linux-kernel - Re: [Patch] acpi: introduce "acpi

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, 10 Mar 2011 18:50:19 +0000
From:	Matthew Garrett <mjg@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Amerigo Wang <amwang@...hat.com>,
	linux-kernel@...r.kernel.org, Takao Indoh <tindoh@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Len Brown <lenb@...nel.org>, linux-doc@...r.kernel.org,
	linux-acpi@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

On Thu, Mar 10, 2011 at 09:50:28AM -0800, Eric W. Biederman wrote:

> Move all EFI calls that the kernel does (on x86) into a special section
> of the bzImage that the bootloader can run.  This works very well for
> the x86 BIOS and it should also work very well for EFI.  Among other
> things by having a special 32bit and a special 64bit section this solves
> the what flavor of EFI problem are we running on problem.

There's no benefit in calling any EFI methods in the kernel if we have 
no intention of making further calls later. If we intent on making 
further calls later then this approach doesn't work well.

> Never perform any EFI calls once the kernel is initialized, last I
> looked all of the EFI calls that were interesting to perform at runtime
> were a subset of what ACPI can do, and ACPI is a easier to deal with
> long term.

With the exception of reboot, I don't see any overlap between the EFI 
runtime services and ACPI.

> Kexec and kdump can easily pass the gather data from the first kernel to
> the second kernel like we do for the normal bios paramsters today.

Doing that's not a problem. The real problem is that passing a virtual 
map to EFI is a one-shot event. The information we need to provide to 
the second kernel isn't a set of parameters - it's the whole memory map, 
and we need to depend on the kernel to be able to set up the same map 
again.

> As a fly in the ointment that leaves the question of how do we set EFI
> variables.  It is needed functionality when we are installing, and
> occasionally nice to have.  But it is a very rare slow path.  I would
> isolate the EFI after the kernel has booted to exactly to that one case.
> Either with a special driver or a some flavor of virtualization from
> userspace like we used to do for video card initialization.

Also capsule updating (not that we implement that at present, but 
vendors will want it). But, again, if you want to push this out to some 
sort of magic then we can just drop pretty much all of the kernel EFI 
support.

> The current design of EFI in the x86 kernel is crap.  We seem to have
> advanced past the early adopter hack anything together to make it work
> stage.  So let's stop adding hacks and write something that won't give
> us a long term support problems.

We're using EFI exactly as it's designed to be used at the moment. The 
only problem is that nobody ever thought people would try to do anything 
like booting one OS into another OS that has different ideas about 
address space layout, but that's a problem with the spec and not our 
implementation.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/