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  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, 29 Sep 2014 17:41:42 +0200
From:	Peter Zijlstra <>
To:	Matt Fleming <>
Cc:	Ingo Molnar <>, "H. Peter Anvin" <>,
	Thomas Gleixner <>,,,
	Ard Biesheuvel <>,
	Matthew Garrett <>
Subject: Re: [GIT PULL] EFI changes for v3.18

On Mon, Sep 29, 2014 at 04:00:09PM +0100, Matt Fleming wrote:
> On Mon, 29 Sep, at 04:05:16PM, Peter Zijlstra wrote:
> > 
> > OMFG what a trainwreck... if they are reentrant like that, a lock isn't
> > going to help you in any way. The implementation of these calls must be
> > lockfree otherwise they cannot possibly be correct.
> The only way these services are going to be called is if we (the OS)
> invoke them. These NMI shenanigans we're playing in the locking
> functions are actually for our benefit, not the firmware's.
> > Conditional locking like above is just plain broken, disgusting doesn't
> > even begin to cover it. Full NAK on this. If this is required by the EFI
> > spec someone needs to pull their head from their arse and smell the real
> > world.
> The conditional locking isn't intended to conform to the spec, it's
> intended to write a pstore object to the EFI variable NVRAM with our
> last dying breath, even if someone was in the middle of a SetVariable()
> call. All the spec says is that, if we're in a non-recoverable state,
> it's OK to do that. Whether that'll be implemented correctly across a
> range of firmware implementations is another matter.
> In fact, maybe we shouldn't support that lockless access at all. I've no
> huge problem changing the code in efi_pstore_write() to bail if we can't
> grab the lock, so that we can be serialized all of the time.
> That would certainly make the runtime lock code much simpler.

Right, like we talked about on IRC, we need to either drop all from NMI
stuff or do the trylock-from-NMI thing you suggested and have a runtime
test to make sure that all actually works.

Because just not having any serialization is relying on the firmware to
not screw itself, which I think is unsound, esp. given that Windows is
unlikely to rely on this and we all know the quality of implementation,
esp. outside of what Windows does.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists