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 12 Nov 2009 00:30 On Wed, Nov 11, 2009 at 06:23:14PM -0800, Matt Thrailkill wrote: > On Wed, Nov 11, 2009 at 1:32 AM, Willy Tarreau <w(a)1wt.eu> wrote: > > 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. > > So a nop(l) sled won't be a problem, right? Right. However we just noticed that with the KVM emulator, you can make it loop for a long time if you feed it with prefixes only. For instance, write a function which does zillions of 0x66 (data size prefix) then return (0xC3) : 66 66 66 ... 66 C3. This is typically the sort of things we must be very careful about in emulators, because we don't want users to steal large amounts of system CPU time doing nothing. 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: H. Peter Anvin on 12 Nov 2009 00:40 On 11/11/2009 09:27 PM, Willy Tarreau wrote: > > Right. However we just noticed that with the KVM emulator, you > can make it loop for a long time if you feed it with prefixes > only. For instance, write a function which does zillions of 0x66 > (data size prefix) then return (0xC3) : 66 66 66 ... 66 C3. > > This is typically the sort of things we must be very careful about > in emulators, because we don't want users to steal large amounts > of system CPU time doing nothing. > That is a (serious) bug in the KVM interpreter, and indeed the exact kind of issues interpreters tend to have... which is why I'd like one piece of code with one set of bugs, and more eyeballs on that one piece of code so they can be fixed. -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 12 Nov 2009 00:50 On Wed, Nov 11, 2009 at 09:31:26PM -0800, H. Peter Anvin wrote: > On 11/11/2009 09:27 PM, Willy Tarreau wrote: > > > > Right. However we just noticed that with the KVM emulator, you > > can make it loop for a long time if you feed it with prefixes > > only. For instance, write a function which does zillions of 0x66 > > (data size prefix) then return (0xC3) : 66 66 66 ... 66 C3. > > > > This is typically the sort of things we must be very careful about > > in emulators, because we don't want users to steal large amounts > > of system CPU time doing nothing. > > > > That is a (serious) bug in the KVM interpreter, and indeed the exact > kind of issues interpreters tend to have... which is why I'd like one > piece of code with one set of bugs, and more eyeballs on that one piece > of code so they can be fixed. Well, I could try to work on a fix (basically the same principle as in mine, with prefix flags), but I simply don't know how to test the code. I've never experimented with KVM yet and learned it embeds an emulator for the first time a few days ago in this thread :-/ If it's easy to make use of it, I'm not opposed to try. 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 13 Nov 2009 05:50 > Interesting...geode gx being buggy? I know pentium was famous for the > fdiv bug, but never heard of geode gx problems... Depends which one - the older ones were very solid. The very first (5510) had some interesting bugs but they were fairly soon stomped. 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: Lennart Sorensen on 13 Nov 2009 11:30
On Thu, Nov 12, 2009 at 09:55:12PM -0800, Yuhong Bao wrote: > Well, do you know the history of the Geode line? It originated in the Cyrix MediaGX, then that was sold to NSC and renamed to Geode, then that was sold to AMD later. That is the history of the Geode GX line yes. The Geode LX is an AMD design, and the Geode NX is an athlon with a lower voltage. Hence the LX probably isn't anything like the original GX. It certainly has none of the bugs or performance issues of the GX. -- 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/ |