odkazovany vlakno jsem pocetl
Rano jsem stahl PoC z githubu, zbezne to procetl, zkompiloval vsunul modul a... guest se restartoval, hostovi to bylo jedno. po restartu si guest stezoval do konzole
watchdog: BUG: soft lockup - CPU#0 stuck for [52-548]s [poc_0:940]
modul jsem vysunul a zamnul si ruce. (pro moje uziti me tohle stejne moc netankuje, ale chtel jsem si to zkusit)
v mym proxmox je default cpu x86-64-v2-AES ktery nested-virt zaply nema (ani jsem nemel v guestovi /dev/kvm), po prepnuti na cpu HOST jsem /dev/kvm mel
ve tvym odkazu vidim reakci devu proxmoxu kde hned v prvnim jejich postu radi ze si mas vypnout nested virt.. fakt netusim co ti vadi, mozna neco prehlizim.
u tebe ten PoC bezi? na jaky verzi?
Jsem resil zda kvuli tomu updatovat a otocit server nebo ne.
Jediny co mam po ruce je:
# apt list --upgradable | grep kernel WARNING: apt does not have a stable CLI interface. Use with caution in scripts. proxmox-default-kernel/stable 2.1.0 all [upgradable from: 2.0.2] proxmox-kernel-6.17/stable 6.17.13-14 all [upgradable from: 6.17.13-1] proxmox-kernel-helper/stable 9.2.0 all [upgradable from: 9.0.4]
A podivne nejake balicky jsou not upgradeable (coz musim zjistit zda je blokovany na druhou vlnu nebo co to ma znamenat, debian neni muj rajon).
A ted fakt nevim - resi to tenhle bug, nebo neresi? Tak jsem googlil cislo CVE + proxmox a jediny nalez bylo nedefinovany vlakno ve foru ktere je oznaceno za "solved", ale prakticky mi nic nereklo. Proc nedokazou napsat ze release x.y.z-n je ten, kde to je OK ?
Bezpecnostni politika nedovoluje poustet "nahodny" PoC z netu (v podsate zadne cizi binarky nemame) - a jeste k tomu na ostrem zeleze, kde to ma predpokladane chovani ze to sejme hosta.
Rozciluje me, ze nasazeni vyhlaseneho nastroje mi pridava vice prace, nez kdybych si to udelal sam po svem (ale spoluadmini by museli resit start/stop skripty virtualek, ne klikaci web).
CPU se prepina vzdy na HOST, ty VM co mam nepotrebuji k provozu nested virtualizaci - ale netusim jaky default je aplikovany. Forum doporucuje vypinat na urovni KVM modulu, ale tusim ze tam je i per-vm klikatko.
rezim cpu=host je kvuli nativni optimalizaci (uvnitr je Gentoo, tak nechci aby se neco zbytecne omezovalo ci emulovalo).
Politika je kvuli bezpecnosti, temer vsechno je inhouse, tak to nebudeme degradovat a zanaset rizika. Neni to prvni VM escape bug (takze se grupuji veci podle toho co tam bezi) - takze se nejak pocita se scenarem ze jestli se neco stane, tak to bude kompromitovany a host/guest izolace narusena, ale prekvapuje me ten klid .. treba ty AMD TLB flush problemy hodne davno se nesli vice hlasite (ale mozna to jen Intel tesilo a netusil co je brzo taky ceka).
Druhy server by mohl byt s jinou politikou, jako vice relaxed - ze prulom/utek z vm k ohrozeni nestaci, protoze tam bude izolace skrze sit (a doufam v ne-soubeh LPE / RCE chyb).
Vyslovene testovaci prostredi neni (nejsou testovaci scenare) na te urovni vm host/guest. Nahradni hw je vyuzivan na jine ucely (takze je, ale nelezi netestovany ladem).