Integration of WinRing0 into the project (or a replace with a new driver).

[GoogleCodeExporter]

Hello !

Have you noticed, that the WingRing0 lib is no longer present? I registered
this just yesterday, looking for help to compile the driver by myself [If I
use open source, I always try to being able, to manage the project by
myself, because ONE DAY, I'll possibly depend completely on it ;-) ].

Best regards!

++mabra

Original issue reported on code.google.com by mabr...@gmail.com on 26 Apr 2010 at 2:17

[GoogleCodeExporter]

Yes I noticed this, and I think I will have to continue the development of a 
driver
(or a replacement) as part of the Open Hardware Monitor project.

There are also a few issues about WinRing0 that should be fixed:

- Security: Either restrict the driver interface to one that is safe to be used
without administrator rights, or require administrator rights to access the 
driver.

- Add higher-level commands to the driver interface to reduce the overhead for 
common
read/write LPC operations.

Original comment by moel.mich on 26 Apr 2010 at 6:02

• Changed title: Integration of WinRing0 into the project (or a replace with a new driver).
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

A new version 2.0.0 of WinRing0 has been released, but the only thing that is 
still
supported by the driver is the reading of MSR (model-specific-registers). As 
far as I
can understand the reason behind this, is to reduce the security problems of the
earlier version. 

I see the security problem in earlier versions, but the version 2.0.0 is still 
not
very useful for the Open Hardware Monitor project. We need access to PCI 
devices to
read the temperature of AMD CPUs and some kind of port I/O to read the mainboard
super I/O chips.

Original comment by moel.mich on 10 May 2010 at 7:59

[GoogleCodeExporter]

Restricted the access to the driver by changing the ACL of the driver device 
after starting it (revision r271). Once a new driver is written this should be 
done in the driver when creating the device using IoCreateDeviceSecure 
(http://www.microsoft.com/whdc/driver/security/drvsecure.mspx).

Original comment by moel.mich on 1 Nov 2010 at 8:52

[GoogleCodeExporter]

How privileged are the functions that OHM uses to access hardware sensors and 
system information?
Would it be feasible to put (some) functionality into a system service?
Or is there, maybe, another way of accessing sensors?

If kernel mode is required, this poses several problems. Hardware modules would 
have to be rewritten in C or C++ and an access model would be necessary to 
avoid security issues. Also, a developer certificate must be obtained or they 
driver would not be installable.

Sounds like a lot of work.

Original comment by onit...@gmail.com on 6 Dec 2010 at 1:34

[GoogleCodeExporter]

The Open Hardware Monitor needs MSR, I/O port and PCI register access (all 
requiring kernel mode). Access to the CPU MSRs is required CPU clocks reading 
and Intel core temperatures, I/O port access for the mainboard super I/O chips, 
and PCI register access for AMD CPU temperature.

Accessing the SMART data of hard disks requires administrator rights, but no 
additional driver so far.

All except the GPU monitoring code could be put into a system service. The 
Windows session 0 isolation prevents any access to the GPU from a service, 
neither NVAPI nor ADL can be accessed in session 0.

I have added the ISuperIO interface some time ago to keep an abstraction layer 
in the code. So anything behind that interface could be moved into a kernel 
driver if required (of course ISuperIO.ReadGPIO and ISuperIO.WriteGPIO 
currently used only for some strange ASRock mainboards would have to be dropped 
then). But at the moment I don't really see enough advantage in moving all 
hardware accessing code into a kernel driver, as long as we still need admin 
rights for other things (like SMART access). 

To remove the admin rights requirement on the Open Hardware Monitor process one 
would need to move all kernel mode stuff into the driver and all the SMART and 
WMI code into a service. But because of the session 0 isolation problem, not 
all monitoring code can be moved into a service, leaving things split up into 3 
locations (driver, service, main process), which I find a bit ugly and 
difficult to handle. Above all when we still want easy portability, and the 
option to run the application without installing anything.

And yes, the code certificate is an additional obstacle, not really helping to 
simplify things.

Original comment by moel.mich on 6 Dec 2010 at 7:49