linux-kernel - Re: [RFC Patch 1/9] Introducing generic hardware breakpoint handler interfaces

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: <20081017235838.7BD231544CB@magilla.localdomain>
Date:	Fri, 17 Oct 2008 16:58:38 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	prasad@...ux.vnet.ibm.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <mingo@...e.hu>,
	<jason.wessel@...driver.com>, <avi@...ranet.com>,
	<richardj_moore@...ibm.com>
Subject: Re: [RFC Patch 1/9] Introducing generic hardware breakpoint handler
 interfaces

> Hmm...  What happens on x86 if you have both an instruction breakpoint 
> and a data breakpoint triggered for the same instruction?  My old 386 
> manual seems to imply that you'll get two exceptions: a fault and a 
> trap.

Yes, those are not really "the same instruction".  The instruction
breakpoint gives you a fault-type debug exception, which means the
instruction hasn't actually been executed yet.  You then might not execute
it at all, if you change the PC in the trap frame.  To execute it, you have
to either set RF or disable that breakpoint, and then execute it.  If it
actually completes (doesn't have some other normal fault first like a page
fault, or an external interrupt first, etc), then you get a single-step
trap after it's executed.  As far as the hardware is concerned these two
events are entirely separate.

> There's another RF-related issue which the patch currently ignores.  
> Namely, what should happen if a new user breakpoint is registered at
> the current PC address?  We should force the RF flag to 0 so that the
> breakpoint will be triggered when execution resumes.  The problem is
> that it's not easy to tell whether the current PC corresponds to the
> same linear address as that registered for the breakpoint -- i.e., I
> don't know how the code should go about translating from virtual
> addresses to linear addresses.  Would this in fact always be the
> identity mapping?  Presumably not if we're in VM86 mode.

Um, punt?  There is the hair in step.c:convert_ip_to_linear, but, bah.
Well, I can see doing it, and it would integrate with the whole handling of
changes to ->ip, etc.  But here we have another fine example of the new can
of worms involved in getting RF handling correct.  I'm thoroughly convinced
we should drop instruction breakpoint support from the initial version of
the x86 patch and hash out this whole RF picture separately after we've got
the rest of hw_breakpoint somewhat more settled.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/