|
|
Subscribe / Log in / New account

Calibrating your fear of big bad optimizing compilers

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 9:17 UTC (Sat) by hsivonen (subscriber, #91034)
In reply to: Calibrating your fear of big bad optimizing compilers by scientes
Parent article: Calibrating your fear of big bad optimizing compilers

Atomics require the other thread of execution to be conforming to the C++1/C11 memory model. There is no such guarantee for userland processes, so using atomics to access userland memory from the kernel is technically UB.

The only thing in C or C++ that allows you to access (in a non-UB way) memory that doesn’t participate in the memory model is volatile, but since the use case it is designed for is memory-mapped devices, it inhibits more optimizations than would be necessary for the use cases of kernel accessing userland memory when responding to a syscall, a hypervisor accessing guest memory when implementing a virtual device, or a Wasm host assessing a SharedArrayBuffer Wasm heap when responing to a call to a host service.

Considering that this type of software is typically implemented in languages that inherit the C++11 memory model (C++ itself plus C11 and Rust), it’s surprising that this facility is missing.


to post comments

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 16:03 UTC (Sat) by scientes (guest, #83068) [Link] (2 responses)

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


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds