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: <54BFCE4D.2060806@redhat.com>
Date:	Wed, 21 Jan 2015 11:05:33 -0500
From:	Jon Masters <jcm@...hat.com>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	Mark Rutland <Mark.Rutland@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Will Deacon <Will.Deacon@....com>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	Rob Herring <robh@...nel.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Al Stone <al.stone@...aro.org>,
	Timur Tabi <timur@...eaurora.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
	"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Mark Brown <broonie@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Olof Johansson <olof@...om.net>,
	"christoffer.dall@...aro.org" <christoffer.dall@...aro.org>,
	"parth.dixit@...aro.org" <parth.dixit@...aro.org>,
	Leif Lindholm <leif.lindholm@...aro.org>
Subject: Re: [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for "acpi"
 and pass acpi=force to enable ACPI

On 01/21/2015 10:42 AM, Catalin Marinas wrote:
> On Wed, Jan 21, 2015 at 03:29:52PM +0000, Jon Masters wrote:
>> On 01/21/2015 10:23 AM, Catalin Marinas wrote:
>>> I have some questions for the ACPI and EFI folk:
>>>
>>> 1. When booting with ACPI, are the EFI run-time services required for
>>>    anything? If yes, Xen may have a bigger problem
>>
>> Yes. At least for some things. For example, installing an Operating
>> System would require that you make runtime services calls to set the
>> BootOrder/BootNext variables, and so on. Further, we use the GetTime
>> service and EFI based reboot to avoid having special drivers. I had
>> those added to SBBR as requirements for that reason.
> 
> So what would a kexec'ed kernel do here? Or we usually expect it to be
> short lived and doesn't need reboot, nor GetTime.

In the use case that I have, it'll use EFI Runtime Servies to handle
both the time of day (which it will need) and to subsequently reboot.
This is currently being worked on (integration into kdump).

> Xen is slightly more problematic but I wonder whether it could run a
> (paravirtualised) UEFI.
> 
>>> 2. Could a boot loader (either kernel doing kexec or Xen) emulate the
>>>    EFI system/config tables and still make them useful to the kernel but
>>>    without EFI_BOOT or EFI_RUNTIME_SERVICES?
>>
>> Yes. But again, without the other required pieces (including the
>> services function pointers in the systab which are required) you'd crash
>> soon after boot trying to make those calls.
> 
> My point was whether you can still pass information like RSDP address
> via EFI tables but explicitly disable runtime services so that the
> kernel won't try to make such calls (and crash).

Yes. As Graeme says, it works just to pass in the ACPI information and
turn off EFI *BUT* it does not work to say you have EFI and then not
provide the correct EFI services. To do so is out of spec, and in fact
it's one reason we weren't able to turn the GetTime service on generally
for x86 - some older x86 boxes didn't implement it originally (another
reason on our end we're requiring all of these services on day one so
that there won't be time for someone to miss them in firmware).

Jon.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ