Názory k článku
Defender ve Windows odstraňuje WinRing0 jako škodlivý, monitorovací software jako FanControl přestane fungovat

Cili driver je spatny, je celkove uplne k nicemu - tazke je spravne, ze jej blokuje, jinak by nikdy nedonutil je autory prepsat ;-)

Přepsat... možná víte přesně, jak se věci mají, a ve Vašem případě se chystám nosit sovy do Athén, ale třeba to tady čte někdo ještě méně v obraze než jsem já...
tak tedy:

Co vím o WinRing0, jedná se o generický ovladač pro přístup "pod kapotu" = přímo na hardware (port IO a snad i MMIO) a tuším taky kamkoli do fyzické RAM, přinejmenším do virtuálního paměťového prostoru jádra. Tzn. ta věc je nebezpečná z principu.

Stejně tak mi Defender a další antiviry už delší dobu kostí "WinIO" - to je ze stejného soudku.

Takových knihoven je víc, výše uvedené jsou hodně populární. Různé z těchto knihoven mají navzájem částečně disjunktní množinu schopností - zapomněl jsem zmínit přístup do PCI Configuration Space, nebo některé privilegované instrukce typu přístup do MSR - ale v principu jde o to, že pod Windows nemá člověk z user space šanci, sáhnout si přímo na hardware. Což člověk občas potřebuje, zejména když se v hardwaru často hrabe, třeba protože to má v popisu práce, nebo pro zábavu, má nějakou jednoduchou periferii zhruba ve stylu GPIO, nebo má na desce švába se zajímavými schopnostmi, pro kterého Microsoft ani výrobce toho švába natruc nedodávají oficiální HW-specific ovladač (výrobce hardwaru se tváří, jako že MSDOS dodnes vládne světu) apod.

Ve svobodných časech, které skončily cca s oficiální podporou XP SP3, směl člověk loadnout do kernelu ve Windows cokoli, co si sám napsal - a nepotřeboval k tomu požehnání Microsoftu. Stačilo říct windowsům "ano je to v pořádku, tenhle driver můžete natáhnout" přestože není podepsaný, nebo podpis nesedí, protože jste si upravili pár defaultů v doprovodném INF souboru.

Napsat driver do kernelu se technicky dá klidně v MinGW, dokonce jsou tuším dnes přibaleny potřebné hlavičkové soubory pro různé generace NT DDK. Nebo samozřejmě oficiální build environtment = MSVC + DDK nebo jak se to dnes jmenuje. Zatnul tomu tipec až striktní požadavek na "podpis" = netriviální dodatečná podmínka nutná, pro hobbíka nesnadno dosažitelná. Nemluvím o zmasírování Windows do nějakého testovacího / vývojářského režimu, nebo jak se tomu říká (aby se kontrola podpisů odstavila) - člověk by jaksi rád provozoval některé věci i v plně produkční instalaci Windows. Třeba měřil teploty a sledoval otáčky ventilátorů, sledoval detailní stav vytížení procesoru apod.

Je nezanedbatelná mentální dřina, naučit se buildnout driver (aspoň kostru a všelijaké formální náležitosti), pokud se člověk chce podívat na otáčky ventilátoru nebo si zablikat LEDkou. Pokud zrovna nepotřebujete obsluhovat IRQ a řešit DMA (což v user space skrz generickou knihovnu dost dobře nejde), tzn. pokud Vašim potřebám vyhoví jednoduché prostředky generické knihovny, může být velmi užitečné a programátorsky velmi jednoduché, tenhle "bezpečnostně problematický trik" použít. Jde jenom o to, aby Vám výrobce operačního systému svěřil odpovědnost - rozhodnout o tom, že "ano, tahle věc smí do kernelu", na daném stroji. Třeba o tom někde pořídit záznam, pokud by snad zákazník chtěl následně reklamovat vadné chování systému.

Ano, takové počínání je z principu nebezpečné. Tyhle "generické knihovny" jsou jedna velká díra do celé krásné koncepce ochrany paměti, oddělení obsluhy hardwaru (kernel) od user space etc. all that jazz.

Třeba v Linuxu dodnes smíte, napsat si do kernelu svůj vlastní driver - pokud umíte. Aniž byste museli Linuse osobně žádat o souhlas, někde se registrovat apod. Je trochu opruz, dostat driver do stávajícího buildu produkčního distribučního kernelu, ale případně není velká bolest, pro potřeby specifického stroje si kernel zkompilovat svůj - zejména pokud nelpíte na end-to-end chain of trust (od UEFI SecureBootu až po pantofle co máte na nohou). Bačování přímo v kernelu se postupně v průběhu let přeci jen i v Linuxu mírně komplikuje (bezpečnostní šrouby jsou utahovány), což vnímá spíš hobbík než profík - ale pořád to jde.
Mimochodem sáhnout si na I/O porty nebo do RAMky nebo PCI Config Space máte možnost standardními správcovskými utilitkami přímo z shellu, rychleji než vyslovíte gcc.

No a pod Windows líp už bylo. Tahle stránka svobody byla vymazána.
Ano máme taky OS, které jsou svobodné ještě mnohem méně.

Fakt je, že když pozoruju třeba takový SpeedFAN (apod. utility) které lezou na SuperIO a podobné poměrně komplikované čipy přímo z user space skrz generickou knihovnu, tak je mi taky smutno, že konkrétně HW health monitory (nebo SuperIO jako jejich nadmnožina) nemají pod Windows nějakou jednotnou třídu ovladačů v kernelu, nějaké API pro user space. V linuxu toto existuje a je to udržováno komunitou - výrobci SuperIO švábů často přispívají k vývoji svou troškou tím, že drží datasheety od svých čipů pod NDA několik let poté, co se začnou prodávat na motherboardech nových počítačů :-(

Mimochodem by bylo návazně super, mít hardwarové senzory pod Windows vytažené do SNMP. Což v Linuxu údajně funguje (osobně jsem zatím nezkoušel, asi to brzo přijde).
https://github.com/net-snmp/net-snmp/issues/67

Už jsem hodně OT.
Abych se vrátil k příspěvku, na který reaguji:

"Někdo by měl autory donutit, driver přepsat": problém je v tom, že tyhle generické knihovny jsou nebezpečné samou podstatou své funkce a svým účelem :-( Těžko je nějak "opravovat", aniž byste zařízli samotný smysl jejich existence. Obvykle chodí přibalené k nějakému dost užitečnému softwaru, který trestuhodně není k dispozici od Microsoftu samotného (takovéhle utilitky by se myslím dost dobře vyjímaly ve sbírce SysInternals). A vcelku pochopitelně jsou přibalené taky k čistokrevnému malwaru (spíš učednické úrovně, protože profík se nemusí uchylovat k takovým trapným pomůckám).

A donutit k napsání driveru výrobce SuperIO čipů? Ehh... "co tam máte dál..."
Budou Vám přirozeně argumentovat, že přístup na SuperIO je věc BIOSu, smyčky řízení ventilátorů jsou dnes obvykle autonomní, a že OS se dozví vše potřebné skrz ACPI Thermal Zone. (A v serverech máte IPMI.)

No nic. Ulevil jsem si, půjdu něco dělat :-)

Napsat driver pro Win neni takovej problem.

Problem je podepisovani a cela ta saskarna kolem certifikatu, co se cas od casu meni.. takze v dobe kdy jsme zacali na projektu to bylo jinak nez kdyz jsme skoncili.

A pak uz jsou jen wtf hnoje z Win kernelu.. treba uplne neschopna sprava pameti, ktera hodi radeji BSOD, nez aby zavolala nejaky callback / udelala uvolneni pameti sama (to je pripad kdy nejakou aplikacni pamet locknete funkci v jadre a aplikace se ukonci a neodemce stranky).

Btw taky mame vlastni genericky stub/proxy driver a zbytek logiky se resi v userspace - a v tomto stavu by reseni zrejme neproslo schvalenim a podepsanim :D

nestačilo by používať iný antivírus, ako defender? Alebo ten driver blokujú aj ostatné?

Jiné antiviráky jsou typicky ještě o něco přísnější než MS Defender. A nejsou od Microsoftu, což může být lehký problém, minimálně psychologický pro správce, že když systém bude podávat chybné výkony, tak mu s tím MS jakožto výrobce OS třeba nepomůže/nepo­radí...

SpeedFan je zvlášť "výživná" utilita. Nainstaluje driver, který má přístup k veškerému HW z user space bez omezení. Následně přebuší otáčky ventilátoru, a provádí to každých pár sekund, aby se tím přerazilo řízení otáček které provádí ACPI. A vysloveně "potěšilo" když jsem měl spuštěný SpeedFan a přepnul na jiného uživatele. Ten druhý uživatel při přilogování také spustil SpeedFan, a následovala BSOD, plně reprodukovatelně. Přiznávám že je to pár let zpátky, a od té doby jsem tuhle příšernost na počítači nikdy neměl. Obecněji máte pravdu, že thermal management je dnes poměrně komplexní, a OS ho nemá řešit přes divokou third party utility, ale přes ACPI Thermal Zone nebo IPMI.

Co jsem tak stihl postřehnout, řízení otáček většinou (v defaultním nastavení BIOSu a potažmo SuperIO čipu) dělá SuperIO čip - má na to autonomní zpětnovazební smyčku (nebo snad i víc). Má to velmi dobrý smysl v tom, že když se Vám přehřeje procesor a vytuhne, nebo nestíhá, tak řízení chlazení jede autonomně dál.

Různé čipy mají tohle autonomní řízení řešeno různě (řídící křivka je různými způsoby parametrizována), a v BIOSu to bývá v různé míře detailně konfigurovatelné. Často jenom "řízení otáček zapnout/vypnout". Když řešíte hluk, může být defaultní chování pěkná otrava. Volnoběžné otáčky moc vysoko, nebo otáčky kolísají apod. V tu chvíli je softwarové řízení lákavou alternativou.

Ale jak říkáte - mělo by to být ošetřeno proti vícenásobnému spuštění. Třeba tak, že to bude systémová serviska, která se nastartuje zároveň se systémem. GUI bude jenom náhled na status té servisky, případně konfigurační nástroj, ale vícenásobné spuštění nebude vadit. Simultánní běh více instancí GUI se dá přece snadno ošetřit. A ano, ideálně by k tomu měl být dedicated driver v kernelu. Který by do user space dával k dispozici API právě jenom pro přístup k HW monitoru. Least privilege. V linuxu je k teplotám, otáčkám a PWM pěkné generické rozhraní pro user space. Včetně toho, že se dá vypnout hardwarová autonomní smyčka (domnívám se, že u podporovaných čipů SpeedFan dělá totéž) a následně máte možnost nastavovat PWM střídu po svém, např. démonkem Fancontrol.

On je mimochodem problém už v tom, že nejen konfigurace SuperIO, ale i přístup k HW monitoru, jde skrz multiplexované "okénko" = skrz dvojici x86 ISA I/O portů INDEX a DATA. Toto je jasná kritická sekce, kterou je třeba ošetřit proti vícenásobnému přístupu. Nejlíp proti simultánnímu přístupu z BIOSu, OS a "ad-hoc dalšího softwaru". Pokud vím, toto asi nikdo neřeší. A vcelku to prochází, protože na SuperIO a HW Monitor za jízdy běžně nesahá ani BIOS ani OS, takže si 3rd-party software může dělat co chce, pokud neběží ve více instancích simultánně bez mutexu. ACPI Thermal Zone běžně bývá v počítači jenom jedna a ukazuje teplotu procesoru z integrovaného čidla, které se čte přes MSR a není háklivé na simultánní vícenásobný přístup.

Pravda je, že tohle multiplexní IO okénko HW health monitoru by snad samo o sobě nemuselo způsobit modrou smrt... třeba není reentrantní zmíněná univerzální knihovna. Každý software obsahuje chyby :-)

Oproti tomu kernel-level anticheaty, které jsou de facto invazivní rootkity nikomu nevadí. :-/

Nejhorsi je to zariznuti self-signed driveru. Driv si stacilo koupit spravny certifikat a bylo vyreseno. Dnes je to nekonecny oser.

Jo,neco takovyho mi hodilo goverlay na sysinfo display..tak jsem aktualizoval dll libre hardware monitoru a ok...z konce 2024...tak nevim...

Já bych ten nápis zkrátil:
Defender ve Windows škodlivý,

Windows je virus.

Ako v tom starom vtipe. Windows nie je virus. Virusy nieco aj robia.

No veď súčasné windows vo vanilla stave práve furt niečo robia (z vlastnej iniciatívy)...

Update aktivita, defender skeny, indexer, .net "optimalizácie", office click-to-run, slovo idle už aj stráca põvodný význam.

Sbíraj a šifrují data... o aktivitě, o tom co se zpustilo, jak se to zpustilo. Kde se nacházíte a případně spojí i s emailem, kdy je to skoro brané jak internetová občanka... Datovej tok v IDLE je brutálně vysokej na pár sekund.
Proto taky u správce úloh v sekci síť nezobrazí, ale až softem třetí strany, který to ukáže... Mě to třeba práskl router.

Myslím, že je pořád zdravé rozlišovat mezi "škodlivý" a "nebezpečný/zra­nitelný" kód. To je asi jako kdyby vám antivir smazal webserver, protože máte starou nezáplatovanou verzi.

To se mi zdá fér. Ne sice smazat, ale KILL after start je dobře.

Neni dobre ani to. Zhodnoceni ma ucinit osoba zodpovedna za system. Antivir nedokaze zhodnotit jaky dopad a jake skody muze mit odstaveni nejake sluzby. Muze se take jednat o false positive. Hlavne v pripade ze do nejake stare verze je backportovana oprava je takove riziko mnohem vyssi. Tim spis pokud si ten system latam sam.