Closed FrankReh closed 4 months ago
Sorry. I think I've convinced myself the exposure is no different than the user thread itself writing bad data into the sq before calling into the kernel.
Right, it doesn't change that at all. In general, the kernel keeps its own indexes for this anyway, as it allow it to update it as needed rather than directly every time.
A recent commit (I don't want to link to it because this is probably a bad question) relaxed the sq load instructions when not in SQPOLL mode because the user thread is blocked while the kernel is accessing the sq fields. Don't we care that another thread, misinformed or maliciously written, could have read/write access to the same memory map? Is it known that at worst, such a scenario can only lead to corrupted data going to or from the resource; it can't lead to a kernel crash or corrupted kernel space? I'm probably overlooking something.