linux-kernel - Re: [patch] x86: fix taking DNA during 64bit sigreturn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200711130143.04807.ak@suse.de>
Date:	Tue, 13 Nov 2007 01:43:04 +0100
From:	Andi Kleen <ak@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	akpm@...ux-foundation.org
Subject: Re: [patch] x86: fix taking DNA during 64bit sigreturn

On Tuesday 13 November 2007 01:11, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> The *real* fix for this is almost certainly to just get rid of the
> >> 64-bit code entirely, and use the 32-bit code as the base for one single
> >> unified setup.
> >
> > That would likely break the ABI. x86-64 ABI is completely different here
> > -- no ibcs, just pure x86 ISA.
>
> Different ABIs clearly have to be handled, 

Well all four cases are quite different.

> but I don't think that is a 
> huge deal.  The i387 code overall (not just asm/i387.h) is very
> different,

Yes because x86-64 is vastly simpler. e.g. the 64bit path 
does not touch the state itself at all. And all the state convert
code moved into the compat layer only. There were also
various other cleanups.

Also 64bit e.g. defers some of the checking to the context
switch, which also simplifies things.

> though, and I find it unlikely that a properly unified code 
> is going to be ready and working in the 2.6.24 timeframe. 

To be honest it is unclear to me how you can do better than
direct FXSAVE from/to user space on 64bit.  Sure you could
put a manual convert pass inbetween like i386, but that
would be rather pointless because it matches 1:1 and in fact would
make the code to be worse (no transparent support of future
FXSAVE extensions) . Not sure what tripped
Linus up so much either. Was it the broken white space?

> I'm exploring 
> if a partial merge with high confidence level is feasible; either way, a
> proper merge for 2.6.25 is probably the right thing.

At least on 64bit the result would be probably more complicated
and likely slower code.

If anything it might make sense to add a few more of the 64bit 
improvements to 32bit (e.g. delayed exception checking).
The direct FXSAVE path cannot be moved over because it
would break the ABI, otherwise I would have done that 
long ago.

BTW if you're looking for real fixes to do iirc some of the FPU
context switch workarounds are missing in KVM which
does mostly its own thing currently.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/