> Cook's implementation contains architecture-specific code that relies on CPU features on x86 and ARM that selectively enable and disable write access to areas of memory. Thus, the data write routines cannot be preemptible, as interrupting the kernel after it enables writing on read-only memory would result in leaving a window of vulnerability open.
Question from someone woefully lacking in kernel knowledge: what does it mean that
- these routines are not preemptible, and
- interrupting the kernel in this scenario would leave it vulnerable
That the routines are not preemptible means that an interrupt cannot run while that piece of code is running until it turns interrupts back on.
The point of this whole thing is to be able to write to "read-only" memory occasionally and be able to do it securely. That way things that aren't updated much (or that you have to be ultra careful with) can't be updated accidentally or via an exploit somewhere else in the kernel. If the memory is marked read-only most of the time then the CPU will prevent you from messing with it.
So you're supposed to start the process with one of these new functions (allowing writes), make the change, then end the process (locking the memory into read-only mode again) with another function.
This is where interrupts are dangerous. If interrupts were on then at anytime the kernel may switch what it's doing to do something else that it considers to be higher priority.
If the interrupt happens between when the work starts and the work ends then while the interrupt is running that memory is not read-only mode when code you don't control gets to run. On a very busy system you might be able to use a bug in another part of the kernel to update something that is supposed to be "read-only" because that protection is temporarily turned off.
By making it so an interrupt can't run you don't have to worry about that case.
There are a number of things in the kernel have to be run in the same mode for various reasons.
Sidenote: I've been following the LWN articles on the Linux kernel for a very long time and have learned a TON of interesting information about how all sorts of low level things work and the problems that can arise. I strongly recommend a subscription to LWN if you have any interest in this kind of stuff .
Oh of course - interrupts. Right. Which is what [I now understand] preeemptible means; system interrupts can intercept normal execution and cause the kernel to go do something else for a minute.
Thanks so much for explaining the read-write conditions too, I now understand this perfectly.
Thanks for the recommendation about the LWN subscription, I'll file that away as a serious consideration. For the meantime, I'm curious - does the subscriber-only content go free after a certain period, or do certain articles remain subscriber-only?
> Thanks for the recommendation about the LWN subscription, I'll file that away as a serious consideration. For the meantime, I'm curious - does the subscriber-only content go free after a certain period, or do certain articles remain subscriber-only?
All subscriber-only content becomes public after one week. However, that one week often makes the difference between learning about things while they're still active areas of consideration and discussion, versus learning about things when they're over and done with. A subscription helps you learn about things you can still participate in.
A routine that satisfies the latter is an example of a non-preemptible routine. Interrupting means temporarily suspending the current processing flow and doing something else. Like, when a hardware interrupt has fired (data arrived on the network interface or the sound card, need to process right now...). If you want to know more - it's on Wikipedia for you :P (contrast preemptible with reentrant).
Question from someone woefully lacking in kernel knowledge: what does it mean that
- these routines are not preemptible, and
- interrupting the kernel in this scenario would leave it vulnerable
?