I have a need to read/write to the battery-backed CMOS RAM from Windows with Secure Boot enabled.
Do I have any options to do so from user-space? If not, what’s the most lightweight solution you can recommend?
Do I have any options to do so from user-space?
Dude… I didn’t know one had the option to do this at all … I had always assumed this was the exclusive province of the BIOS, and that he was the only one who understood what was stored and its format. So, I’ll be curious to hear replies.
Peter
In this case I am the BIOS writer and need to update a checksum that wasn’t
updated properly. I can’t update the BIOS while the checksum is incorrect.
It’s not anything magical. Just some basic IO on ports 70/71 & 72/73.
Can I create a lightweight driver that simply gives me access to read/write to the I/O Space addresses of interest? Then have my application load the driver when it starts, do my work, then unload it when it exits?
Shane_Corbin wrote:
Can I create a lightweight driver that simply gives me access to read/write to the I/O Space addresses of interest? Then have my application load the driver when it starts, do my work, then unload it when it exits?
The older WDKs had a sample called PortIO that was designed for exactly
this purpose. It was in at Windows 7, but I see it has been removed now.
It doesn’t actually give you user-mode permission to write the I/O
ports. That involves changing the CPU’s I/O permission mask, which is
possible but dangerous. The sample just provides ioctls to read and
write the ports.
@Shane_Corbin said:
I have a need to read/write to the battery-backed CMOS RAM from Windows with Secure Boot enabled.
Do I have any options to do so from user-space? If not, what’s the most lightweight solution you can recommend?
AFAIK, there’s no way to do this from user mode.
In the distant past, you could do it from kernel mode with HalSetBusDataByOffset(), using the Cmos bus type. Not sure if this still works in recent versions of Windows. The function still exists, but I don’t know if the Cmos bus type is still implemented.
Given a choice, using the Hal function is preferable to banging on the RTC I/O ports directly because it lets Hal serialize the access. Devices with an index/data register pair, like the RTC, can’t be used safely by multiple threads.
I did almost the same thing about 10 years back on Win2003. As I recall, I just used the trusty “DOS” DEBUG program and piped in a sequence of commands to INP and OUTP the appropriate sequence. I recall being surprised that it actually worked!