linux-kernel - Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled

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: <20160211160405.GK4134@codeblueprint.co.uk>
Date:	Thu, 11 Feb 2016 16:04:05 +0000
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with
 interrupts enabled

On Mon, 08 Feb, at 11:37:58AM, Andy Lutomirski wrote:
> On Feb 4, 2016 5:58 AM, "Ard Biesheuvel" <ard.biesheuvel@...aro.org> wrote:
> >
> > OK, since Sai has confirmed that Windows leaves interrupts enabled when
> > calling the EFI variable store related runtime services, we should be able
> > to do the same for Linux, or at least be slightly more confident that we
> > won't have to back out this change later.
> 
> Could this use a mutex instead of a spinlock?
> 
> Can someone with a mixed mode setup read a variable in a loop and make
> sure it doesn't crash and burn?  It should work fine, but explicit
> testing would be nice.  (It's interesting mainly because doing a mixed
> mode call with interrupts on can result in a non-IST CPL0 to CPL0
> exception delivery, which won't result in a stack switch.  This could
> easily trigger a stack overflow, logic bug, microcode bug, or
> as-yet-unknown CPU "feature".
 
I don't have physical hardware for testing mixed mode anymore (that
was returned to Intel when I left) but testing with Qemu didn't turn
up any problems when running with interrupts enabled.

> Hmm.  We should also audit the mixed mode entry code to make sure that
> the high bits of RSP are explicitly clear before switching into compat
> mode.  If I had to make a guess about how CPUs behave, I'd guess
> pessimistically: Intel CPUs clear the high bits of RSP when switching
> into long mode due to interrupt delivery, and AMD CPUs leave them set
> just to mess with us.
 
Interesting thought. I'm not aware of anyone testing mixed mode with
AMD CPUs, so that would be a good data point.

> Also, a WARN_ON(in_interrupt()) somewhere might be a good sanity check.

lockdep should catch this kind of stuff pretty quickly since we grab
the spinlock in every code path.