linux-kernel - RFC: running out of x86 boot loader IDs

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-next>] [day] [month] [year] [list]

Message-ID: <49823683.6060201@zytor.com>
Date:	Thu, 29 Jan 2009 15:06:43 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	x86@...nel.org
Subject: RFC: running out of x86 boot loader IDs

The 4-bit values used to hold x86 boot loader IDs are near exhaustion. 
As a result, I'm proposing an extension protocol and will implement it 
in time for the next merge window unless there are objections.

The proposal will be as follows:

- The boot loader IDs (type_of_loader >> 4) E and F will be reserved:

	E - extended IDs
	F - special uses

   F is consistent with the current use of FF for "unknown".

- If the boot loader ID is E, the current pad1 field at 0x226 is 
repurposed as an extended loader ID.  The reason to use the pad1 field 
is that it is present in all headers since version 2.02.  The boot 
loader ID will simply be: ((extended ID + 0x10) << 4) + (version), where 
(version) as before is (type_of_loader & 15).  This is the value which 
will be reported in /proc/sys/kernel/bootloader_type.

The biggest question is probably: is there a need/desire for an extended 
version field, or is four bits enough for existing bootloader needs?

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