Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED

Andi Kleen
2004-05-01T15:01:39Z

> -- This information is, in the very near future, _not_ going to be
> static anymore. There will be systems that update the information in
> dynamically during SMIs.

That's fine - /dev/mem can handle that too. An user will have to
poll for changes anyways, so having it it /proc does not have
any advantages.

I would see the sense if there was an interrupt to notify the
the system of changes, but there isn't ;-)

>
> -- SMBIOS consists of two things, the table entry point and the table
> itself. The table entry point is always in 0xF0000 - 0xFFFFF.
> Traditionally, the actual table has been here as well. BIOS is running
> out of space here and future systems are moving this information to high
> memory. /dev/mem will not allow access to memory above top of system
> RAM.

mmap /dev/mem of high memory should work. Did you try it?
For read/write it would be fairly easy to add, just needs a kmap.

> -- Red Hat has a /dev/mem patch in their tree that restricts access to
> RAM above 1MB.

That's their breakage.

Clearly it is a useless change anyways because you can easily circumvent
it by just accessing any bus master hardware in the system.

> This procfs/sysfs driver allows access to smbios information by
> non-root, non CAP_SYS_RAWIO users. I've had several occasions where I
> have been bitten by having to be root to read smbios when I did not need
> root for anything else.

That is what suid root was invented for. It is a fairly nifty mechanism,
did you ever try it? I know that some sysadmins try to get away from
it, but that is clearly misguided because it is not any more dangerous than
adding more kernel code.

-Andi