Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
Original issue reported on code.google.com by
mabr...@gmail.com
on 26 Apr 2010 at 2:17