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:	Sat, 30 Apr 2016 21:01:24 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	"Compostella, Jeremy" <jeremy.compostella@...el.com>
Cc:	Ingo Molnar <mingo@...nel.org>, stefan.stanacar@...el.com,
	peterz@...radead.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, hpa@...or.com, bp@...en8.de,
	ard.biesheuvel@...aro.org, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote:
> Ingo Molnar <mingo@...nel.org> writes:
> >
> > Hm, can reboot notifiers do non-atomic allocations?
> The reboot notifier chain is a blocking notifier chain. AFAIK, it
> allows non-atomic allocation, right ?
 
I would assume so, yes.

> > Why is efivar_entry so huge?
> efivar_entry structure include two "big" arrays of 1024 bytes each for
> the EFI variable name and data.

Yeah. This is partially historical in that the EFI variable code has
always had these arrays.

But it's also that if you're dealing with EFI variables you always
want someplace to cache the data and name, so no one has ever proposed
to split out the data/name from struct efivar_entry.

We've never put them on the stack before either ;)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ