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 10 Nov 2009 17:50 On 11/10/2009 02:34 PM, Lennart Sorensen wrote: > On Tue, Nov 10, 2009 at 02:29:33PM -0800, H. Peter Anvin wrote: >> I don't believe we were talking about ARM. > > True. I do get the impression the ARM has higher trap overhead than x86. Also, the x87 FPU is a very clunky beast that's slow to emulate (unlike SSE). -hpa -- 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 10 Nov 2009 17:50 On Tue, Nov 10, 2009 at 11:20:31PM +0100, Ingo Molnar wrote: > > * H. Peter Anvin <hpa(a)zytor.com> wrote: > > > *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 ? 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: Lennart Sorensen on 10 Nov 2009 18:00 On Tue, Nov 10, 2009 at 02:38:02PM -0800, H. Peter Anvin wrote: > Also, the x87 FPU is a very clunky beast that's slow to emulate (unlike > SSE). Yeah x87 is rather horrible. -- Len Sorensen -- 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 10 Nov 2009 18:00 On 11/10/2009 02:42 PM, Willy Tarreau wrote: > On Tue, Nov 10, 2009 at 11:20:31PM +0100, Ingo Molnar wrote: >> >> * H. Peter Anvin <hpa(a)zytor.com> wrote: >> >>> *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. -hpa -- 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:00
On Tue, Nov 10, 2009 at 02:47:20PM -0800, H. Peter Anvin wrote: > On 11/10/2009 02:42 PM, Willy Tarreau wrote: > > On Tue, Nov 10, 2009 at 11:20:31PM +0100, Ingo Molnar wrote: > >> > >> * H. Peter Anvin <hpa(a)zytor.com> wrote: > >> > >>> *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 ! On the other hand, I certainly understand why this would be an important check in a complete emulator which could parse and emulate a flow of instructions. 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. Regards, 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/ |