Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 16:03 UTC (Sat) by scientes (guest, #83068)
In reply to: Calibrating your fear of big bad optimizing compilers by hsivonen
Parent article: Calibrating your fear of big bad optimizing compilers

>so using atomics to access userland memory from the kernel is technically UB.

But don't we only look at user-land data from the same thread that sent the data, so there are no races (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 16:47 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

> (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

If the access from the kernel is undefined behaviour (because another user thread modified that memory in violation of the rules), that's the kernel's problem. Undefined behaviour doesn't just mean the kernel will read an incorrect value, it means absolutely anything could happen (and would happen with kernel privileges).

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 19:12 UTC (Sat) by hsivonen (subscriber, #91034) [Link]

Right. The C++11/C11 memory model has just UB and doesn’t say which thread of execution experiences the UB. For use cases like kernel vs. userland, hypervisor vs. guest, Web browser UI vs. renderer, and Wasm host vs. Wasm program, you want to have things defined such that the more privileged side can’t experience UB if the less privileged side doesn’t follow the rules.