linux-kernel - Re: [PATCH] x86: fix typo(?) in step.c

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, 10 Mar 2008 20:44:08 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	"Jan Beulich" <jbeulich@...ell.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, <markus.t.metzger@...el.com>,
	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
	<hpa@...or.com>
Subject: Re: [PATCH] x86: fix typo(?) in step.c

> So, is this going to be fully reverted, or is it worth pointing out/fixing
> other issues? The thing I'm recognizing right now is that
> eee3af4a2c83a97fff107ddc445d9df6fded9ce4 made the writes to
> DebugCtlMSR unconditional, which means any attempt to do
> debugging on i[345]86 will ultimately cause the kernel to oops. All of
> that stuff should really depend on CONFIG_X86_DEBUGCTLMSR...

I think it would be wise to excise all the BTS-related additions until
after 2.6.25.  But I am too swamped already and not planning to do
anything about this myself.  But, that said, FWIW it does not look to
me like debugctlmsr will ever be written on hardware that doesn't
support it.  The stores are all only enabled if TIF_DEBUGCTLMSR gets
set and thread.debugctlmsr is nonzero.  That can't be set by ptrace
unless arch_has_block_step() returns true.

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/