linux-kernel - Re: 2.6.39.1 immediately reboots/resets on EFI system

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: <4DF2A81C.7000902@kernel.org>
Date:	Fri, 10 Jun 2011 16:26:20 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Maarten Lankhorst <m.b.lankhorst@...il.com>,
	Jim Bos <jim876@...all.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: 2.6.39.1 immediately reboots/resets on EFI system

On 06/10/2011 04:03 PM, Matthew Garrett wrote:
> On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
> 
>> the problem is : overlapping between kernel code with boot services code.
> 
> SHouldn't checking against the iomem resource map avoid that?
> 
>> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
>> try to find usable range for decompressed kernel ( too early )...
>>
>> So solution will be:
>> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
> 
> That's acceptable if we can't find a better solution.

good.

> 
>> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
> 
> This isn't an option.
> 
> The medium-term fix is to ensure that the bootloaders don't put the 
> kernel on top of boot services code. 

that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.

> The long-term fix is to perform the 
> SetVirtualAddressMap transition in either the bootloader or the kernel 
> entry point.

that is sane and clean workaround for those systems with buggy fw.

> But the short-term fix here is to allocate all boot 
> services regions that don't overlap with the kernel. That'll fix some 
> number of machines and shouldn't break any existing ones.

that is questionable and dangerous. before SetVirtualAddressMap, some function in boot service could be called,
those data or code for boot services could be overlapped kernel. so kernel code could be damaged by those calling.

also that will make our kernel code more messy.

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