From: Willy Tarreau on
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
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
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

> 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
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/