linux-kernel - Re: x86: A process doesn't stop on hw breakpoints sometimes

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]

Message-ID: <20160524232958.GA14477@redhat.com>
Date:	Wed, 25 May 2016 01:29:58 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andrei Vagin <avagin@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
	Andy Lutomirski <luto@...nel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: Re: x86: A process doesn't stop on hw breakpoints sometimes

On 05/23, Andy Lutomirski wrote:
>
> I'm guessing you're either hitting a subtle bug in the mess that is
> breakpoint handling or you're hitting a bug in perf's context switch
> code.

yes, same feeling...

> Given that the breakpoint gets missed many times in a row,

yes, the child specially tries to hit the same bp again and again,

> this is
> presumably either a bug in breakpoint programming (i.e. the thing
> isn't actually set in dr0/dr7) or a bug in the bp state tracking.

or some buf in perf_sched_in(). In fact this is what I think now, but
I can be wrong.

> If
> it were a bug in RF flag handling, I'd expect it to skip once and trip
> the second time through.

Exactly.

It would be nice to ensure that this problem has actually gone, and how.

So, Andrei, if you have any motivation, we can continue. The next step
needs a simple kernel patch or kernel module which allows to read dr0/dr7
and print these registers in the "fail" loop.

Oleg.