Re: Allow data races on some read/write operations

[Ralf Jung]

Hi all,

> > > For some kinds of hardware, we might not want to trust the hardware.
> > > I.e., there is no race under normal operation, but the hardware could
> > > have a bug or be malicious and we might not want that to result in UB.
> > > This is pretty similar to syscalls that take a pointer into userspace
> > > memory and read it - userspace shouldn't modify that memory during the
> > > syscall, but it can and if it does, that should be well-defined.
> > > (Though in the case of userspace, the copy happens in asm since it
> > > also needs to deal with virtual memory and so on.)
> >
> > Wow you are really doing your best to combine all the hard problems at the same
> > time. ;)
> > Sharing memory with untrusted parties is another tricky issue, and even leaving
> > aside all the theoretical trouble, practically speaking you'll want to
> > exclusively use atomic accesses to interact with such memory. So doing this
> > properly requires atomic memcpy. I don't know what that is blocked on, but it is
> > good to know that it would help the kernel.
>
> I am sort of baffled by this, since the C kernel has no such thing and
> has worked fine for a few years. Is it a property of Rust that causes us
> to need atomic memcpy, or is what the C kernel is doing potentially dangerous?

It's the same in C: a memcpy is a non-atomic access. If something else 
concurrently mutates the memory you are copying from, or something else 
concurrently reads/writes the memory you are copying two, that is UB.
This is not specific to memcpy; it's the same for regular pointer loads/stores. 
That's why you need READ_ONCE and WRITE_ONCE to specifically indicate to the 
compiler that these are special accesses that need to be treated differently. 
Something similar is needed for memcpy.

Kind regards,
Ralf