Hirdetés
- bobalazs: Artcraft - Az Adobe/Microsoft/egyéb termékek trónfosztója
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Parci: Milyen mosógépet vegyek?
- gban: Ingyen kellene, de tegnapra
- PSti: Gondos óra rövid bemutató
- Yézi: Forza Horizon 2, már PC-n is
- MasterDeeJay: Coffeetime mod Asus B150M-A D3 + i7 10750H ES
- Geri Bátyó: Agglegénykonyha 22 – Unortodox rakott krumpli
- MasterDeeJay: Legolcsóbb 3:2 arányú új monitor? (~50eft) 2.rész kalibrálás!
Új hozzászólás Aktív témák
-
"Valojaban az van, amit bambano irt: rendesen meg kellene irni a kernelt es az interface-eit, hogy ring 0-ban csak az fusson, aminek kell; a device driverek ring 1-ben, az emelt szintu, de kernel szintet nem igenylo system middleware-ek meg ring 2-ben - erre vannak kitalalva."
Ha még olvassa valaki: nagyon tartja magát ez a "csak jól meg kell írni"-zöldség. : -) Hány évtized számítástechnika szól arról, hogy ilyen nem létezik? Amúgy a Linuxon is sok támadási lehetőség van. És mi történik akkor, ha egy szinten már legalább két driver fut, amik szintén kárt okozhatnak a másikban? Úgy dobálóztok a ringekkel, mint más a dimenziókkal... És legyen teljesen átírva a Kernel tegnapra szeparált processzekkel, legyen vele minden továbbra is kompatibilis, mert az sem nagy ügy, és semmi se tartalmazzon hibát... : -)
Le merném fogadni, hogy egy ilyen hypervisorhoz századakkora változtatásokat sem kell eszközölni, mintha nekiállnának a Kernelt átírni, de annyira tudja mindenki látatlanban, mit kellene csinálni... Ebből az szokott lenni, hogy az első áttekintéskor, amikor kezd kiderülni, mennyire bonyolult is egy rendszer, akkor jönnek a felismerések...
Ettől még lehet rossz a rendszer, de néhány felületes rögeszméhez ragaszkodni, mint ez is (nem tőled): "vagyis ha plusz védelmi réteget raksz bele, meg ai-t raksz bele, akkor azokban is". Hát ez nem úgy működik, hogy minden vagy semmi, hanem lépcsők, elhatárolt területek és valószínűségek vannak. Ilyenkor bukik meg teljesen valakinek nemcsak szakismerete, hanem a gondolkodása is, ezért mertem butaságot emlegetni.
"Sot, esetleg egy alaposabb es kotelezo teszt sem artana a gyartok fele az MS-tol, akkor akar jobb lenne a helyzet."
A következő probléma ezt nem ismerni. Természetesen már réges-rég van ilyen, ahogy írtam: a WHQL - érvényes MS aláírás nélkül nem töltődnek be a driverek (a sys vagy a cat is lehet aláírt, ez külön téma), WHCP/HLK certification. Aztán az attestation signing, de az olyan driver retail Windows-ba nem kerülhet, plusz a Windows Test Signing mode, de az meg nem üzemszerű, sőt ha igaz, már nem is perzisztens, ill. Win 11-től lehetőség van vállalati környezetben, ahol pl. gond az MS-nek kiadni a kódot vizsgálatra vagy felesleges, belső aláíráslánc kialakítására (de nem egyedi self-signed driverek futtatására), ez nekem is új. Persze még így sem létezik olyan analízis, ami minden ellen megvéd.
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/whql-release-signature
-
"Valojaban az van, amit bambano irt: rendesen meg kellene irni a kernelt es az interface-eit, hogy ring 0-ban csak az fusson, aminek kell; a device driverek ring 1-ben, az emelt szintu, de kernel szintet nem igenylo system middleware-ek meg ring 2-ben - erre vannak kitalalva."
Sot, esetleg egy alaposabb es kotelezo teszt sem artana a gyartok fele az MS-tol, akkor akar jobb lenne a helyzet.
De pl biztonsagi szoftverek teren sem artana, mert az hogy leterdeltet a ceges biztonsagi szoftver egy 22 magos Windowsos gepet, az nekem erthetetlen.
Allitolag a ceges Ubuntumon is az fut, de semmit nem veszek eszre rajta, semmi akadas. -
De hát pont erről van szó, hogy biztonságosabb (korlátosabb) környezetet próbálják kialakítani a driverek körül. ring0 ugyan, de kb. egy virtuális gépben belül, szóval valójában le van korlátozva, hogy mit csinálhat. Ezért sem megy minden régi driver. Pl. ami futás időben kódot generál, annak most már vmi speckó ring4-es környezetbe kell azt beküldenie.
-
"De hát még csak nem is az MS-nél írják őket, hanem szanaszét a világban rakás másig cégnél.": azt a döntést, hogy nem biztonságos környezetet alakít ki a driverekhez, hanem ai szeméttel növeli a bloatot, nem szanaszét hozták meg, hanem az ms hozta meg.
Ha az ms úgy dönt, hogy ring1-be tölti be a drivereket, akkor azok oda fognak betöltődni, nem oda, ahova a fakezű driver írók álmodják. -
“De hát még csak nem is az MS-nél írják őket, hanem szanaszét a világban rakás másig cégnél.”
Viszont az MS tudna kontrollalni a minoseget kotelezo tesztek lefuttatasaval. Kulonbozo tesztek kulonbozo szintu es minositesu alairast jelenthetnenek. Ergo az ms meg tudna oldani a minosegi problemakat. -
VAAAAGY meg kellett volna írni rendesen azt a drivert.
A valóság amihez az OS-nak alkalmazkodnia kell, hogy a drivereket emberek írják (még?), akik hibáznak.
De nem, az ms egy harmadik utat választott
De hát még csak nem is az MS-nél írják őket, hanem szanaszét a világban rakás másig cégnél.
-
VAAAAGY meg kellett volna írni rendesen azt a drivert.
A valóság amihez az OS-nak alkalmazkodnia kell, hogy a drivereket emberek írják (még?), akik hibáznak.
De nem, az ms egy harmadik utat választott
De hát még csak nem is az MS-nél írják őket, hanem szanaszét a világban rakás másig cégnél.
-
KISDUCK
addikt
-
Valahol írtam olyat, hogy a cpu szintű védelem hülyeség?
"Itt most lehet valami ring 0, és mégis rá tud csapni a kezére a CPU, hogy ja te csak egy driver vagy, ilyet nem csinálhatsz.": ja. Ahhoz, hogy rácsapjon a kezére, belerak egy rakás szemetet a kódba, miközben annyit kellett volna csinálni, hogy nem ring0-ra teszi, hanem ring1-re.VAAAAGY meg kellett volna írni rendesen azt a drivert.
De nem, az ms egy harmadik utat választott, ami az ő pénztárcájának meg a részvényesi közgyűlésen előadott bullshitnek jobban fekszik, mellesleg járhatatlan, és azt erőlteti.
Valahogy az ms mindig azt erőlteti, ami nem jó a felhasználónak.
-
Valahol írtam olyat, hogy a cpu szintű védelem hülyeség?
"Itt most lehet valami ring 0, és mégis rá tud csapni a kezére a CPU, hogy ja te csak egy driver vagy, ilyet nem csinálhatsz.": ja. Ahhoz, hogy rácsapjon a kezére, belerak egy rakás szemetet a kódba, miközben annyit kellett volna csinálni, hogy nem ring0-ra teszi, hanem ring1-re.VAAAAGY meg kellett volna írni rendesen azt a drivert.
De nem, az ms egy harmadik utat választott, ami az ő pénztárcájának meg a részvényesi közgyűlésen előadott bullshitnek jobban fekszik, mellesleg járhatatlan, és azt erőlteti.
Valahogy az ms mindig azt erőlteti, ami nem jó a felhasználónak.
-
Ilyen alapon akkor a többi CPU szintű védelem is hülyeség, mert lehet bennük hiba... Itt arról van szó, hogy a CPU-k virtualizálási képességével finomabban fel lehet osztani a jogosultságokat, mint hogy ring 0 (kernel), vagy sem (ring 3, user, de azok már eleve meglhetősen izoláltak egymástól). Itt most lehet valami ring 0, és mégis rá tud csapni a kezére a CPU, hogy ja te csak egy driver vagy, ilyet nem csinálhatsz.
-
"Valojaban az van, amit bambano irt: rendesen meg kellene irni a kernelt es az interface-eit, hogy ring 0-ban csak az fusson, aminek kell; a device driverek ring 1-ben, az emelt szintu, de kernel szintet nem igenylo system middleware-ek meg ring 2-ben - erre vannak kitalalva."
Sot, esetleg egy alaposabb es kotelezo teszt sem artana a gyartok fele az MS-tol, akkor akar jobb lenne a helyzet.
De pl biztonsagi szoftverek teren sem artana, mert az hogy leterdeltet a ceges biztonsagi szoftver egy 22 magos Windowsos gepet, az nekem erthetetlen.
Allitolag a ceges Ubuntumon is az fut, de semmit nem veszek eszre rajta, semmi akadas. -
Nem lenne egyszerűbb rendesen megírni a drivereket?
Ez gyakorlatban lehetetlen. Minden valós nagyobb kódbázisban vannak és lesznek támadásra kihasználható benézések. Ezért próbálnak buta falakat felhúzni. Pl. ezzel egy driver nem tud egy memória lapra executable és writeable flag-et is egyszerre beállítani. Így ha valami bug-nak hálra rá lehetett venni, hogy bementi adatot kódként hajtson végre a saját jogosultságával, az mostantól már biztos nem fog működni.
-
Ami kodot a driver behuz a memoriaba, azok is alairt kodok, mi tobb, az a technika sem uj, hogy az irhato memoriateruletrol nem lehet kodot futtatni.
Valojaban az van, amit bambano irt: rendesen meg kellene irni a kernelt es az interface-eit, hogy ring 0-ban csak az fusson, aminek kell; a device driverek ring 1-ben, az emelt szintu, de kernel szintet nem igenylo system middleware-ek meg ring 2-ben - erre vannak kitalalva.
-
wolfpapa72
tag
de fafa.
Kiengedtük a szellemet a palackból és még nem is kívántunk semmit! 
-
"Az aláírt kód is lehet sérülékeny és jelenleg is a biztonsági megoldásoknak kell driver, ami bizony kódokat futtat kernel szinten, ahol már nincs védett memória, dumál a userspace komponensekkel."
Nemcsak az aláírt kódról van szó, hanem az aláírt kód, vagyis a driver által valahogyan a memóriába juttatott és futtatni kívánt kódról is. Hasonló kifejezések több mindent is jelenthetnek. Az egyik alapvető technika ez ellen, hogy ne lehessen írható lapon kódot futtatni. A hypervisor pedig, ami a védelem _egyik_ lépcsőjeként képes egyes eseteket kiszúrni, ezért került elkülönített szintre, aminek a biztonságát nem kód garantálja, hanem a virtualizáció (ez a különbség világos?), hogy ne a közös Kernel térben legyen, amiről már leírtam.
-
"Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket."
Aha, egy tök új architektúrában egyáltalán el fog indulni valami, ami teljesen más környezetre van megírva. : -) Na, ez a tájékozatlan pöffeszkedés. Írj át az alapjaitól egy több évtizede fejlesztett, együttműködésre kialakított és optimalizált rendszert szeparált processzekben futó driverekkel működőre... Valamint interruptok elirányítgatása, DMA-k stb., hogy csak a felszínt karcolgassuk.
Hogy meg lehetne tenni, az biztos, ott a QNX, de az nem az én asztalom. A teljesítmény is jó kérdés.
Sőt a Windows-ban most is alkalmazva van ez a koncepció; ott az UMDF, ami a user módú device drivereket jelenti, amik valóban szeparáltak, de más oka is van, hogy ilyen kivitelűek. Ilyenek az UMD display driverek (!), a kis USB client driverek, a szenzorok mini driverei stb. Csakhogy ennek is megvannak a következményei I/O-sebességben, egyebekben - nem univerzális megoldás. Megjegyzem, printer drivereket is elég hosszan írtam, az is egy része a rendszernek, bár azok nem úgy driverek.
Az AI érdekes lesz, hogy pontosan hogyan és mire alkalmazzák, a Kernelben nem lehet túl nagy hülyeségeket csinálni, értelmetlen hőzöngeni.
-
Eleve úgy kellett volna megírni.
A unixoknál számított, hogy mindenféle vason menjenek, ott gond lett volna.
Amikor kijött az nt, az teljesen új architektúra volt, ott kellett volna az elején megcsinálni rendesen."Írj át az alapjaitól egy több évtizede fejlesztett, együttműködésre kialakított és optimalizált rendszert": hányszor írták már át a windows kernelt? NT, 2K, w7, w10? Emlékeim szerint volt rá kísérlet, hogy kirakják a kernel védelmi szintről a grafikus drivert magasabb szintre, miért nem maradt úgy?
"Ja, én írtam még ... kernel device drivereket": nagyszerű! Ez azt jelenti, hogy láttad ugyanazt a hulladék világot sokszor. Dolgoztál már rendes oprendszeren, mint pl. VMS? Az ms elcsábította a VMS fő konstruktőrét, ő rakta össze az nt-t. Ha jól emlékszem a nevére, Dave Cutler. Ha a vms-ben szét tudta pakolni a funkciókat négy védelmi szintre, akkor az nt-ben miért nem lehetett a kezdetektől fogva úgy csinálni? (kernel / executive / supervisor / user)
"te miket írtál és mennyire ismered a device driver-fejlesztést?": ettél már rántottát?
-
weiss
addikt
-
Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket.
Az ms-nél megvolt a megfelel szaktudás hozzá, a kor egyik legjobb oprendszer tervezőjét nyúlták le anno.
Az ms-nek nem kell hardver kompatibilitáshoz igazodnia, mert fut pc-n, meg pc-n.Akkor miért nem csinálják meg?
"nehezen tudna másként és megfelelő sebességgel működni": tehát ha megcsinálnák rendesen a kódot, vagy rendesen szeparálnák a drivereket, akkor nem tud megfelelő sebességgel működni, míg ha nyakonborítják mindenféle ai marhasággal, ami folyamatosan ellenőriz, akkor meg igen?
"Csupán csak nem ismered ezt a területet, a Kernel egy külön világ.": esetleg lehet, hogy te nem ismered ezt a területet?
(set mode grammatikanáci. érdekes ez a magyar nyelv, ez a "kor egyik legjobb oprendszer tervezője" most azt jelenti, hogy oprendszer tervezők közül a legjobb, vagy azt, hogy az ember, aki a legjobb oprendszert tervezte. jelen konkrét helyzetben egyszerű, mert mindkettő...
) -
"Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket."
Aha, egy tök új architektúrában egyáltalán el fog indulni valami, ami teljesen más környezetre van megírva. : -) Na, ez a tájékozatlan pöffeszkedés. Írj át az alapjaitól egy több évtizede fejlesztett, együttműködésre kialakított és optimalizált rendszert szeparált processzekben futó driverekkel működőre... Valamint interruptok elirányítgatása, DMA-k stb., hogy csak a felszínt karcolgassuk.
Hogy meg lehetne tenni, az biztos, ott a QNX, de az nem az én asztalom. A teljesítmény is jó kérdés.
Sőt a Windows-ban most is alkalmazva van ez a koncepció; ott az UMDF, ami a user módú device drivereket jelenti, amik valóban szeparáltak, de más oka is van, hogy ilyen kivitelűek. Ilyenek az UMD display driverek (!), a kis USB client driverek, a szenzorok mini driverei stb. Csakhogy ennek is megvannak a következményei I/O-sebességben, egyebekben - nem univerzális megoldás. Megjegyzem, printer drivereket is elég hosszan írtam, az is egy része a rendszernek, bár azok nem úgy driverek.
Az AI érdekes lesz, hogy pontosan hogyan és mire alkalmazzák, a Kernelben nem lehet túl nagy hülyeségeket csinálni, értelmetlen hőzöngeni.
-
Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket.
Az ms-nél megvolt a megfelel szaktudás hozzá, a kor egyik legjobb oprendszer tervezőjét nyúlták le anno.
Az ms-nek nem kell hardver kompatibilitáshoz igazodnia, mert fut pc-n, meg pc-n.Akkor miért nem csinálják meg?
"nehezen tudna másként és megfelelő sebességgel működni": tehát ha megcsinálnák rendesen a kódot, vagy rendesen szeparálnák a drivereket, akkor nem tud megfelelő sebességgel működni, míg ha nyakonborítják mindenféle ai marhasággal, ami folyamatosan ellenőriz, akkor meg igen?
"Csupán csak nem ismered ezt a területet, a Kernel egy külön világ.": esetleg lehet, hogy te nem ismered ezt a területet?
(set mode grammatikanáci. érdekes ez a magyar nyelv, ez a "kor egyik legjobb oprendszer tervezője" most azt jelenti, hogy oprendszer tervezők közül a legjobb, vagy azt, hogy az ember, aki a legjobb oprendszert tervezte. jelen konkrét helyzetben egyszerű, mert mindkettő...
) -
Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket.
Az ms-nél megvolt a megfelel szaktudás hozzá, a kor egyik legjobb oprendszer tervezőjét nyúlták le anno.
Az ms-nek nem kell hardver kompatibilitáshoz igazodnia, mert fut pc-n, meg pc-n.Akkor miért nem csinálják meg?
"nehezen tudna másként és megfelelő sebességgel működni": tehát ha megcsinálnák rendesen a kódot, vagy rendesen szeparálnák a drivereket, akkor nem tud megfelelő sebességgel működni, míg ha nyakonborítják mindenféle ai marhasággal, ami folyamatosan ellenőriz, akkor meg igen?
"Csupán csak nem ismered ezt a területet, a Kernel egy külön világ.": esetleg lehet, hogy te nem ismered ezt a területet?
(set mode grammatikanáci. érdekes ez a magyar nyelv, ez a "kor egyik legjobb oprendszer tervezője" most azt jelenti, hogy oprendszer tervezők közül a legjobb, vagy azt, hogy az ember, aki a legjobb oprendszert tervezte. jelen konkrét helyzetben egyszerű, mert mindkettő...
) -
Thocy a ZAGY
tag
-
Csupán csak nem ismered ezt a területet, a Kernel egy külön világ. Persze én is hülyén írtam: igazából minden Kernel driver egy folyamatban van, nehezen tudna másként és megfelelő sebességgel működni és ezeket nem lehet egymástól megvédeni. Közös címtér meg minden - átírhatják egymás állapotait, memóriáját stb.
Mond az neked valamit, hogy tightly coupled drivers, amikor egyik driver gond nélkül meghívja egy másik függvényeit? : -) Ennyire használják ugyanazokat az erőforrásokat és ennyire látják egymást. De a DRIVER_IRQL_NOT_LESS_OR_EQUAL is tipikusan ilyen bugcheck kód volt, amit bármi és akármi is okozhatott... Én még akkor foglalkoztam vele (évekig), amikor a PnP és a WDM új volt, azóta eltelt egy kis idő.
Egyébként utánaolvastam, az Androidon is van hasonló eszköz, ill. a Linuxon is van egy project hasonló célokkal, szóval ez a "rétegezés" is általános biztonsági megoldás (lesz), nem mindegy, hogy hány sor kód mekkora részét éri el a rendszernek.
Azok a hardverek, amelyekre a windows certifikálva van, mind eleget tudnak ahhoz, hogy szeparálni lehessen a kernel drivereket.
Az ms-nél megvolt a megfelel szaktudás hozzá, a kor egyik legjobb oprendszer tervezőjét nyúlták le anno.
Az ms-nek nem kell hardver kompatibilitáshoz igazodnia, mert fut pc-n, meg pc-n.Akkor miért nem csinálják meg?
"nehezen tudna másként és megfelelő sebességgel működni": tehát ha megcsinálnák rendesen a kódot, vagy rendesen szeparálnák a drivereket, akkor nem tud megfelelő sebességgel működni, míg ha nyakonborítják mindenféle ai marhasággal, ami folyamatosan ellenőriz, akkor meg igen?
"Csupán csak nem ismered ezt a területet, a Kernel egy külön világ.": esetleg lehet, hogy te nem ismered ezt a területet?
(set mode grammatikanáci. érdekes ez a magyar nyelv, ez a "kor egyik legjobb oprendszer tervezője" most azt jelenti, hogy oprendszer tervezők közül a legjobb, vagy azt, hogy az ember, aki a legjobb oprendszert tervezte. jelen konkrét helyzetben egyszerű, mert mindkettő...
) -
HThomas
őstag
-
Pofon egyszerűen ki lehet kapcsolni most is
BIOS-ban letiltod a CPU virtualizációt, így a Windows nem tudja használni ezeket a funkciókat. Nekem is le van tiltva és ki van szürkítve a Windows Defender-ben a VBS és a Memory Integrity bekapcsolásának a lehetősége. Játékos gépen ugye nem volt ajánlott eddig se ezeket használni, mert átlag 10%-nyi teljesítmény vesztést okoz.
Nagyon köszi, ezt nem tudtam! -
Ettől tartok, ha nem lehet majd kikapcsolni akkor egy teljesen jól működő hangkártyám lényegében lenullázódik.
Pofon egyszerűen ki lehet kapcsolni most is
BIOS-ban letiltod a CPU virtualizációt, így a Windows nem tudja használni ezeket a funkciókat. Nekem is le van tiltva és ki van szürkítve a Windows Defender-ben a VBS és a Memory Integrity bekapcsolásának a lehetősége. Játékos gépen ugye nem volt ajánlott eddig se ezeket használni, mert átlag 10%-nyi teljesítmény vesztést okoz. -
"a Kernelben a folyamatokat nem lehet egymástól megvédeni": már miért ne lehetne?
Felsoroltál egy rakás eszközt, ami a hibák lokalizálására szolgál, amelyek lassítják a gépet, több ramot igényelnek és elvárják az ai-t. AI önigazolás. Csak egy dolgot nem soroltál fel sem te, sem más, hogy megírják rendesen a drivert.
-
Cs7
tag
Úgy érted, hogy a cikkbeli update után ezt már tényleg nem lehet W11 alatt használni?
-
Necroman_Mk2
őstag
-
"a Kernelben a folyamatokat nem lehet egymástól megvédeni": már miért ne lehetne?
Felsoroltál egy rakás eszközt, ami a hibák lokalizálására szolgál, amelyek lassítják a gépet, több ramot igényelnek és elvárják az ai-t. AI önigazolás. Csak egy dolgot nem soroltál fel sem te, sem más, hogy megírják rendesen a drivert.
-
Ez egyrészt arról szól, hogy csak aláírt, jóváhagyott kódok futhassanak, másrészt hogy bizonyos statikus analíziseket konkrétan az indulásakor folytasson le a rendszer. Pl. ne tudjon egy driver futás közben valahonnan kódokat betölteni és azokat futtatni, memórialapokat beállítani hozzá, bizonyos API-hívásokat végezni.
Ránézésre a vírusvédelem is elláthatná a HVCI feladatainak egy jelentős részét, de a Kernelben a folyamatokat nem lehet egymástól megvédeni, sok minden közös és keresztben-kasul elérhető, így viszont a Kernel kódok alacsonyabb jogosultságú szinten futnak a HVCI-nél, ezért se hibás kód, se rosszindulatú kód nem tudja azokat manipulálni. Sőt titkokat is lehet ott tárolni stb.
Mindez csak egy összetevője a sok védelemnek kezdve a WHQL-től, vagyis a driverek egyedi engdélyezésétől a Secure Boot következményein és ezen a HVCI-n keresztül a Defender viselkedésalapú vizsgálatáig. Egyébként a Kernel nagyon mérsékelten szokott bugos lenni, a HVCI ráadásul egyáltalán nem új.
És létezik olyan kártékony kód, ami ellen még ez sem orvosság, lásd: a Netfilter-eset.
-
Ez egyrészt arról szól, hogy csak aláírt, jóváhagyott kódok futhassanak, másrészt hogy bizonyos statikus analíziseket konkrétan az indulásakor folytasson le a rendszer. Pl. ne tudjon egy driver futás közben valahonnan kódokat betölteni és azokat futtatni, memórialapokat beállítani hozzá, bizonyos API-hívásokat végezni.
Ránézésre a vírusvédelem is elláthatná a HVCI feladatainak egy jelentős részét, de a Kernelben a folyamatokat nem lehet egymástól megvédeni, sok minden közös és keresztben-kasul elérhető, így viszont a Kernel kódok alacsonyabb jogosultságú szinten futnak a HVCI-nél, ezért se hibás kód, se rosszindulatú kód nem tudja azokat manipulálni. Sőt titkokat is lehet ott tárolni stb.
Mindez csak egy összetevője a sok védelemnek kezdve a WHQL-től, vagyis a driverek egyedi engdélyezésétől a Secure Boot következményein és ezen a HVCI-n keresztül a Defender viselkedésalapú vizsgálatáig. Egyébként a Kernel nagyon mérsékelten szokott bugos lenni, a HVCI ráadásul egyáltalán nem új.
És létezik olyan kártékony kód, ami ellen még ez sem orvosság, lásd: a Netfilter-eset.
-
csibe1
veterán
"A Microsoft egyébként a memóriaintegritást csak akkor aktiválja, ha biztos benne, hogy az adott PC-re telepített meghajtók kompatibilisek vele, tehát fut majd egy előzetes ellenőrzés, hogy a technika bekapcsolása ne okozzon kellemetlenségeket. "
Elméletileg, gyakorlatilag meg...
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Ez egyrészt arról szól, hogy csak aláírt, jóváhagyott kódok futhassanak, másrészt hogy bizonyos statikus analíziseket konkrétan az indulásakor folytasson le a rendszer. Pl. ne tudjon egy driver futás közben valahonnan kódokat betölteni és azokat futtatni, memórialapokat beállítani hozzá, bizonyos API-hívásokat végezni.
Ránézésre a vírusvédelem is elláthatná a HVCI feladatainak egy jelentős részét, de a Kernelben a folyamatokat nem lehet egymástól megvédeni, sok minden közös és keresztben-kasul elérhető, így viszont a Kernel kódok alacsonyabb jogosultságú szinten futnak a HVCI-nél, ezért se hibás kód, se rosszindulatú kód nem tudja azokat manipulálni. Sőt titkokat is lehet ott tárolni stb.
Mindez csak egy összetevője a sok védelemnek kezdve a WHQL-től, vagyis a driverek egyedi engdélyezésétől a Secure Boot következményein és ezen a HVCI-n keresztül a Defender viselkedésalapú vizsgálatáig. Egyébként a Kernel nagyon mérsékelten szokott bugos lenni, a HVCI ráadásul egyáltalán nem új.
És létezik olyan kártékony kód, ami ellen még ez sem orvosság, lásd: a Netfilter-eset.
Kiengedtük a szellemet a palackból és még nem is kívántunk semmit! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Nagyon köszi, ezt nem tudtam!
Új hozzászólás Aktív témák
- Tőzsde és gazdaság
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Filmgyűjtés
- Elektromos cigaretta 🔞
- One otthoni szolgáltatások (TV, internet, telefon)
- Kerékpárosok, bringások ide!
- Akadásmentes játékot ígér a shader előfordítással az SCSKiller
- Gumi és felni topik
- 3D nyomtatás
- OLED monitor topic
- További aktív témák...
- Sony A6700 + 70-350 objektiv új állapot, 3500expo körül.
- Sony RX100 Mark IV + 4 akku, esztétikai hibával
- Fuji XT-30 Mark II + 15-45
- 36 hó garancia Lenovo LOQ gamer laptop/ RTX 5060/ AMD R7 250/ 1TB SSD/ 16GB DDR5/ Vadi új
- Apple MacBook Air 13 M1 8 GB RAM / 256 GB SSD hibátlan, tesztelt, számlával, dobozában, garanciával
- 27% - MSI MAG X670e Gaming Plus Wifi Alaplap
- HP ProDesk 600 G5 MINI,i5-9500T,4GB DDR4,256GB NVMe SSD,WIN11,WIFI,HDMI
- 305 - Lenovo Yoga Pro 9 (16IAH10) - Intel Core U7 255H, 32GB, 1TB SSD, RTX 5060 (ELKELT)
- SzoftverPremium.hu
- Lenovo ThinkPad X13 Gen 3 i5-12. gen-16GB DDR5 RAM FHD+ gari. 4g modem Érintőkijelző