XPost: alt.comp.os.windows-11
On Thu, 3/13/2025 5:54 PM, Lawrence D'Oliveiro wrote:
The parallels between PC antivirus software and the body’s immune
system know no bounds. Here’s another one: sometimes the immune system mistakenly identifies some of the body’s own cells as the enemy, and proceeds to destroy them.
This has happened with Windows antivirus software before, and here’s another case <https://www.theverge.com/report/629259/winring0-windows-defender-fan-control-pc-monitoring-alert-quarantine>:
a privileged kernel-level toolkit used by many monitoring and
fan-control apps is now being identified by Windows Defender as
malware, and the apps that install it are being blocked.
Apparently the open-source “WinRing0” toolkit in question has known vulnerabilities. But these vulnerabilities have already been patched
in a newer version. However, the new version cannot be deployed until Microsoft issues a digital signature for it. Which it will not do
without charging some hefty fee. Which the developers in question
cannot afford to pay.
Do you think maybe the entire Windows ecosystem is fundamentally
hostile to open-source software?
It's good to see you take security seriously, by
looping in the COLA group in your post.
This is an example of how the Speedfan author provided
Ring0 access to get at the hardware monitor.
[Picture]
https://i.postimg.cc/kG1nDNKM/Speedfan-Ring0.gif
The Speedfan author, got some company to sign his
driver for usage on 64-bit OSes. Speedfan, as far as I know,
is no longer under active development. And neither
Windows nor Linux has anything to read out the hardware
monitor on three of my computers here.
All three machines, have automated fan control and
a graphic control in UEFI, for controlling fan speed.
My daily driver, which is currently an 8C 16T runs
cool enough, the fan control doesn't even engage
(the fan speed never changes). Whereas the monster
machine, the fan adjustments are quite active in UEFI.
Via SMM/SMI, the fan can be adjusted 30 times a second.
I would guess the best "health indicator" for the OS, would
be the details of how CPU-Z works. It seems to be self-signed
(by CPUID corporation). That's not using a Microsoft signature,
and it is also not flagged when I run it.
But in the case of Speedfan, we see an example of what
the hobbyists were doing. The "giveio.sys" file is very
small, and as I understand it, there is no source code
available for it. Hobbyists hand it from one to another,
shrug... and ship. That's the way things used to be done.
And part of the incentive for blocking a lot of the
materials, is they are the subject of drive-by attacks.
There are exploits that take advantage of the *installer*
installing these things. For example, I had an Asus
AISuite driver in my System32 folder, I didn't know it
was there, AISuite III was not on the machine (having
been removed years ago), but the driver did not get
removed. It was not classed as HackerWare, but never the
less a status message from Windows Defender appeared,
saying "you should remove this". And I agreed, that
a stub driver serving no purpose, should not be left in
the system.
Some of the low-level hacks on Windows, they set the
Hidden attribute on the .sys file. This prevents
people from identifying materials of this sort by
"casual inspection". There is some small amount of
value, to having a dialog report the lack of hygiene.
I do not know how this doom-and-gloom scenario is
supposed to play out. I have materials here, not
signed by Microsoft, but signed by someone else,
and at the moment... they still work, and nothing
squeaks or beeps.
There is another way to gain access, and that is via
ACPI Object. Asus has a hardware ACPI object for
hardware monitor access, and the Asus AISUite hardware
monitor has been using that for maybe fifteen years or more.
And that's not supposed to have the same risk model
as a "giveio.sys" 5KB executable Ring0 thing. But as I
understand it, there was some sort of drive-by issue
with the Asus materials.
Asus also attacks the machine, from UEFI, and offers
to install software into your newly installed OS.
Which you can easily enough deny (crate?). And I don't know
the attack mechanism there. Windows Defender does not
seem to interfere with that.
at the moment, everything seems to be under control.
I have a suspicion what the long term plan is, but
there is no sign at my desk here, of that plan
moving forward on this issue.
*******
And using SMBUS ? What a stupid thing to do.
The SMBUS is NOT designed properly. It has no protection
from two "masters" (softwares accessing the SMBUS)
not corrupting each others accesses. Some hobbyists
tried to get some of the hardware companies interested
in supporting a protocol to have serialized access
to the thing, but that idea fell through. As a result,
serious hardware should not be running off that bus.
And LPC should be the connection of choice, because
it does not have the same serialization issue that
SMBUS does. You could go from LPC to some other bus
standard, and drive your toys with that.
Even Microsoft itself has fallen into that trap.
Attempted to run monitor software on hardware features
lacking serialization, and comedy ensued (interface no
longer works when the user tries to access that information).
Microsoft had to quickly back that out.
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
