Re: [tip: x86/entry] x86/entry: Convert Divide Error to IDTENTRY

[Kees Cook]

On Sun, Oct 11, 2020 at 05:25:22PM +0200, Dmitry Vyukov wrote:
> On Tue, May 19, 2020 at 9:59 PM tip-bot2 for Thomas Gleixner
> <tip-bot2@xxxxxxxxxxxxx> wrote:
> >
> > The following commit has been merged into the x86/entry branch of tip:
> >
> > -DO_ERROR(X86_TRAP_DE,     SIGFPE,  FPE_INTDIV,   IP, "divide error",        divide_error)
> >
> > +DEFINE_IDTENTRY(exc_divide_error)
> > +{
> > +       do_error_trap(regs, 0, "divide_error", X86_TRAP_DE, SIGFPE,
> > +                     FPE_INTDIV, error_get_trap_addr(regs));
> > +}
> 
> I suppose this is a copy-paste typo and was supposed to be "divide
> error", right?
> Otherwise it changes how kernel oopses look like and breaks syzkaller
> crash parsing, and probably of every other kernel testing system that
> looks for kernel crashes.
> 
> syzkaller now says just the following for divide errors, without
> attribution to function/file/maintainers:
> 
> kernel panic: Fatal exception (3)
> FS:  0000000000000000(0000) GS:ffff8880ae500000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000004c9428 CR3: 0000000009e8d000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Kernel panic - not syncing: Fatal exception in interrupt
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> I will fix it up in syzkaller. It is now required anyway since this
> new crash mode is in git history, so needed for bisection and testing
> of older releases.
> 
> It is not the first time kernel crash output changes
> intentionally/unintentionally breaking kernel testing.
> But I wonder if LKDTM can be turned into actual executable tests that
> produce pass/fail and fix crash output for different oopses?
> Marco, you implemented some "output tests" for KCSAN. Can that be
> extended to other crash types? With some KUnit help? However, I am not
> sure about hard panics, they may not play well with unit-testing...

A lot of the behavioral tests in LKDTM end up triggering arch-specific
logging. I decided to avoid trying to consolidate it in favor of
actually getting the test coverage. :)

-- 
Kees Cook