linux-kernel - Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 18 Feb 2020 19:36:51 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:     Christophe Leroy <christophe.leroy@....fr>,
        Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Anil S
 Keshavamurthy 
        <anil.s.keshavamurthy@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        "David S. Miller" <davem@...emloft.net>,
        Larry Finger <Larry.Finger@...inger.net>,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>, stable@...nel.vger.org
Subject: Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in
 real mode

Masami, Christophe,
Apologies for pitching in late here...

Masami Hiramatsu wrote:
> On Tue, 18 Feb 2020 12:04:41 +0100
> Christophe Leroy <christophe.leroy@....fr> wrote:
> 
>> >> Nevertheless, if one symbol has been forgotten in the blacklist, I think
>> >> it is a problem if it generate Oopses.
>> > 
>> > There is a long history also on x86 to make a blacklist. Anyway, how did
>> > you get this error on PPC32? Somewhere would you like to probe and
>> > it is a real mode function? Or, it happened unexpectedly?
>> 
>> The first Oops I got was triggered by a WARN_ON() kind of trap in real 
>> mode. The trap exception handler called kprobe_handler() which tried to 
>> read the instruction at the trap address (which was a real-mode address) 
>> so it triggered a Bad Access Fault.
>> 
>> This was initially the purpose of my patch.
> 
> OK, then filtering the trap reason in kprobe handler is a bit strange.
> It should be done in the previous stage (maybe in trap.c)
> Can we filter it by exception flag or only by checking the instruction
> which causes the exception, or needs get_kprobe()...?

I think Masami's earlier patch proposal to bail out early from 
kprobe_handler() is appropriate here. We don't support kprobe in real 
mode since we don't have a way to ensure that the pre/post handlers work 
properly.

We will obviously also have to blacklist some of the real mode code from 
being probed to begin with. In addition, we will also have to blacklist 
any location where we can't take a trap (MSR_RI being unset, as an 
example)

Christophe,
See some of the below patch series:
https://patchwork.ozlabs.org/patch/752336/
https://patchwork.ozlabs.org/patch/752333/
https://patchwork.ozlabs.org/patch/782399/


- Naveen