←back to thread

What Makes System Calls Expensive: A Linux Internals Deep Dive

(blog.codingconfessions.com)
72 points rbanffy | 1 comments | 20 Sep 25 13:53 UTC | HN request time: 0.205s | source
Show context
blakepelton ◴[20 Sep 25 14:43 UTC] No.45313835[source]▶
The article quotes the Intel docs: "Instruction ordering: Instructions following a SYSCALL may be fetched from memory before earlier instructions complete execution, but they will not execute (even speculatively) until all instructions prior to the SYSCALL have completed execution (the later instructions may execute before data stored by the earlier instructions have become globally visible)."

More detail here would be great, especially using the terms "issue" and "commit" rather than execute.

A barrier makes sense to me, but preventing instructions from issuing seems like too hard of a requirement, how could anyone tell?

replies(2): >>45315382 #>>45319204 #
1. eigenform ◴[21 Sep 25 01:27 UTC] No.45319204[source]▶
> preventing instructions from issuing seems like too hard of a requirement

If this were the case, you could perform SYSCALL in the shadow of a mispredicted branch, and then try to use it to leak data from privileged code.

When the machine encounters an instruction that changes privilege level, you need to validate that you're on a correct path before you start scheduling and executing instructions from another context. Otherwise, you might be creating a situation where instructions in userspace can speculatively influence instructions in the kernel (among probably many other things).

That's why you typically make things like this drain the pipeline - once all younger instructions have retired, you know that you're on a correct [not-predicted] path through the program.

edit: Also, here's a recent example[^1] of how tricky these things can be (where SYSCALL isn't even serializing enough to prevent effects in one privilege level from propagating to another)

[^1]: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf