Google Proposes "Page Table Check" For Fighting Some Types Of Linux Memory Corruption

[phoronix]

Phoronix: Google Proposes "Page Table Check" For Fighting Some Types Of Linux Memory Corruption

Last week Google engineers uncovered a reference count underflow issue affecting all Linux kernels going back to v4.14 in 2017. This issue led to memory leaking from one process to another and only uncovered by accident. To address this class of memory corruption issues moving forward, Google is proposing a new "Page Table Check" feature moving forward...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Page-Table-Check-RFC

[perpetually high]

The Page Table Check feature will check for illegal sharing when pages are inserted/removed that there is no illegal sharing that stems from double mapping. If corruption is detected, the kernel will crash. As well, this extra checking does cause some performance implications as well as extra memory overhead.

I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?

[juxuanu]

Rewrite it in Rust 🤪

[CochainComplex]

Waiting for the first People recommending "just use WSL" as solution.

[waxhead]

I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?

If the kernel stop then what is the vector of attack then really? , why would you like to log a CORRUPTION and keep carrying on, essentially maintaining this corruption with the risk of causing more havoc such as a potential more serious attack vector, ruining your filesystems, spreading corrupted data over the network, or generally screwing up stuff somewhere....

It is all about what potentially cause more damage, and a crash is serious enough that it will sooner or later be fixed, thus fixing the root cause which in the long run is far better.

[waxhead]

Rewrite it in Rust 🤪

https://www.youtube.com/watch?v=1S1fISh-pag

[pgeorgi]

I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?

A crash mitigates the invalid state. With "log and carry on" you also have to insert a "clean up" step unless you like dealing with inconsistent system states, so you're spending effort on working around issues instead of fixing them while reducing the pain enough that fixes have no priority. A crash is a clean if harsh signal for "fix here", but once fixed you're done.

[vladpetric]

Rewrite it in Rust 🤪

AFAICT this is not the kind of problem that Rust automatically prevents.

[perpetually high]

waxhead pgeorgi Good points, thanks

[waxhead]

waxhead pgeorgi Good points, thanks

And thank you!. Kudos to you for giving out a thanks when you learned / re-thinked / viewed something differently. I wish I where better at that myself.