Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #687401 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2025-03-13 21:54 +0000 |
| Last post | 2025-03-15 21:50 +0000 |
| Articles | 11 — 5 participants |
Back to article view | Back to comp.os.linux.advocacy
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
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-13 21:54 +0000 |
| Subject | Death 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]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-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]
| From | Farley Flud <fsquared@fsquared.linux> |
|---|---|
| Date | 2025-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]
| From | CrudeSausage <crude@sausa.ge> |
|---|---|
| Date | 2025-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]
| From | "Alan K." <alan@invalid.com> |
|---|---|
| Date | 2025-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]
| From | CrudeSausage <crude@sausa.ge> |
|---|---|
| Date | 2025-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]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-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]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-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]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-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]
| From | CrudeSausage <crude@sausa.ge> |
|---|---|
| Date | 2025-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]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-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