linux-kernel - Re: [PATCH 01/34] System Firmware Interface

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: <4E258C2D.2070808@redhat.com>
Date:	Tue, 19 Jul 2011 09:52:45 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	linux-kernel@...r.kernel.org
CC:	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 01/34] System Firmware Interface

On 07/19/2011 09:25 AM, Andi Kleen wrote:
> Playing the devils advocate here, but this is really unclear...
>
>   

Sorry, I'll try to be more specific.

>> There is some additional information I'd like to throw out here as
>> well.  SMBIOS also provides information on the system state after the
>> BIOS/EFI is finished and before the kernel has been booted.  This has
>> been *invaluable* to me when diagnosing some wonky hardware from OEMs. 
>>     
> Hmm this is for SMBIOS tables that changes at runtime?
> Why exactly is the kernel booting a good point to dump that?
>
>   

Let me back up :) as I clearly didn't do a good job of explaining this.

I have systems/have had systems in which NO kernel would boot because of
faulty hardware.  That hardware was identified as bad during the BIOS
POST but no information on it could be determined because we didn't make
it very far through boot :/.  As you know Andi, booting with bad memory
or a bad cpu is excruciatingly difficult to diagnose.

The SMBIOS does provide access to a system log in which details on
failed hardware (again, failed hardware having been identified by the
BIOS) and that information was immensely useful to me during the system
boot.  (see the Type 15 System Event Log Structure).

Plugging that into the existing "dmi" code was a headache.  The code is
just not laid out to make expansion of dmi devices easy.

>   
>> I want to expand the SMBIOS layer to dump that information out when I
>>     
> What information exactly?
>
> And dumping = print to system log?
>   

Yes, to the system log.

>   
>> tl;dr: There are some other useful bits of SMBIOS we could take
>> advantage of but the current "dmi" layer is difficult to work with.
>>     
> Like what?
>
>   

Like the above example ;) ... but there are other things like the type
of memory in the system from a HW debug point of view become important. 
My #1 goal is to get the SMBIOS version # exported via sysfs and to get
the type 15 stuff output as debug info.

P.

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