linux-kernel - Re: [PATCH 2/2] Fix efi

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 May 2016 11:24:55 -0500
From:	Alex Thorlton <athorlton@....com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Alex Thorlton <athorlton@....com>, linux-kernel@...r.kernel.org,
	Dimitri Sivanich <sivanich@....com>,
	Russ Anderson <rja@....com>, Mike Travis <travis@....com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Borislav Petkov <bp@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-efi@...r.kernel.org
Subject: Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote:
> I suppose the SGI/UV code is the only one using 7 arguments or more? Might make
> sense to point that out in the changelog.

First off, to everybody, sorry for the delayed responses.  I've been
AFK for a few days and forgot to set my vacation notice :(

Yes, I believe that's it.  I didn't do a full audit, but a quick glance
at the other users of this call showed that nobody else appears to be
using that many args.

> Just curious, how did you find this bug? It's a pretty obscure one, of the 
> 'developer tears out hairs from frustruation' type ...

Yes, this one was a real puzzle to figure out.  Basically I just stepped
through the assembly code from a known good point to see how we ended up
where we did.  I quite a bit of help from the vets around here, as well
as from our simulator that I used to step through our early boot code to
find the problem.

The real hair pulling mostly came from trying to figure out *WHY* we
were putting the return address in this seemingly random spot on the
stack.  After thoroughly re-reading assorted Intel (et. al.) docs about
a hundred times, I was able to piece together what I thought was
supposed to be going on here.  The solution may be simple, but arriving
there was anything but that :)

- Alex