-
Notifications
You must be signed in to change notification settings - Fork 98
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
0005fd6
commit c7d29ee
Showing
1 changed file
with
101 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,101 @@ | ||
--- | ||
simd: 'XXXX' | ||
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) | ||
|
||
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 "priviledged" 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 priviledged 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. | ||
|