i686 quirk for AMD Geode
in [Kernel]
|
Prev: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Next: drm/ksm -> s2disk -> resume -> [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
From: H. Peter Anvin on 11 Nov 2009 01:30 On 11/10/2009 09:52 PM, Willy Tarreau wrote: > > - last, the probability of having an NX page just after an > executable one seems too tight to me to even constitute > an attack vector ! BTW, I'm not even certain that all CPUs > correctly implement this check ! > Do you have *any* *evidence* *whatsoever* for that assertion?! I personally will consider something that doesn't implement proper security check to be a potential security hole and will NAK the patch. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Willy Tarreau on 11 Nov 2009 01:40 On Tue, Nov 10, 2009 at 10:15:58PM -0800, H. Peter Anvin wrote: > On 11/10/2009 09:52 PM, Willy Tarreau wrote: > > > > - last, the probability of having an NX page just after an > > executable one seems too tight to me to even constitute > > an attack vector ! BTW, I'm not even certain that all CPUs > > correctly implement this check ! > > > > Do you have *any* *evidence* *whatsoever* for that assertion?! No, just basic feeling based on implementation cost and difficulty vs gains as I explained. > I personally will consider something that doesn't implement proper > security check to be a potential security hole and will NAK the patch. Even in the case of the NOPL instruction ? I clearly don't see the potential security hole ! Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 11 Nov 2009 03:10 > (...) > > > CMOV/NOPL are rarely used, thus have no reason to cause a massive > > > performance drop, but are frequent enough (at least cmov) for almost > > > > *One* CMOV in the inner loop will make your performance go down 20x. > > yes, just like with emulated FPU or trapped unaligned accesses. It's > just like flying fishes. They exist but they aren't the most common > ones. If people encounter these cases on a specific program, then > they just have to recompile it if it is a problem. At least they > don't rebuild the whole distro. And once again, I've been using > cmpxchg/bswap emulation for years on my i386 without feeling any > need for a rebuild, and CMOV emulation for years now on my mini-itx And did you set cpu family to 6 for your 386? That's the part I was objecting most. Yes, you can emulate, but emulation is very bad for performance... so don't lie about cpu family. (Imagine application that has NOPL in inner loop, for performance reasons. You want to use version _without_ the NOPL on processors that lack it.) So... I don't like instruction emulation, but can live with it. But don't lie about supported instructions in /proc as original patch did. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 11 Nov 2009 03:10 On 11/10/2009 10:36 PM, Willy Tarreau wrote: >> >> Do you have *any* *evidence* *whatsoever* for that assertion?! > > No, just basic feeling based on implementation cost and difficulty > vs gains as I explained. Quite on the contrary; in hardware it would be pretty hard to *not* do the right thing. >> I personally will consider something that doesn't implement proper >> security check to be a potential security hole and will NAK the patch. > > Even in the case of the NOPL instruction ? I clearly don't see > the potential security hole ! > You have it backwards. Prove that there *isn't* one and we'll talk. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 11 Nov 2009 03:20
Hi! > > >>> *THIS* is the kind of complexity that makes me think that having a > > >>> single source for all interpretation done in the kernel is the > > >>> preferred option. > > >> > > >> Definitely agreed ... The NX code is quite a maze right now, so changes > > >> to it should come generously laced with cleanups. > > > > > > BTW, I don't see why we should be impacted by NX. Trying to > > > execute from an NX page would return a SEGV, not SIGILL, so > > > we should not be bothered, am I wrong ? > > > > Yes. Consider a page-crossing instruction. > > OK, but to be pragmatic, NX is there to prevent execution of > instructions in the stack (or heap) during buffer overflows. > If we only implement the few instructions lised in previous > mail, there is very little benefit to check for NX : > > - those instructions cannot jump to other code, they just > change one register or memory location at most (or just nop) > > - once we return from the signal handler, if we have crossed > a NX page boundary, the program will segfault anyway, taking > with it the change we just completed. > > - last, the probability of having an NX page just after an > executable one seems too tight to me to even constitute > an attack vector ! BTW, I'm not even certain that all CPUs > correctly implement this check ! Yes, you can probably "get away" with it. But I would not want to debug problems on systems with half-instruction-emulation. Please do it right, or not at all. > So in short, I think we could reasonably implement CMOV/NOPL > with the instruction length control, with getuser for data > accesses but without checking the code pages permissions if > we know that the CPU could already fetch the beginning of > the instruction correctly to cause an invalid opcode trap. > > I'm not saying this is perfect, just that this is reasonable. Reasonable hack to get distro booting yes. Reasonable for mainline? No. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |