On Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote:
> > Andy Lutomirski pointed out that sending SIGBUS to tasks that
> > hit poison in the kernel copying syscall parameters from user
> > address space is not the right semantic.
>
> What does that mean exactly?
Andy said that a task could check a memory range for poison by
doing:
ret = write(fd, buf, size);
if (ret == size) {
memory range is all good
}
That doesn't work if the kernel sends a SIGBUS.
It doesn't seem a likely scenario ... but Andy is correct that
the above ought to work.
>
> From looking at the code, that is this conditional:
>
> if (t == EX_HANDLER_UACCESS && regs && is_copy_from_user(regs)) {
> m->kflags |= MCE_IN_KERNEL_RECOV;
> m->kflags |= MCE_IN_KERNEL_COPYIN;
>
> so what does the above have to do with syscall params?
Most "copy from user" instances are the result of a system call parameter
(e.g. "buf" in the write(2) example above).
> If it is about us being in ring 0 and touching user memory and eating
> poison in same *user* memory while doing so, then sure, that makes
> sense.
Yes. This is for kernel reading memory belongng to "current" task.
> > So stop doing that. Add a new kill_me_never() call back that
> > simply unmaps and offlines the poison page.
>
> Right, that's the same as handling poisoned user memory.
Same in that the page gets unmapped. Different in that there
is no SIGBUS if the kernel did the access for the user.
-Tony
