Messages in this thread | | | Date | 1 May 2004 17:01:36 +0200 | Date | Sat, 1 May 2004 17:01:36 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED |
| |
> -- 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |