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

Date:	Mon, 10 Mar 2008 11:53:19 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	<markus.t.metzger@...el.com>, <tglx@...utronix.de>,
	"Roland McGrath" <roland@...hat.com>,
	<linux-kernel@...r.kernel.org>, <hpa@...or.com>
Subject: Re: [PATCH] x86: fix typo(?) in step.c

>>> Ingo Molnar <mingo@...e.hu> 06.03.08 14:11 >>>
>
>* Roland McGrath <roland@...hat.com> wrote:
>
>> I know.  That completely misses the point I just made:
>> 
>>    As I said then, one of my concerns was with the low-level tweaks 
>>    not yet sufficiently baked, independent from my reservations about 
>>    the ptrace feature.  Your #if'ing out of the user ABI additions for 
>>    2.6.25 does nothing to remove the unknown new risks from all the 
>>    tweaks with fingers in the low-level arch stuff.  This is the sort 
>>    of thing I was concerned about.
>> 
>> You didn't revert the parts that ever could have caused problems for 
>> anyone except those using the new ptrace extensions, i.e. changes to 
>> step.c, context switch, whatever else was touched we've lost track of 
>> now.  I keep saying that those are not baked, 100% independent of the 
>> ptrace feature.  You don't seem to be hearing me.
>
>well the issue is that both regset and bts had regressions, so the 
>safest was to do the minimal step of undoing any externally visible 
>changes. Feel free to send a reverter patch for the other lowlevel bts 
>bits as well.

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...

Jan

--
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/