* Purpose of dmi-sysfs kernel module @ 2014-05-14 9:23 Jean Delvare 2014-05-14 15:52 ` Mike Waychison 0 siblings, 1 reply; 5+ messages in thread From: Jean Delvare @ 2014-05-14 9:23 UTC (permalink / raw) To: Mike Waychison, Bjorn Helgaas; +Cc: Greg Kroah-Hartman, linux-kernel Hi Mike, Bjorn, 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]? I read on LWM [2] that you were mostly interested in type 15 records, to gain access to the System Event Log information. Well, "dmidecode -t 15" does exactly that. It may be a bit late now but if anything is missing from dmidecode, I would rather add it there than implement a separate solution. [1] http://www.nongnu.org/dmidecode/ [2] http://lwn.net/Articles/429427/ Thanks, -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dmi-sysfs kernel module 2014-05-14 9:23 Purpose of dmi-sysfs kernel module Jean Delvare @ 2014-05-14 15:52 ` Mike Waychison 2014-05-14 19:23 ` Jean Delvare 0 siblings, 1 reply; 5+ messages in thread From: Mike Waychison @ 2014-05-14 15:52 UTC (permalink / raw) To: Jean Delvare; +Cc: Bjorn Helgaas, Greg Kroah-Hartman, linux-kernel Hi Jean, On Wed, May 14, 2014 at 2:23 AM, Jean Delvare <jdelvare@suse.de> wrote: > Hi Mike, Bjorn, > > 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. 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. > I read on LWM [2] that you were mostly interested in type 15 records, > to gain access to the System Event Log information. Well, "dmidecode -t > 15" does exactly that. It may be a bit late now but if anything is > missing from dmidecode, I would rather add it there than implement a > separate solution. > > [1] http://www.nongnu.org/dmidecode/ > [2] http://lwn.net/Articles/429427/ > > Thanks, > -- > Jean Delvare > SUSE L3 Support ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dmi-sysfs kernel module 2014-05-14 15:52 ` Mike Waychison @ 2014-05-14 19:23 ` Jean Delvare 2014-05-14 22:51 ` Mike Waychison 0 siblings, 1 reply; 5+ messages in thread From: Jean Delvare @ 2014-05-14 19:23 UTC (permalink / raw) To: Mike Waychison; +Cc: Bjorn Helgaas, Greg Kroah-Hartman, linux-kernel 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'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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dmi-sysfs kernel module 2014-05-14 19:23 ` Jean Delvare @ 2014-05-14 22:51 ` Mike Waychison 2014-05-15 8:48 ` Jean Delvare 0 siblings, 1 reply; 5+ messages in thread From: Mike Waychison @ 2014-05-14 22:51 UTC (permalink / raw) To: Jean Delvare; +Cc: Bjorn Helgaas, Greg Kroah-Hartman, linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dmi-sysfs kernel module 2014-05-14 22:51 ` Mike Waychison @ 2014-05-15 8:48 ` Jean Delvare 0 siblings, 0 replies; 5+ messages in thread From: Jean Delvare @ 2014-05-15 8:48 UTC (permalink / raw) To: Mike Waychison; +Cc: Bjorn Helgaas, Greg Kroah-Hartman, linux-kernel Hi Mike, Le Wednesday 14 May 2014 à 15:51 -0700, Mike Waychison a écrit : > On Wed, May 14, 2014 at 12:23 PM, Jean Delvare <jdelvare@suse.de> wrote: > > 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. In case I wasn't clear enough: my concern isn't that dmi-sysfs is too dumb, but that it is doing too much. > 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. That's what I would expect the dmi-sysfs kernel driver to do for every table or relevant I/O area: pass the data through to user-space and let user-space decode it. > > 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 am not questioning the fact that it solves a real problem. I just don't think it was the best way to solve it. And I feel a bit sad that the point was not even raised on the dmidecode-devel list. > 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. With the current implementation of dmi-sysfs, that would require a significant amount of extra code in dmidecode, to walk /sys/firmware/dmi/entries, parse all the files there and inject all the pieces into the existing decoding loop. I'm not going to do that, sorry. Now if dmi-sysfs would simply export raw tables through sysfs as acpi does, it would be truly trivial to hook dmidecode to it as a preferred alternative to reading from /dev/mem. That, I would be happy to implement in dmidecode. -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-05-15 8:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-14 9:23 Purpose of dmi-sysfs kernel module Jean Delvare 2014-05-14 15:52 ` Mike Waychison 2014-05-14 19:23 ` Jean Delvare 2014-05-14 22:51 ` Mike Waychison 2014-05-15 8:48 ` Jean Delvare
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).