lkml.org 
[lkml]   [2014]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Purpose of dmi-sysfs kernel module
    Hi Jean,

    On Wed, May 14, 2014 at 12:23 PM, Jean Delvare <jdelvare@suse.de> wrote:
    > 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@suse.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 tried to make dmi-sysfs be as dumb as possible, which is why the
    code doesn't try very hard to actually interpret the individual
    entries, and instead only exposes them as "raw" files. The only
    "specialized" type (that actually decodes the entry in kernel-land) is
    type 15, as this entry provides a level of indirection to get at the
    system log (which is either elsewhere in raw /dev/mem memory, or only
    accessible behind IO ports). Again, in this case, only the raw system
    event log is exposed and the kernel makes no attempt to parse this
    log, it only exposes the raw read-only bytes.

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

    Well, it solves some real problems for us while locking down userland
    access to /dev/mem and iopl.

    I have had several folks ask me in the past as to why dmidecode
    doesn't work when these facilities are removed from userland, and
    dmi-sysfs has proven to be a workable alternative for most. That
    said, dmidecode is the de facto method people use for getting at this
    data, and I have no intention on replacing it -- rather, I was hoping
    that at some point dmidecode could be updated to understand how to
    read the raw sysfs file in lieu of requiring superuser privileges, but
    I haven't had the opportunity or need to make this happen myself.

    Mike Waychison


    \
     
     \ /
      Last update: 2014-05-15 01:41    [W:3.158 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site