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

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

Hi Ivan,

On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> On 03/05/2015 09:46 AM, Jean Delvare wrote:
> > It's not just two tables (I don't expect a lot of BIOSes to provide two
> > tables in practice, and they would have essentially the same format
> > anyway) but more importantly two entry points. The _SM3_ entry point is
> > brand new and most applications (including dmidecode) don't support it
> > yet. It doesn't matter if the kernel itself can parse it, as it passes
> > the raw entry point to applications anyway.
> >
> > It happens that we are introducing this new sysfs raw interface at the
> > same time _SM3_ is being introduced, so we do not have to care about
> > backwards compatibility. Both the kernel and dmidecode will need to be
> > updated to support the new interface, so we can keep things simple and
> > let the kernel expose only the best entry point.
> >
> > If the sysfs raw interface was already present at the time _SM3_
> > support was being added, then we would have had to present both entry
> > points for backwards compatibility. And if some _SM4_ entry point is
> > ever added in the future with a new format, we will have to export it
> > as a new sysfs attribute so as to not break compatibility.
> >
> > As a summary, I agree that a single entry point file is OK for now, but
> > only because we are lucky that the timing is right.
> 
> Despite of timing is right.
> 
> The specification doesn't oblige firmware to provide two entry points.
> An implementation may provide either the 32-bit entry point or the 64-bit
> entry point, or both. For compatibility with existing SMBIOS parsers, an
> implementation should provide the 32-bit entry point, but it's not required.

I expect most implementations will do, as it's trivial to implement.

> Another case if specification requires to provide two entry points. Then 
> you can
> be sure in backward compatibility. But at least for now you can't.
> 
> It's obvious, if kernel found two entry points then it can create two 
> sysfs attributes.
> But, what kernel should do in case if only one new entry point is present.
> Generate entry point of old version..., sorry but it's bad idea. At 
> least because
> where guarantee that we have enough information for this. Only field we 
> can bring
> thought entry point versions is magic string _SM*_, and based on it, if util
> don't support new version it can warn. It's used for differ versions and
> there is nothing we can do more.

I agree that the kernel should not fake an entry point which does not
exist (I'm not sure if you misunderstood me but I never suggested that.)

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