linux-kernel - Re: [PATCH] efi_high_alloc: use EFI_ALLOCATE_MAX

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:	Mon, 25 Aug 2014 13:10:50 +0200
From:	Harald Hoyer <harald@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>
CC:	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS

On 25.08.2014 12:34, Matt Fleming wrote:
> (Adding linux-efi to Cc)
> 
> On Fri, 22 Aug, at 03:48:23PM, harald@...hat.com wrote:
>> From: Harald Hoyer <harald@...hat.com>
>>
>> On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
>> following memory regions:
>>
>> 0x0000000000100000 - 0x0000000020000000
>> 0x0000000020200000 - 0x0000000040000000
>> 0x0000000040200000 - 0x00000000d2c02000
>> 0x00000000d6e9f000 - 0x000000011e600000
>>
>> and decided to allocate 2649 pages at address 0x11dba7000.
>> As I understand this is the physical address and this machine only
>> has 4GB mem!!
>  
> Yeah, but RAM doesn't necessarily start at the physical address
> 0x000000000000. Nor is it necessarily contiguous.
> 
> In other words, it's perfectly legitimate to allocate at physical
> addresses above 0x10000000 if the above memory map tells us RAM lives
> there.

yeah, I thought so, too :)

> 
>> Nevertheless, unpacking of the initramfs later on failed.
>> This was mainly caused by commit 4bf7111f50167133a71c23530ca852a41355e739,
>> which enables loading the initramfs above 4G addresses.
>>
>> With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS.
>> This returns 0x00000000d2c02000 on my machine and the resulting
>> address at which the initramfs is loaded is then 0x00000000d21a9000,
>> which seems to work fine.
> 
> Well yeah, that makes sense because you've obviously got a buggy EFI
> firmware that doesn't load things correctly above 4GB. It turns out that
> this is a common bug.
> 
> Can you try the following patch and see whether booting with
> efi=nochunk results in a functioning initramfs? I've had some success
> with disabling the chunking workaround when reading files in the EFI
> boot stub. Also, including a copy of a dmesg would be helpful.
> 

Here we go... dmesg attached, but uncompression failed.


View attachment "efi-dmesg.txt" of type "text/plain" (51536 bytes)