On 05/02/2018 11:23 PM, Andy Lutomirski wrote:
The kernel could do*something*, probably along the membarrier system
call. I mean, I could implement a reasonable close approximation in
userspace, via the setxid mechanism in glibc (but I really don't want to).
I beg to differ.
Thread A:
old = RDPKRU();
WRPKRU(old & ~3);
...
WRPKRU(old);
Thread B:
pkey_alloc().
If pkey_alloc() happens while thread A is in the ... part, you lose. It
makes no difference what the kernel does. The problem is that the WRPKRU
instruction itself is designed incorrectly.
Even that is solvable, as long as the architecture as exact traps: You
can look at the program counter and patch up the registers accordingly
if the code is in the critical section. Of course, this would need
centralizing PKRU updates in a vDSO or a single (glibc) library
function. Certainly not nice and even horrible enough not to do it, but
I don't think it's actually impossible.
Didn't we discuss this before?
Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
