Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs

----- On Jul 2, 2018, at 7:06 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

On Mon, Jul 2, 2018 at 4:00 PM Mathieu Desnoyers
[off-list ref] wrote:

quoted

Unfortunately, that rseq->rseq_cs field needs to be updated by user-space
with single-copy atomicity. Therefore, we want 32-bit user-space to initialize
the padding with 0, and only update the low bits with single-copy atomicity.

Well... It's actually still single-copy atomicity as a 64-bit value.

Why? Because it doesn't matter how you write the upper bits. You'll be
writing the same value to them (zero) anyway.

So who cares if the write ends up being two instructions, because the
write to the upper bits doesn't actually *do* anything.

Hmm?

Are there any kind of guarantees that a __u64 update on a 32-bit architecture
won't be torn into something daft like byte-per-byte stores when performed
from C code ?

I don't worry whether the upper bits get updated or how, but I really care
about not having store tearing of the low bits update.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com