From c7d29ee9d0666fc0d8c5f3a06102e54bb5e5086c Mon Sep 17 00:00:00 2001 From: Joe Caulfield Date: Wed, 2 Oct 2024 14:55:32 +0700 Subject: [PATCH] privileged syscalls --- proposals/XXXX-privileged-syscalls.md | 101 ++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 proposals/XXXX-privileged-syscalls.md diff --git a/proposals/XXXX-privileged-syscalls.md b/proposals/XXXX-privileged-syscalls.md new file mode 100644 index 000000000..ac95c7384 --- /dev/null +++ b/proposals/XXXX-privileged-syscalls.md @@ -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. +