SIMD-0181: Privileged Syscalls

[buffalojoec]

Support for privileged syscalls, to perform special-cased runtime activities,
for enshrined program IDs only.

[Lichtso]

Account allocation is managed and limited by the serialization interface. See "The serialization interface" in #177. Syscalls can't change anything about that.

[Lichtso]

This requirement is already being phased out through #162 and #167.

[buffalojoec]

That may be, but there are other use cases for this class of syscalls. Some potential examples:

• ELF verification
• Updating the program JIT cache
• Reduced/ignored CUs for vote processing

I can add them to the proposal once I firm up the list of known privileged operations.

[Lichtso]

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.

[buffalojoec]

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?

[topointon-jump]

I support the general idea, but this doesn't feel like a "spec". It seems more like a discussion of a concept, rather than a spec which client teams should implement. I think the "Discussions" tab is a better place for SIMDs like these.

When there are concrete specifications for specific privileged syscalls and their semantics those should go into a SIMD.

Thoughts?

[buffalojoec]

I support the general idea, but this doesn't feel like a "spec". It seems more like a discussion of a concept, rather than a spec which client teams should implement. I think the "Discussions" tab is a better place for SIMDs like these.

When there are concrete specifications for specific privileged syscalls and their semantics those should go into a SIMD.

Thoughts?

Fair enough. So would you rather we introduce the first privileged syscall itself as well as the new concept of privileged syscalls in the same SIMD? Or just one SIMD for all of the proposed privileged ones and their corresponding programs?

Previously I have introduced a SIMD to lay out the new protocol concept, and then subsequent SIMDs which depend on that can reference it, but I'm happy to move in the suggested direction!

[topointon-jump]

Fair enough. So would you rather we introduce the first privileged syscall itself as well as the new concept of privileged syscalls in the same SIMD? Or just one SIMD for all of the proposed privileged ones and their corresponding programs?

I think a SIMD for a concept is a bit unclear, because it's not clear exactly what client teams are agreeing to by approving it. If the concept is controversial or needs fleshing out https://github.com/solana-foundation/solana-improvement-documents/discussions seems like a great place to do this.

If the concept is fleshed out then I think a concrete SIMD specifying the implementation is great. In this either of your suggestions would work. I think SIMDs work best when they are precise and concrete 😄

[buffalojoec]

If the concept is fleshed out then I think a concrete SIMD specifying the implementation is great. In this either of your suggestions would work. I think SIMDs work best when they are precise and concrete 😄

Sounds good. I'll close this for now, do some more fleshing out, open the discussion in the discussions tab, and if we want to move forward I'll reopen this PR and update it.