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]
Message-ID: <da0e65ef-7c04-e274-2f15-a50daa8c4c8c@redhat.com>
Date:	Mon, 9 May 2016 00:13:22 -0400
From:	Jon Masters <jcm@...hat.com>
To:	Octavian Purdila <octavian.purdila@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Mark Brown <broonie@...nel.org>,
	Wolfram Sang <wsa@...-dreams.de>
Cc:	Joel Becker <jlbec@...lplan.org>, linux-acpi@...r.kernel.org,
	linux-efi@...r.kernel.org, linux-i2c@...r.kernel.org,
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
	irina.tirdea@...el.com
Subject: Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables

Hi Octavian,

Apologies for missing this earlier, just catching up on this thread...

On 04/19/2016 06:39 PM, Octavian Purdila wrote:

> This patch allows SSDTs to be loaded from EFI variables. It works by
> specifying the EFI variable name containing the SSDT to be loaded. All
> variables with the same name (regardless of the vendor GUID) will be
> loaded.

This sounds very useful during development. However, and using EFI
variables isn't so terrible, but I am concerned that this should be
standardized through ASWG and at least involve certain other OS vendors
so that the variable (GUID) can be captured somewhere. If not in the
spec itself, then it should be captured as an external ACPI resource on
the UEFI website with a clear pointer to the exact IDs to be used.

Can you confirm that's the intention? i.e. that you're allowing a
command line option for specifying the ID now because you intend to go
ensure that there is a standard one that everyone will use later?

I should check (but maybe you know) if the kernel is automatically
tainted by this codepath as well?

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ