-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIMD-0181: Privileged Syscalls #181
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,101 @@ | ||
--- | ||
simd: '0181' | ||
title: Privileged Syscalls | ||
authors: | ||
- Joe Caulfield | Anza | ||
category: Standard | ||
type: Core | ||
status: Draft | ||
created: 2024-10-02 | ||
feature: (fill in with feature tracking issues once accepted) | ||
supersedes: (optional - fill this in if the SIMD supersedes a previous SIMD) | ||
superseded-by: (optional - fill this in if the SIMD is superseded by a subsequent | ||
SIMD) | ||
extends: (optional - fill this in if the SIMD extends the design of a previous | ||
SIMD) | ||
--- | ||
|
||
## Summary | ||
|
||
Support for privileged syscalls, to perform special-cased runtime activities, | ||
for enshrined program IDs only. | ||
|
||
## Motivation | ||
|
||
As we continue the effort to migrate all builtin programs to on-chain BPF | ||
programs (Core BPF), the ability for some of these programs to perform | ||
privileged operations becomes immediately relevant. | ||
|
||
Some examples of such operations are: | ||
|
||
- Allocating very large accounts (System program) | ||
- Marking accounts as `executable` (loaders) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That may be, but there are other use cases for this class of syscalls. Some potential examples:
I can add them to the proposal once I firm up the list of known privileged operations. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed that we probably will need a few exceptions to raise limits in the program runtime for core programs. But I don't think that these should come as syscalls. In general we try to avoid adding syscalls and built-ins. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The syscall approach I feel like gives us a more standardized interface and specification for these kinds of operations, rather than just baking them into the program runtime's implementation details. For example, such a specification (privileged syscalls) makes reimplementation with other clients/VMs easier I would think. What kind of alternatives did you have in mind? |
||
|
||
In order to accomplish the aforementioned goal, some programs - such as System | ||
and loaders - will need the ability to perform activites that are not permitted | ||
to all on-chain BPF programs. | ||
|
||
Similar to the purpose of [SIMD 0088](./0088-enable-core-bpf-programs.md), this | ||
SIMD serves to establish the existence of "privileged syscalls", which are | ||
syscalls only available to enshrined programs. | ||
|
||
## New Terminology | ||
|
||
- **Privileged Syscall**: A virtual machine builtin function only available to | ||
runtime-enshrined program IDs. | ||
|
||
## Detailed Design | ||
|
||
The Solana Virtual Machine (SVM) follows a well-defined Instruction Set | ||
Architecture (ISA) for supported VM op codes. Additionally, the Solana protocol | ||
also dictates a set of interfaces for VM builtin functions known as System | ||
Calls, or "syscalls". | ||
|
||
All of the protocol-defined syscalls are made available to all on-chain programs | ||
through a loader, which implements each syscall interface at the runtime level, | ||
allowing on-chain programs to call into them to perform certain actions, such as | ||
logging and invoking other programs. | ||
|
||
This proposal suggests adding interfaces for "privileged" syscall interfaces to | ||
the Solana protocol. These syscalls would specifically _not_ be made available | ||
to all on-chain programs, but rather a subset of programs, represented by an | ||
enshrined set of program IDs within the runtime. | ||
|
||
These privileged syscalls must _only_ be registered VM builtin functions for | ||
enshrined programs. When the runtime encounters an enshrined program to be | ||
executed, it must register the necessary privileged syscalls as VM builtin | ||
functions for the provisioned VM instance. When any non-enshrined program is | ||
encountered, these functions must not be registered. | ||
|
||
Each new privileged syscall introduced to the protocol must have its own SIMD. | ||
The program IDs that must be granted access to that particular privileged | ||
syscall must be included in the proposal. | ||
|
||
## Alternatives Considered | ||
|
||
The primary alternative to privileged syscalls is for any builtin programs that | ||
perform privileged operations to remain builtins, and not be migrated to Core | ||
BPF. However, this would force validator client teams to maintain these builtins | ||
with their clients. | ||
|
||
With the suggested approach for privileged syscalls, validator client teams | ||
would instead only have to maintain these syscalls themselves, not entire | ||
programs. | ||
|
||
## Impact | ||
|
||
As mentioned above, privileged syscalls would further enable all builtin | ||
programs to be migrated to Core BPF, reducing the maintenance burdern for | ||
core contributors from various validator client teams. | ||
|
||
Developers and validators are unaffected. All on-chain programs that are not | ||
granted access to privileged syscalls are unaffected. Those programs that are | ||
granted access would be backwards compatible. | ||
|
||
## Security Considerations | ||
|
||
The primary security consideration is ensuring that only those enshrined | ||
programs can access these privileged syscalls. If not implemented correctly, | ||
core contributors could mistakenly grant privileged abilities to ordinary | ||
on-chain programs, which could have consequential implications on consensus. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Account allocation is managed and limited by the serialization interface. See "The serialization interface" in #177. Syscalls can't change anything about that.