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: <512FC82B.40909@zytor.com>
Date:	Thu, 28 Feb 2013 13:12:11 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Robin Holt <holt@....com>
CC:	hpa@....com, Yinghai Lu <yinghai@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Revert commit 5dcd14ecd4 - breaks EFI boot with SLES11 elilo.efi

On 02/28/2013 01:09 PM, Robin Holt wrote:
>>
>> Sounds like ELILO needs to be fixed to pass the boot_params correctly.
>>
>> To support existing ELILO, it would be good to know exactly *which*
>> fields ELILO pass in as garbage (because it does, that is why ->sentinel
>> is nonzero) and use its bootloader ID to apply the proper brainwhack for
>> the legacy versions.
> 
> Any idea how I can dump that information?
> 

Look at the source code and look at what fields it actually initializes.
 Give us that list, and then we can work around elilo braindamage in the
kernel.

Then make it follow the boot spec:

> In 32-bit boot protocol, the first step in loading a Linux kernel
> should be to setup the boot parameters (struct boot_params,
> traditionally known as "zero page"). The memory for struct boot_params
> should be allocated and initialized to all zero. Then the setup header
> from offset 0x01f1 of kernel image on should be loaded into struct
> boot_params and examined. The end of setup header can be calculated as
> follow:
> 
>         0x0202 + byte value at offset 0x0201

... so we don't have to.

	-hpa

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