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

Date:	Thu, 11 Feb 2016 16:03:54 +0000
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"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 Tue, 09 Feb, at 05:52:34PM, Ard Biesheuvel wrote:
> On 8 February 2016 at 20:37, Andy Lutomirski <luto@...capital.net> 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?
> >
> 
> When I first started working on this code, I proposed using a mutex,
> but at the time, we still had the efi-pstore case to worry about
> http://article.gmane.org/gmane.linux.kernel.efi/4112
> 
> In the mean time, we have modified the efi-pstore code so it simply
> gives up when the EFI varstore is busy, and we also got rid of the NMI
> special case where locks are ignored. In summary, it sounds to me that
> moving to a mutex should be feasible, but I am only really familiar
> with the ARM side of the implementation, which is far less complex
> than the x86 side, so Matt should confirm.

You cannot touch mutexes from interrupt context, not even to perform a
mutex_trylock(), and that's the problem.

Since the efi-pstore code can run from interrupt context we need to
use a locking primitive that works, even though we have all that
non-blocking logic.