[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1ucb0rt.fsf@nanos.tec.linutronix.de>
Date: Thu, 18 Jun 2020 22:02:30 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Cyril Hrubis <chrubis@...e.cz>,
Peter Zijlstra <peterz@...radead.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Alexandre Chartre <alexandre.chartre@...cle.com>,
kernel test robot <rong.a.chen@...el.com>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
Andy Lutomirski <luto@...nel.org>, ltp@...ts.linux.it
Subject: Re: [LTP] [x86/entry] 2bbc68f837: ltp.ptrace08.fail
Cyril Hrubis <chrubis@...e.cz> writes:
> What is does is to write:
>
> (void*)1 to u_debugreg[0]
> (void*)1 to u_debugreg[7]
> do_debug addr to u_debugreg[0]
>
> Looking at the kernel code the write to register 7 enables the breakpoints and
> what we attempt here is to change an invalid address to a valid one after we
> enabled the breakpoint but that's as far I can go.
>
> So does anyone has an idea how to trigger the bug without the do_debug function
> address? Would any valid kernel function address suffice?
According to https://www.openwall.com/lists/oss-security/2018/05/01/3
the trigger is to set the breakpoint to do_debug() and then execute
INT1, aka. ICEBP which ends up in do_debug() ....
In principle each kernel address is ok, but do_debug() is interesting
due to the recursion issue because user space can reach it by executing
INT1.
So you might check for exc_debug() if do_debug() is not available and
make the whole thing fail gracefully with a usefu error message.
Thanks,
tglx
Powered by blists - more mailing lists