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: <20160810123058.GB3204@gmail.com>
Date:	Wed, 10 Aug 2016 14:30:58 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Mario Limonciello <mario_limonciello@...l.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Borislav Petkov <bp@...en8.de>,
	Matt Fleming <mfleming@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] Allow the trampoline to use EFI boot services RAM


One side note:

* Andy Lutomirski <luto@...nel.org> wrote:

> This series fixes it the other way: it allow the trampoline to live
> in boot services memory.  It achieves this by deferring the panic
> due to failure to reserve a trampoline until early_initcall time
> and then adjusting the EFI boot services quirk to reserve space
> for the trampoline if we haven't already found it a home.

>   x86/efi: Allocate a trampoline if needed in efi_free_boot_services()

Btw., this means that we first try to allocate the trampoline the old fashioned 
way, and in the rare cases this fails we allocate it from the EFI data area, 
right?

This is problematic from the probability management POV: we are creating a rare 
piece of code that will run only on a select few systems.

I think it would be much better to allocate the trampoline from the EFI area on 
all EFI systems by default. Is there any reason why that would not work?

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ