linux-kernel - Re: [PATCH V2] 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 16:33:54 +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 V2] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS

On 25.08.2014 15:07, Matt Fleming wrote:
> On Mon, 25 Aug, at 01:55:32PM, 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.
>> ...
>> [    0.000000] efi: mem53: type=2, attr=0xf, range=[0x000000011dba7000-0x000000011e600000) (10MB)
>> ...
>> [    0.000000] RAMDISK: [mem 0x11dba7000-0x11e5fffff]
>> ...
>> [    0.154933] Unpacking initramfs...
>> [    0.160990] Initramfs unpacking failed: junk in compressed archive
>> [    0.163436] Freeing initrd memory: 10596K (ffff88011dba7000 - ffff88011e600000)
>> ...
>>
>> Nevertheless, unpacking of the initramfs later on failed.
>> This is maybe caused by my buggy EFI BIOS and
>> commit 4bf7111f50167133a71c23530ca852a41355e739,
>> which enables loading the initramfs above 4G addresses.
>>
>> With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS,
>> which should do the same as before, but use the EFI logic to select the high memory range.
>  
> No, that's not correct. Your patch changes the semantics of
> efi_high_alloc(). The original version allocates from the top of memory
> down, so you always get the highest aligned address, that is no higher
> than 'max_addr'.
> 
> Your version allocates some address that isn't above 'max_addr', but it
> needn't necessarily be the highest possible address. The following is
> taken from the AllocatePages() documentation in the UEFI spec,
> 
>   "Allocation requests of Type AllocateMaxAddress allocate any available
>    range of pages whose uppermost address is less than or equal to the
>    address pointed to by Memory on input."
> 
> Note the part about allocating *any* available range.
> 
> Furthermore, there are more callers of efi_high_alloc() than the initrd
> loading case, and you've changed their behaviour with this patch.
> 
> I get where you're coming from, but this isn't the best way to solve
> this problem, sorry. NAK.
> 

So is that ok, if other callers of efi_high_alloc() get an address > 4GB?

Will the buggy EFI implementation work with the usage of the other caller's
allocated memory? Or will they run into the same issues as the initramfs loader?
--
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/