Re: i686 quirk for AMD Geode

[Willy Tarreau]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/