On Mon, 17 Feb 2025 at 21:21, Mathieu Desnoyers[...]
we still let this function read the rseq_cs.
+ * It's unclear what benefits the resticted code gets by doing this
restricted
+ * (it probably already hijacked control flow at this point), and
+ * presumably any sane sandbox should prohibit restricted code
+ * from accessing struct rseq, and this is still better than
+ * terminating the app unconditionally (it always has a choice
+ * of not using rseq and pkeys together).
Note that because userspace can complete an rseq critical section
without clearing the rseq_cs pointer, this could happen simply because
the kernel is preempting the task after it has:
1) completed an rseq critical section, without clearing rseq_cs,
2) changed pkey.
So allowing this is important, and I would remove the comment about
hijacked control flow and such. This can happen with normal use of the
ABI.
Thanks for the review!
I've addressed all comments in the series in v2.
I've reworded this paragraph to simplify sentences, but I still kept
the note aboud malicious rseq_cs.
If we would not be circumventing normal protection, then, yes, these
cases would be the same. But since we are circumventing protection
that otherwise exists, I think it's important to think about
potentially malicious cases. In this context inaccessible rseq_cs
values that resulted from normal execution are very different from
malicious onces. Normal ones will point to a fixed set of real
well-formed rseq_cs objects, while malicious ones may point to
god-knows-where in an attempt of an attacker to do things we can't
even imagine right now (e.g. rseq_cs overlapping with protected crypto
keys).
It's as if a particular instance of copy_to_user would allow
user-space to write arbitrary kernel memory, and memory of other
processes circumventing all normal protections. In that context we
would need to be very careful regarding what we actually allow.