RE: PATCH: /dev/nvram cleanups.

Riley Williams (rhw@MemAlpha.CX)
Thu, 29 Jul 1999 12:36:36 +0100 (GMT)


Hi there.

>>> What I meant was that normal users should not be able
>>> to read the fields that contain the encoded password.

>> The permissions of /dev/nvram should enforce the access
>> policy IMHO.

> Seems reasonable to me.

True.

> This just leaves the issue of sizing the nvram.

> Maybe this can be determined by checking the BIOS
> manufacturer & version. (Admittedly this could be a
> large table, but this part is in userspace anyhow).
> If the manufacturer or version are not supported, just
> make the first 50 bytes available (as it is now),
> otherwise size it accordingly from the lookup table.

Alternatively, why not use the fact that the chips with only
0-63 as valid addresses effectively fold back 64-127 to 0-63
to auto-detect that fact. Something like the following:

typedef unsigned char BYTE;
typedef unsigned short int WORD;

#define RTC_SECONDS 0

WORD cmos_ram_size(void)
{
WORD limit = 64;
BYTE new, old;

while (limit < 32768) {
old = read_rtc(limit+RTC_SECONDS);
sleep( 1 );
new = read_rtc(limit+RTC_SECONDS);
if (old != new)
break;
limit <<= 1;
}
return (limit);
}

Assuming that the returned value indicates the size of the CMOS's
address space, and that read_rtc(addr) returns the current value of
the byte at the RTC's register with the specified address, that will
correctly handle CMOS chips with up to 32k of CMOS RAM. I would tend
to assume that chips with larger RAM are not currently available, but
if they are, it's not hard to extend the above to support them.

The above code makes the following assumptions:

1. The register at address 0 returns the current second as
stored in the RTC. I have NOT checked that this is the
correct offset, but if not, just put the relevant offset
in the definition of RTC_SECONDS.

2. The result of the sleep(1) call will always be sufficient
for the second counter to tick over.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/