On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau <w...@1wt.eu> wrote: > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote: >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote: >> > I see and am not particularly against this, but what use case do you >> > have in mind precisely ? I doubt it's just saving a few tens of bytes, >> > so probably you're more concerned about the potential risks this opens ? >> > But given we only allow this for CAP_SYS_RAWIO and these ones already >> > have access to /dev/mem and many other things, don't you think there >> > are much easier ways to dump kernel memory in this case than trying to >> > inject some meltdown code into the victim process ? Or maybe you have >> > other cases in mind that I'm not seeing. >> >> I'd like this to be config-controllable so that distros can make the >> decision whether/if they want to support the whole per-mm thing. > > OK. > >> Also, if CAP_SYS_RAWIO is going to protect, please make the >> ARCH_GET_NOPTI variant check it too. > > Interestingly I removed the check consecutive to the discussions. But > I think I'll simply remove the whole ARCH_GET_NOPTI as it has no real > value beyond initial development. >
I've thought about this a bit more. Here are my thoughts: 1. I don't like it being per-mm. I think it should be a per-thread control so that a program can have a thread with PTI that runs less-trusted JavaScript and other network threads with PTI off. Obviously we lose NX protection mm-wide if any threads have PTI off. I think the way to implement this is: Have this in struct mm_context: bool has_non_pti_thread; To turn PTI off on a thread: Take pagetable_lock. if (!has_non_pti_thread) { context.has_non_pti_thread = true; clear the NX bits; } drop pagetable_lock; set the TI flag; Fork clears the per-mm flag in the new mm. Exec clears it, too. I think that's all that's needed. Newly created threads always have PTI on. To turn PTI back on, just clear the TI flag. 2.Turning off PTI is, in general, a terrible idea. It totally breaks any semblance of a security model on a Meltdown-affected CPU. So I think we should require CAP_SYS_RAWIO *and* that the system is booted with pti=allow_optout or something like that. --Andy