
The “rare write” mechanism - JoshTriplett
https://lwn.net/SubscriberLink/724319/d25e2894c072d2af/
======
i336_
> _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

?

~~~
MBCook
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
.

~~~
i336_
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?

~~~
JoshTriplett
> 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.

~~~
dllthomas
> A subscription helps you learn about things you can still participate in.

As well as helping sustain such an amazing resource!

