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:	Wed, 14 May 2014 21:23:47 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Purpose of dmi-sysfs kernel module

Hi Mike,

On Wed, 14 May 2014 08:52:36 -0700, Mike Waychison wrote:
> On Wed, May 14, 2014 at 2:23 AM, Jean Delvare <jdelvare@...e.de> wrote:
> > Sorry for joining the party a little late but I am just discovering the
> > dmi-sysfs kernel module. I have to admit that I am very curious about
> > why it was needed. What does it let you achieve that you couldn't
> > already do with dmidecode [1]?
> 
> The downside to using dmidecode is that (at least at the time), it
> involved requiring giving access to /dev/mem to the binary so that it
> could grub around in raw memory looking for the records.

This is still the case indeed.

> dmi-sysfs
> provides an alternative that allows for kernel-parsed entries to be
> exposed to userland without having to expose /dev/mem and raw IO which
> is insecure.

Thanks for the explanation. But if access to /dev/mem was your only
concern, your solution seems somewhat overkill. You could have just
exposed the raw SMBIOS entry point and DMI table through sysfs, pretty
much like ACPI does, and leave the rest to dmidecode (or libsmbios.)
That would have avoided reimplementing part of dmidecode and creating
yet another interface to DMI data.

I'm not maintaining dmi-sysfs, I'm not even using it so far, so I don't
really care, but to be honest I am quite surprised that it was accepted
into the kernel.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ