linux-kernel - Re: [x86] only print out DR registers if they are not power-on defaults.

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 20 Jun 2013 07:29:12 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [x86] only print out DR registers if they are not power-on
 defaults.

On Wed, Jun 19, 2013 at 03:02:19PM -0700, H. Peter Anvin wrote:
> On 06/19/2013 02:52 PM, Borislav Petkov wrote:
> > On Wed, Jun 19, 2013 at 02:42:49PM -0700, H. Peter Anvin wrote:
> >> There is serious confusion with regards to DR6 about the bits which
> >> are *fixed* (forced to 1) and the ones which are *reserved* (should
> >> always have a fixed value.)
> >>
> >> There are some bits in DR6 which are used by hardware probes.
> > 
> > Haha, I knew it! HW guys don't care about the architectural documents.
> > 
> > Maybe DR6 should probably be dropped altogether from the check before
> > exiting __show_regs early?
> 
> Uhm... I think you're missing the point of architectural documents.
> 
> The architectural documents describe the contract between hardware and
> software.  It doesn't mean that hardware can't go beyond it... it is in
> fact the norm.  The architectural documentation states what software may
> rely on and within what bounds it can assume safe behavior to be
> compatible both now and with any future extensions.

Well, that I know :).

>From your comment above it sounded like we can't really rely on some of
the bits in DR6_RESERVED to be really always 1 as they cannot only be
*fixed* (forced to 1) but also be reserved with a fixed value which is
not necessarily 1.

And there's a section in the SDM "19.23.1 Differences in Debug Register
DR6" which says that some families allow writes to 1b of bit 12 while
others don't.

Now Dave stated earlier "I occasionally see DR6: 00000000fffe0ff0 for
eg." which says that bit 16 can be 0b but the AMD spec says "read as 1s"
and Intel's spec says "Reserved (set to 1)" which I only assume is the
same thing: the default state of those is 1.

So maybe the DR6 check should be reversed to actually look at only the
defined bits and ignore "volatile" reserved bits, whichever they might
be :-):

if (!(dr6 & 0xe00f))

I.e., bit slices [15:13] and [3:0] should be 0.

Then we can assume no breakpoint condition has been detected nor the
debug registers are being used in some way.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/