Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.advocacy > #687401 > unrolled thread

Death By Auto-Immune Disease

Started byLawrence D'Oliveiro <ldo@nz.invalid>
First post2025-03-13 21:54 +0000
Last post2025-03-15 21:50 +0000
Articles 11 — 5 participants

Back to article view | Back to comp.os.linux.advocacy


Contents

  Death By Auto-Immune Disease Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-13 21:54 +0000
    Re: Death By Auto-Immune Disease Paul <nospam@needed.invalid> - 2025-03-13 20:49 -0400
    Re: Death By Auto-Immune Disease Farley Flud <fsquared@fsquared.linux> - 2025-03-14 10:36 +0000
    Re: Death By Auto-Immune Disease CrudeSausage <crude@sausa.ge> - 2025-03-14 08:39 -0400
      Re: Death By Auto-Immune Disease "Alan K." <alan@invalid.com> - 2025-03-14 09:42 -0400
        Re: Death By Auto-Immune Disease CrudeSausage <crude@sausa.ge> - 2025-03-14 10:53 -0400
        Re: Death By Auto-Immune Disease Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-14 21:26 +0000
      Re: Death By Auto-Immune Disease Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-14 21:25 +0000
        Re: Death By Auto-Immune Disease Paul <nospam@needed.invalid> - 2025-03-15 00:57 -0400
        Re: Death By Auto-Immune Disease CrudeSausage <crude@sausa.ge> - 2025-03-15 08:22 -0400
          Re: Death By Auto-Immune Disease Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-15 21:50 +0000

#687401 — Death By Auto-Immune Disease

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2025-03-13 21:54 +0000
SubjectDeath By Auto-Immune Disease
Message-ID<vqvk66$3v7rr$1@dont-email.me>
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?

[toc] | [next] | [standalone]


#687410

FromPaul <nospam@needed.invalid>
Date2025-03-13 20:49 -0400
Message-ID<vqvuea$7coo$1@dont-email.me>
In reply to#687401
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

[toc] | [prev] | [next] | [standalone]


#687419

FromFarley Flud <fsquared@fsquared.linux>
Date2025-03-14 10:36 +0000
Message-ID<182ca504f67fa485$32887$5317$802601b3@news.usenetexpress.com>
In reply to#687401
On Thu, 13 Mar 2025 21:54:15 +0000, Lawrence D'Oliveiro wrote:

> is now being identified by Windows Defender as
> malware, and the apps that install it are being blocked.
> 

Who does not excise that ridiculous "Defender" immediately after
install?

It is a relatively simple matter.  There are utilities that allow one
to attain the level of "TrustedInstaller."  Once attained, simply
disable the Defender Service (and all updates and telemetry as well)
and then remove the Defender files and directory.

After this, and a few dozen other modifications, that junk OS becomes
somewhat tolerable for occasional use.


-- 
Systemd: made by assholes for assholes.

[toc] | [prev] | [next] | [standalone]


#687421

FromCrudeSausage <crude@sausa.ge>
Date2025-03-14 08:39 -0400
Message-ID<UrVAP.87687$bYQ4.3285@fx41.iad>
In reply to#687401
On 3/13/25 17:54, 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.

Windows now has a proactive defense mechanism where certain things the 
operating system believes to be harmful are blocked. In my case, this 
has resulted in Windows believing that ArmouryCrate, software ASUS 
provides to allow users to control their hardware, is partly harmful. It 
has done the same for G-Helper, a lightweight ArmouryCrate replacement. 
The sad part is that it only seldom considers it to be harmful, 
suggesting that even if something were to actually be malware, Windows 
would only sometimes block the threat.

> 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 not. As it is, I can more easily run open-source software on 
Windows than I can in Linux. With the latter, I have to hope that 
there's a Snap available if I'm using Ubuntu or a Flatpak if I'm using 
something else. If I prefer to use the repositories, I have to hope that 
the software is in them. Otherwise, I have to compile from source with 
no guarantee that it will work or integrate into the system as expected. 
In this respect, Windows is much better since I only have to look for an 
executable to load the software, and I can be sure that it will work.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]


#687423

From"Alan K." <alan@invalid.com>
Date2025-03-14 09:42 -0400
Message-ID<vr1bnu$1da97$1@dont-email.me>
In reply to#687421
On 3/14/25 08:39 AM, CrudeSausage wrote:
> In this respect, Windows is much better since I only have to look for an executable to 
> load the software, and I can be sure that it will work.
I don't think 100%.  Some software will fail because of a missing DLL.

-- 
Linux Mint 22.1, Cinnamon 6.4.8,  Kernel 6.8.0-55-generic
Thunderbird 128.8.0esr, Mozilla Firefox 136.0.1
     Alan K.

[toc] | [prev] | [next] | [standalone]


#687429

FromCrudeSausage <crude@sausa.ge>
Date2025-03-14 10:53 -0400
Message-ID<XpXAP.13687$0qs5.2475@fx07.iad>
In reply to#687423
On 3/14/25 09:42, Alan K. wrote:
> On 3/14/25 08:39 AM, CrudeSausage wrote:
>> In this respect, Windows is much better since I only have to look for 
>> an executable to load the software, and I can be sure that it will work.
> I don't think 100%.  Some software will fail because of a missing DLL.

It can happen, but it only usually does if the software I'm looking to 
install is ancient. Otherwise, the dependencies either install or offer 
to be downloaded during the process.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]


#687457

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2025-03-14 21:26 +0000
Message-ID<vr26uc$23hho$3@dont-email.me>
In reply to#687423
On Fri, 14 Mar 2025 09:42:22 -0400, Alan K. wrote:

> Some software will fail because of a missing DLL.

How about an incompatible DLL? Only, changing to the compatible version 
breaks something else?

Windows has no integrated Linux-style package manager that will 
automatically keep track of dependencies like this, and also manage 
system-wide updates for you.

[toc] | [prev] | [next] | [standalone]


#687455

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2025-03-14 21:25 +0000
Message-ID<vr26s7$23hho$2@dont-email.me>
In reply to#687421
On Fri, 14 Mar 2025 08:39:16 -0400, CrudeSausage wrote:

> On 3/13/25 17:54, Lawrence D'Oliveiro wrote:
>>
>> Do you think maybe the entire Windows ecosystem is fundamentally
>> hostile to open-source software?
>
> Otherwise, I have to compile from source with no guarantee that it
> will work or integrate into the system as expected.

Building from source tends to be more reliable (and requires fewer steps) 
on Linux than Windows. There is a guy on comp.lang.c, a Windows fanatic, 
who regularly moans about this, as though it’s the fault of the developers 
of Open Source.

> In this respect, Windows is much better since I only have to look for an
> executable to load the software, and I can be sure that it will work.

That’s what Linux package repos do: they provide that “executable” (or 
library dependency or whatever). Consider that a major distro like Debian 
includes something like 50,000 packages in its official repo: where are 
you going to find a selection of prebuilt open-source Windows executables 
that large? It doesn’t exist.

[toc] | [prev] | [next] | [standalone]


#687472

FromPaul <nospam@needed.invalid>
Date2025-03-15 00:57 -0400
Message-ID<vr31b9$2s65b$1@dont-email.me>
In reply to#687455
On Fri, 3/14/2025 5:25 PM, Lawrence D'Oliveiro wrote:
> On Fri, 14 Mar 2025 08:39:16 -0400, CrudeSausage wrote:
> 
>> On 3/13/25 17:54, Lawrence D'Oliveiro wrote:
>>>
>>> Do you think maybe the entire Windows ecosystem is fundamentally
>>> hostile to open-source software?
>>
>> Otherwise, I have to compile from source with no guarantee that it
>> will work or integrate into the system as expected.
> 
> Building from source tends to be more reliable (and requires fewer steps) 
> on Linux than Windows. There is a guy on comp.lang.c, a Windows fanatic, 
> who regularly moans about this, as though it’s the fault of the developers 
> of Open Source.
> 
>> In this respect, Windows is much better since I only have to look for an
>> executable to load the software, and I can be sure that it will work.
> 
> That’s what Linux package repos do: they provide that “executable” (or 
> library dependency or whatever). Consider that a major distro like Debian 
> includes something like 50,000 packages in its official repo: where are 
> you going to find a selection of prebuilt open-source Windows executables 
> that large? It doesn’t exist.
> 

Visual studio hasn't always behaved like it does today.

Did you know you could use Visual Studio without a .proj file ?
I'm sure you know that, because you're ready to pass judgment on it.

There is a bat file that figures this stuff out for you, but I didn't
use that either. I did it all by hand, one try after another. Most
of the C language support trees, are in a separate Windows Kit (SDK).

cd /d  [set your working path] [Win10AMD on 4TB HDD]

set INCLUDE=C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt;
            C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include;
            C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um;
            C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared

set LIB=C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\ucrt\x64;
        C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\um\x64;
        C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\lib\x64

set LIBPATH=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\lib\x64

# compile and link. F:\TEMP for temporary files, the executable ends up under F:\

cl  parse-mft.cpp  /FoF:\TEMP\  /FeF:\parse-mft.exe

That's no different than MINGW. No moaning required.

A build recipe for Firefox, used the compiler and linker
directly from a VS install in this way. I didn't invent the
idea, but I knew it could be done, because I did a Firefox that way.

You don't have to use the IDE if you don't want to.

There were some earlier versions of VS, where setting
the path was easy. But they couldn't be satisfied with
that, and they had to make it much harder. Mission accomplished.
As a hobbyist, it would take me about a week of fiddling
around, before I could remember how to set one of these
up using the "GUI". It took less than a week, to make up some
paths for the job, the hard way.

FOSS trees with Win builds, are available on things like
github. You still have to use Safe Hex operating principles
and not be in a rush when doing things like that. You are not
always limited to just source tarballs, sometimes there are
executables.

I keep a MINGW tree (the original), and if the headers
I need aren't there, I have VS Community Edition installs I can use.

   Paul

[toc] | [prev] | [next] | [standalone]


#687486

FromCrudeSausage <crude@sausa.ge>
Date2025-03-15 08:22 -0400
Message-ID<eieBP.543498$SZca.47871@fx13.iad>
In reply to#687455
On 2025-03-14 5:25 p.m., Lawrence D'Oliveiro wrote:
> On Fri, 14 Mar 2025 08:39:16 -0400, CrudeSausage wrote:
> 
>> On 3/13/25 17:54, Lawrence D'Oliveiro wrote:
>>>
>>> Do you think maybe the entire Windows ecosystem is fundamentally
>>> hostile to open-source software?
>>
>> Otherwise, I have to compile from source with no guarantee that it
>> will work or integrate into the system as expected.
> 
> Building from source tends to be more reliable (and requires fewer steps)
> on Linux than Windows. There is a guy on comp.lang.c, a Windows fanatic,
> who regularly moans about this, as though it’s the fault of the developers
> of Open Source.

That doesn't address the problem I pointed out: it doesn't guarantee 
that it will work or integrate into the system as expected.

>> In this respect, Windows is much better since I only have to look for an
>> executable to load the software, and I can be sure that it will work.
> 
> That’s what Linux package repos do: they provide that “executable” (or
> library dependency or whatever). Consider that a major distro like Debian
> includes something like 50,000 packages in its official repo: where are
> you going to find a selection of prebuilt open-source Windows executables
> that large? It doesn’t exist.

I am glad to know that Debian has a gigantic library of software in its 
repositories, but it once again doesn't guarantee that it will work 
right. Linux is plagued with programs that will install but are either 
broken or don't even load. If I can be sure, as a Debian user, that 
something I install actually does the job it is intended for, that's 
great. I wouldn't know since I haven't tried Debian since 2011 or so.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]


#687504

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2025-03-15 21:50 +0000
Message-ID<vr4sn4$cbcb$3@dont-email.me>
In reply to#687486
On Sat, 15 Mar 2025 08:22:34 -0400, CrudeSausage wrote:

> That doesn't address the problem I pointed out: it doesn't guarantee
> that it will work or integrate into the system as expected.

Linux is usually the system where Open Source software is tested first. So 
if a piece of software will work anyway, it will likely work on Linux.

> I am glad to know that Debian has a gigantic library of software in its
> repositories, but it once again doesn't guarantee that it will work
> right.

Debian has a reputation for having things “work right”. It is considered 
industrial-strength, with stability so rock-solid as to be downright 
boring. Lots of businesses entrust mission-critical revenue-generating 
operations to it.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.linux.advocacy


csiph-web