Linus beolvasztotta a Kernel page-table isolation-t

Kernel

Linus végül beolvasztotta a Kernel page-table isolation (röviden: PTI, KPTI, korábban: KAISER) hardening megoldást a saját kernelfájába. A KPTI célja a biztonság fokozása a kernel- és user space memória jobb izolálása révén. Ez a fundamentális változtatás az aktuális fejlesztési ciklus késői szakaszában (-rc5 után) érkezett, ezért nem kizárt, hogy a 4.15-ös kernel fejlesztési ciklusa az -rc8-ig (vagy tovább is) tart majd.

A kernel page-table isolation jelenlegi helyzetéről az LWN publikált egy összefoglalót "The current state of kernel page-table isolation" címmel, amely nem előfizetőknek január 4-től lesz olvasható.

( uid_15426 | 2018. 01. 01., h – 19:37 )

Es nagyon ugy tunik, hogy valami uber sebezhetoseg all a hatterben:

http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case…?

tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

----------------------
while (!sleep) sheep++;

> In the worst case the software fix causes huge slowdowns in typical workloads.

vs

> Fig.8: Comparison of the runtime of different benchmarks when running on the KAISER-protected kernel. The default kernel serves as baseline (=100%). We see that the average overhead is 0.28% and the maximum overhead is 0.68%.

https://gruss.cc/files/kaiser.pdf

Kivancsi vagyok, hogy masok szerint egy konkret, temahoz fuzodo hozzaszolas vagy fakenews-duplanick-trollvagy off-topic poszt-lanc szamit inkabb trollkodasnak :) (De latom egyre cikibb ez neked is, tehat hagyjuk -- a frappans vegszo lehetoseget azert meghagyom neked. :) )

----------------------
while (!sleep) sheep++;

Egyszerű programú barátom. Próbálj különbséget tenni a két mondatrész között:
"all contemporary CPU architectures that implement virtual memory"
vs
"Intel processzorokban levő tervezési hiba miatt"

Ha még mindig nem értenéd egy kis szamárvezető számodra:
Typically, one is used to map the user address space (lower half) whereas the other is used to map the kernel address space (upper half). Gruss et al. [6] speculated that this might be one of the reasons why the attack does not work on ARM processors. As x86-64 has only one translation-table register (CR3), it is used for both user and kernel address space. Consequently, to perform privilege checks upon a memory access, the actual page translation tables have to be checked.

Tisztelt Uram!

Hiába vagdalkozik, ezúttal is mellélőtt. Senkinek a másodnickje nem vagyok, mellesleg ha esetleg ránéz a userid-re, láthatja, hogy nem mai, másod- harmad- és sokadnicket pedig ritkán szoktak beregisztrálni az elsők közt (persze sose lehet tudni). Viszont mivel nincs kedvem paranoid egyedeket győzködni, a jövőben tiszteljen meg azzal, hogy egy szakmai témában nem kezd el személyeskedni, amikor esetleg Önnek nem tetsző véleménnyel találkozik.

A neten szokatlan magázós mód nem véletlen, a jövőben Önnel nem kívánok közelebbi kapcsolatba kerülni. Úgyhogy kérem, ne fárassza magát (és engem se) azzal, hogy erre válaszol.

Mit nézett be pubika??
Az volt a hamis kiinduló spekuláció, hogy minden modern cpu arch érintett, ergo a linux kernel fejlesztői baszták el.
Erre kiderül, hogy az Intel baszta el. Linux és Windows fejlesztők most próbálják szoftver oldalon befoltozni amit az Intelnél javíthatatlanul elszartak.
Tudod nem mindegy Manchesterben McLareneket osztogatnak vagy Moszkvában Moszkvicsokat fosztogatnak!
Sikerült neked is tátott szájjal befutni a faszerdőbe fogalmatlanul. Ne félj, nem vagy egyedül. A hupon erős a mezőny paszulyerdős kocogásban.

Normális HUP-ot használok!

Off:

„Tudod nem mindegy Manchesterben McLareneket osztogatnak vagy Moszkvában Moszkvicsokat fosztogatnak!”

Ezzel a nickel így elszúrni ezt a történetet. :-(

Mivel már elég sok változata kering a neten (például Volvóval; akkor sokan még azt sem tudták, hogy mi az a Volvó), így beszúrom az eredeti változatot, ahogy a rádióban hallottam:

A jereváni rádió a következő hírről számolt be: „Leningrádban Volgákat osztogatnak!”
Nemsokára érkezik a helyesbítés: „Nem Leningrádban, hanem Moszkvában, nem Volgákat, hanem Moszkvicsokat, és nem osztogatnak, hanem fosztogatnak.”

( turul16 v | 2018. 01. 02., k – 09:54 )

" Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches."

https://lwn.net/Articles/738975/

Alighanem ez nem tesz jot a legtobb virtualis halozotnak, proxynak, static webservernek, memcached ..
Lehet ez lesz az elso security `feature` amit tenyleg letiltok.

A Hardwares `fix` is rosszul hangzik, ha komolyan gondoljak a memoria cim feloldas szandekos lassitasiat.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.