linux-kernel - Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

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

Date:	Sun, 8 Mar 2015 19:21:30 +0100
From:	Jean Delvare <jdelvare@...e.de>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	"Ivan.khoronzhuk" <ivan.khoronzhuk@...ballogic.com>,
	dmidecode-devel@...gnu.org,
	Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
	Matt Fleming <matt.fleming@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Mark Salter <msalter@...hat.com>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry
 point area raw attribute

On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 18:11, Jean Delvare <jdelvare@...e.de> wrote:
> > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> >> And the 32-bit entry point could well be 3.0 anyway, if
> >> it uses any of the new enum values for the data items that were
> >> undefined before 3.0.
> >
> > This is true but irrelevant to the discussion.
> 
> To clarify, the SMBIOS 3.0 spec explicitly allows the 32-bit entry
> point to either point to the same table as the 64-bit entry point, or
> point to a separate table, in which case the contents of the latter
> should be a subset of the contents of the former. It doesn't specify
> anything about the version number to be used in the 32-bit entry point
> in case they point to separate tables. This means the presence of the
> 32-bit entry point does not guarantee that the table contents are
> compatible with the pre-3.0 tools. So perhaps it would make sense to
> export the 32-bit entry point separately only if it points to a
> different table, and has a different version number?

The situation is exactly the same as with every new version of the
SMBIOS specification: tools need to be updated to support the new
enumerated values and the new fields, but are able to decode all the
rest just fine. The only thing that would make it a different situation
is if something in the 3.0 specification is incompatible with previous
specifications. But I'd be very surprised if this is the case, as I am
sure the DMTF people care about compatibility.

And I can't see any practical case where the vendor would want to not
implement version 3.0 in the _SM_-pointed table if they do so for the
_SM3_-pointed table. That's more work for them and serves no purpose,
as everything that could be encoded in old versions can also be encoded
in newer versions.

So, no, I still don't think there is any value in exposing two entry
points in sysfs.

-- 
Jean Delvare
SUSE L3 Support
--
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/