linux-kernel - Re: [PATCH] x86: prevent unconditional writes to DebugCtl MSR

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:	Mon, 21 Apr 2008 14:30:30 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	"Jan Beulich" <jbeulich@...ell.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: prevent unconditional writes to DebugCtl MSR

> >agreed. Jan, wanna send a fix for this?
> 
> Hmm, without knowing the context here I'd say the way it's done in
> .25 is quite reasonable; a BUG_ON() here would seem quite rude to
> me. I thought it really should be the call sites ensuring this doesn't
> get called, and the silent ignoring is just to prevent bringing the
> system down. A WARN_ON() (or perhaps even WARN_ON_ONCE()) would
> be the most I'd be inclined to add there.

Like I said, the call sites already do ensure that it doesn't get called.
If there were any such bug, then the 2.6.25 behavior of silently being
broken is inordinately rude.  Since we think there is no such bug now, the
BUG_ON would not be hit, and if it is then it's deservedly so.  I don't
care whether it's a BUG_ON or a WARN_ON, since the point is that it never
happen.  What I object to is the change you made in 2.6.25, which ensures
that extra cycles at low level will be spent on every call, to guarantee
that any such bug in the future is maximally confusing.  That is not helping.

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/