Re: [PATCH] kfence: check kfence canary in panic and reboot

[Shaobo Huang <huangshaobo6@huawei.com>]

> > From: huangshaobo <huangshaobo6@huawei.com>
> >
> > when writing out of bounds to the red zone, it can only be detected at
> > kfree. However, there were many scenarios before kfree that caused this
> > out-of-bounds write to not be detected. Therefore, it is necessary to
> > provide a method for actively detecting out-of-bounds writing to the red
> > zone, so that users can actively detect, and can be detected in the
> > system reboot or panic.
> >
> >
> After having analyzed a couple of KFENCE memory corruption reports in the
> wild, I have doubts that this approach will be helpful.
> 
> Note that KFENCE knows nothing about the memory access that performs the
> actual corruption.
> 
> It's rather easy to investigate corruptions of short-living objects, e.g.
> those that are allocated and freed within the same function. In that case,
> one can examine the region of the code between these two events and try to
> understand what exactly caused the corruption.
> 
> But for long-living objects checked at panic/reboot we'll effectively have
> only the allocation stack and will have to check all the places where the
> corrupted object was potentially used.
> Most of the time, such reports won't be actionable.
 
The detection mechanism of kfence is probabilistic. It is not easy to find a bug.
It is a pity to catch a bug without reporting it. and the cost of panic detection
is not large, so panic detection is still valuable.
 
> > for example, if the application memory is out of bounds and written to
> > the red zone in the kfence object, the system suddenly panics, and the
> > following log can be seen during system reset:
> > BUG: KFENCE: memory corruption in atomic_notifier_call_chain+0x49/0x70
[...]

thanks,
ShaoBo Huang