linux-kernel - Re: [PATCH] fix DMI for EFI

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: <49AE9850.9020103@redhat.com>
Date:	Wed, 04 Mar 2009 10:03:44 -0500
From:	Brian Maly <bmaly@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Yinghai Lu <yinghai@...nel.org>, linux-kernel@...r.kernel.org,
	ying.huang@...el.com
Subject: Re: [PATCH] fix DMI for EFI

>Hm, could we ever find ourselves in the positition of having to 
>access the DMI strings table in the EFI init code, to implement 
>a quirk? I think that's quite plausible.

>OTOH, with some DMI quirks in EFI tables it's a bit of a chicken 
>and egg problem. Can DMI strings ever be outside of EFI tables 
>on EFI systems?

>	Ingo

Right now it is EFI that loads the dmi tables (and all other tables such 
as ACPI), so it is a chicken and the egg. I think that if dmi is ever 
needed by EFI, the dmi scan will have to be moved inside efi_init. We 
could move the dmi scan into efi_init and do the dmi scan the moment we 
have the dmi table. Thats really the soonest point we could scan on EFI 
systems. Im OK with moving dmi to efi_init if you prefer.

Brian

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