Re: [RFC 4/7] mm: add page consistency checker implementation

[David Hildenbrand (Arm)]

>>>
>>> For something like a datacenter deployment I'd agree with you - the odds are
>>> too low to care. For an unsupervised self driving vehicle, where there's no
>>> human (locally or remotely) available to take over, I'd like the odds to be as
>>> low as possible :)
>>
>> I thought that people usually use special RT OSes (with proven logic etc) for
>> any safety-related systems. Using Linux on the core safety system sounds ...
>> scary.
> 
> RT OSes are indeed the current approach.
> 
> s/scary/exciting ;)

Not so exciting for the passengers ;)

> 
>> But, I'd expect corruption of other data (user pages? page tables?) a much
>> bigger problem than page al locator metdata? What am I missing that this here is
>> -- in context of the bigger problems there -- a thing we particularly care about?
> 
> You are very correct! The allocator work was fairly standalone, so it was an
> easy first project to tackle.

But in general, wouldn't we just expect ECC memory to give us an MCE, so we can
detect what was corrupted and act accordingly?

That's how it usually works: hw detects a memory corruption and injects an MCE.
We detect that we corrupted memmap state and kill the kernel.

Why does ECC not help here?

> 
> In general, the approach depends on what we're trying to defend from:
> 
> 1. bugs: an ASI-like MMU enforced "context" system.
> 2. physics: just like in most other areas - lots of redundancy. For example,
> consider redundant variables in safety critical code which exists as two
> copies: var_v1 = value and var_v2 = value XOR mask. When accessing them, read
> both copies, XOR the second back, compare.
> 
> There were a few sessions back in LPC about this. Here's the one from Bryan
> Huntsman which gives a good overview:
> https://www.youtube.com/watch?v=ie_ClBCed94

Thanks, but I fundamentally don't understand how RAS capabilities interact here?
We have mm/memory-failure.c for a reason :)

-- 
Cheers,

David