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: Willy Tarreau on 11 Nov 2009 04:40 On Wed, Nov 11, 2009 at 09:03:13AM +0100, Pavel Machek wrote: > > > (...) > > > > 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? No, not at all ! > 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. That's the point I agree with you, I don't like this setting either. I don't want to incite applications to use features that are emulated. However I think that allowing applications run when they don't/can't perform the check is useful. > (Imagine application that has NOPL in inner loop, for performance > reasons. You want to use version _without_ the NOPL on processors that > lack it.) Exactly. Same for MMX, 3DNOW, SSE* and such. > 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. 100% agreed ! 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/
From: Willy Tarreau on 11 Nov 2009 04:40 On Tue, Nov 10, 2009 at 11:57:04PM -0800, H. Peter Anvin wrote: > 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. It just depends on how the instruction prefetcher is implemented. If the check is only performed on the first byte of the opcode, we can miss the tail. In my experience, intel processors have been doing instruction checks right, but I have no reason to be absolutely certain that all other vendors do that right, especially those targetting cheap embedded systems. Eventhough this one is not for this precise case, here's an example of such a missed boundary check : http://download.intel.com/design/processor/specupdt/315593.pdf AK27: "general protection fault may not be signaled on data segment limit violation above 4-G limit". Status: "no fix". Note that I don't find this can present a significant vulnerability risk. Maybe if someone comes with a concrete case where it is a real trouble, they will fix it. > >> 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. You're not helping. You're asking me to prove that something has no issue, all I can say is that it does not have any issue I can imagine. Proving the opposite with an example would be easier. All I can say is that executing a NOP results in no state change in the processor except the instruction pointer which points to the next instruction after execution. Since a NOP changes nothing, it cannot be used alone to provide any privilege, access to data or any such thing. Since it does not perform any jump, it cannot either be used to take back control of the execution flow. And it is certain that the next instruction after it will be executed, so if the NOP crosses a page boundary and completes on a non-executable one, the next instruction will trigger the PF. So I can't see how a NOP can be used to circumvent any protection. 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: Alan Cox on 11 Nov 2009 05:10 On Tue, 10 Nov 2009 22:15:58 -0800 "H. Peter Anvin" <hpa(a)zytor.com> 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?! > > I personally will consider something that doesn't implement proper > security check to be a potential security hole and will NAK the patch. Assuming you are doing the fault handling only for a CPU where you expect to need it (which would be wise I think) then it's a question of whether the CPU supports NX in the first place. Even if it does the only thing you can reasonably hope to do is move the program counter one instruction into the next page. The user access checks will trap any attempt to cross 0xC0000000 and the protection fault might just occur one or part of an instruction on in the other cases. Alan -- 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: Alan Cox on 11 Nov 2009 05:30 > So in my opinion, we should have : > - CMOV (for 486, Pentium, C3, K6, ...) > - NOPL (newcomer) > > And if we want to extend down to i386 : > - BSWAP (=htonl) > - CMPXCHG (mutex) > - XADD (never encoutered but cheap) > > I still have the 2.4 patch for BSWAP, CMPXCHG, CMOV and XADD lying If we go that far it needs a lot more thought and probably to use the KVM code simply because of all the complexities around prefixes and the like (Not of course that the real CPUs are consistent either) -- 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 05:50
On Wed, Nov 11, 2009 at 10:21:36AM +0000, Alan Cox wrote: > > > So in my opinion, we should have : > > - CMOV (for 486, Pentium, C3, K6, ...) > > - NOPL (newcomer) > > > > And if we want to extend down to i386 : > > - BSWAP (=htonl) > > - CMPXCHG (mutex) > > - XADD (never encoutered but cheap) > > > > I still have the 2.4 patch for BSWAP, CMPXCHG, CMOV and XADD lying > > If we go that far it needs a lot more thought and probably to use the KVM > code simply because of all the complexities around prefixes and the like well, ironically the KVM decoder can decode an infinite string of prefixes while the very simple and limited one in the patch I showed did correct checks for invalid cases (multiple segments, repeated locks, etc...). It would only accept one data size prefix, one address size prefix, one lock and one segment prefix. I have nothing against the KVM one, it's just that it's a full-featured emulator while we were speaking about a 686 emulators for lower-end processors. 98% of the instructions supported by KVM will never be used for that purpose. This is where I see a waste. We're comparing 7000 lines of code supporting 64-bit, real mode, NX, etc... to 400. I fail to see how we can guarantee that we do it right in that larger code (and the example above proves it wrong). And as you said, NX is not an issue on the CPUs we're targetting. 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/ |