linux-kernel - Re: [GIT PULL v4.5] Fix INT1 recursion with unregistered breakpoints

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAO6TR8W=tF_gDyVJEHG1smgP_98ecg_yVrX0qPbe4B2uo9g86Q@mail.gmail.com>
Date:	Mon, 11 Jan 2016 17:55:43 -0700
From:	Jeff Merkey <linux.mdb@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: [GIT PULL v4.5] Fix INT1 recursion with unregistered breakpoints

On 1/11/16, Andy Lutomirski <luto@...capital.net> wrote:
> On Mon, Jan 11, 2016 at 4:44 PM, Jeff Merkey <linux.mdb@...il.com> wrote:
>> Hi Thomas,
>>
>> I agree with #2, we should clear the breakpoint.  As for #1, if
>> there's an execute breakpoint it MUST be cleared or it will just fire
>> off again when it sees the iretd from the int1 exception handler.  I
>> do use the breakpoint API Thomas, this showed up while debugging and
>> testing the API with "lazy debug register switching".
>>
>> So do you want me to expand the patch and clear the breakpoint?  Just
>> give the word and I'll get busy and GIT -R- DONE.
>
> It seems to me that you're papering over some issue instead of fixing
> the root cause.  If you're using the API, then either you're doing it
> wrong or the API is broken.  Can you figure out which and fix it?
>
> --Andy
>

That's what I did, the API is broken,  you can't trigger an int1
exception and not set the resume flag -- this is what clears the
exception, otherwise the hardware will just keep firing off the int1
exception until someone sets and loads the resume flag in the
processor.

I can try to explain this again, but the way the hardware works is:

INT1 -> call exception handler (execute breakpoint)
handler clears traps flag and sets resume flag
(Exception cleared)

if you don't set the resume flag then

INT1 -> call exeception handler
RF not set
iretd instruction
INT1 -> call exception handler
INT1 -> call exception handler
INT1 -> call exception handler
... forever ...

So the hardware just keep firing off at the same execution address and
not move forward.  the resume flag tells the processor to step into
the next instruction in the pipeline.  If never set, the instruction
pointer will never advance.  This is how intel processors work.

Jeff