linux-kernel - Re: [PATCH] x86, efi: Break up large initrd reads

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, 15 Dec 2011 00:33:54 +0100
From:	Maarten Lankhorst <m.b.lankhorst@...il.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt@...sole-pimps.org>,
	Matthew Garrett <mjg@...hat.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Mike Waychison <mikew@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Jones <pjones@...hat.com>
Subject: Re: [PATCH] x86, efi: Break up large initrd reads

Hey,

On 12/13/2011 07:26 PM, H. Peter Anvin wrote:
> On 12/12/2011 03:10 PM, H. Peter Anvin wrote:
>> On 11/25/2011 12:48 AM, Matt Fleming wrote:
>>> On Fri, 2011-11-25 at 02:37 +0100, Maarten Lankhorst wrote:
>>>> The efi boot stub tries to read the entire initrd in 1 go,
>>>> however some efi implementations hang if too much if asked
>>>> to read too much data at the same time. After some
>>>> experimentation I found out that my asrock p67 board will
>>>> hang if asked to read chunks of 4mb, so use a safe value.
>>>>
>>>> From elilo source code:
>>>> /*
>>>>  * We load by chunks rather than a single big read because
>>>>  * early versions of EFI had troubles loading files
>>>>  * from floppies in a single big request.  Breaking
>>>>  * the read down into chunks of 4KB fixed that
>>>>  * problem. While this problem has been fixed, we still prefer
>>>>  * this method because it tells us whether or not we're making
>>>>  * forward progress.
>>>>  */
>>>>
>>>> While the comment says 4KB, it's using 4 * EFI_PAGE_SIZE (16KB),
>>>> so I went by the safest route of following elilo here.
>>>>
>> I'm going to NAK this, because I think the performance impact is too
>> severe.  I would like to set the cap at 1 MiB for now, unless we can
>> identify platforms where *that* is known to fail.
>>
>> Maarten, would you be willing to rev your patch?  Furthermore, please
>> make the maximum chunksize a define.
>>
> One more thing, Maarten: could you please provide the full DMI
> information of the affected system?
>
When I was testing in increments of 1 mb, 4 mb was the magic number that caused a hang.
My system runs fine with 1mb and my original patch used that as blocksize.

What dmi information do you need? Top 2 entries from dmidecode, in case that's sufficient:

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: To Be Filled By O.E.M.
        Product Name: To Be Filled By O.E.M.
        Version: To Be Filled By O.E.M.
        Serial Number: To Be Filled By O.E.M.
        UUID: 03000200-0400-0500-0006-000700080009
        Wake-up Type: Power Switch
        SKU Number: To Be Filled By O.E.M.
        Family: To Be Filled By O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASRock
        Product Name: P67 Pro3
        Version:                      
        Serial Number:                      
        Asset Tag:                      
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis:                      
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

But I suspect the other p67 boards from asrock would be affected by the 4mb crash  too.

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