SIMD-0179: SBPF stricter verification constraints

[LucasSte]

No description provided.

[topointon-jump]

Some of these stricter rules, especially those around restricting jump destinations at runtime, have performance implications. Are these stricter checks absolutely necessary? If so, I think there are other ways of achieving this security without compromising performance.

[topointon-jump]

Let's specify this version

[topointon-jump]

Will this require a double pass through the bytecode to pick up all valid call destinations?

[Lichtso]

The symbol table is not the bytecode. Call destinations in the bytecode are not registered as functions.

[Lichtso]

Better wording might be:

Functions are registered by presence in the symbol table.

[LucasSte]

Functions are registered by presence in the symbol table.

I was going to adopt your wording, but basically I already say this:

Functions must be registered if they are present in the symbol table.

Is this dubious or ambiguious?

[Lichtso]

Issue is that it is unclear if there are other ways for functions to be registered.

[topointon-jump]

Yea - could we specify that we are treating the symbol table as the source of truth for what is considered a valid call dest? 🙏

[LucasSte]

I included more details on this.

[topointon-jump]

This has performance implications - is this absolutely necessary? If this check is necessary, can we instead have the compiler mark the beginning of valid jump destinations by emitting a marker bytecode opcode?

[topointon-jump]

Can we specify exactly how these rules are enforced:

• Whether the check is performed at runtime or verification time
• The exact logic (in pesudo-code)
• Whether these can be checked in a single pass

Several of these seem like they would have performance implications, and precisely specifying them would help to determine if this is the case or not.

[topointon-jump]

How is this enforced? Is this enforced in the verifier or at runtime?

[Lichtso]

This is a check at verification time (see error code) and is easy to enforce:
The verifier scans all instructions and keeps track of which function it is currently in, then checks jump targets against that range. The current function tracking can be done in constant time (per scanned instruction) by checking the next symbol in the dynamic symbol table and then advancing that pointer once a function boundary is crossed.

See: https://github.com/solana-labs/rbpf/blob/69a52ec6a341bb7374d387173b5e6dc56218fe0c/src/verifier.rs#L238

[topointon-jump]

Could we add this description^ to the SIMD? 🙏

[LucasSte]

Added.

[Lichtso]

• Almost all of the checks are verification time, only exception is the callx target location check, that is at runtime
• All our checks are O(1), O(log n) or O(n) and can be performed in a single forward scan of the bytecode
• About the callx target location runtime check:
  • Our suggestion: We register functions in the dynamic symbol table, then call target verification can be done in the single scan together with all other instructions and callx target runtime check is between O(1) and O(log n)
  • Your suggestion: We register functions in the bytecode, then call target verification requires a second scan of the bytecode, and the callx target runtime check becomes O(1)

[topointon-jump]

Almost all of the checks are verification time, only exception is the callx target location check, that is at runtime
All our checks are O(1), O(log n) or O(n) and can be performed in a single forward scan of the bytecode

Could we add more details about these checks and their performance properties to the SIMD itself, in pseudo-code? I was reading the SIMD without looking at the code, and a lot of these performance properties weren't clear until I read the code.

After reading the code most of my concerns turned out to have been unfounded - it would be great to move towards a world where SIMDs can be read independently of the code.

[topointon-jump]

Your suggestion: We register functions in the bytecode, then call target verification requires a second scan of the bytecode, and the callx target runtime check becomes O(1)

Just to be clear, our suggestion was

• Change the bytecode emitted to have a special marker bytecode, signifying the start of the function
• We can then just check for that bytecode marker in the next instruction right before we jump