linux-kernel - Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0

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

Date:	Wed, 02 Feb 2011 10:05:23 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen Devel <Xen-devel@...ts.xensource.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen
 dom0

On 02/02/2011 01:54 AM, Borislav Petkov wrote:
> Ok, I'm reading your answers but I keep getting the impression that this
> discussion is not moving anywhere. You keep finding reasons why it can't
> be done and trying to persuade me that your way is the only way. Why is
> that?

I agree that this conversation has got bogged down.  I'm getting the
impression that you're not really understanding my answers within the
context of how Xen works, and so things are going in circles.  I'm happy
to go into more detail if you're interested.

I'm not trying to be obstructionist here.  We've often changed the way
things work on the Xen side to smooth the path into the kernel, and I'm
perfectly willing to do it again for the microcode driver if it makes
sense to do so.

> And I'm telling you microcode_xen has nothing to do among
> vendor-specific code. Since when is xen a hw vendor and deserves special
> attention? And don't tell me because people use it.

Who's asking for special attention?  I'm just trying to use the existing
microcode infrastructure for handling different methods of microcode
update to add one more.  Why is "because people use it" not a useful
thing to say?  If I said "but nobody uses it", then that would be a
strong argument for not including it.

>  It is absolutely
> inacceptable to add a bunch of code to arch/x86 just because you're
> telling me it can't be done differently, not intermixed with hw vendor
> code and just because a hypervisor vendor needs it.
You seem to have staked out a very... specific... position here, but I
don't agree with your premise that microcode_foo is specifically
microcode_<cpu-vendor>.  If you view it as microcode_<method of loading
microcode> then adding microcode_xen makes perfect sense.  Since it is a
small, self-contained piece of code that doesn't have any effects on any
other code, nor any dependencies aside from the microcode driver's
internal interface, I think it is a clean way to approach the problem.

Or to turn it around, what specific problems do you see arising from
implementing the Xen microcode loader in this way?  Why is adding a
third microcode_foo.c a problem?

>  Does that mean that
> if every other virtualization booth wants to add their special code to
> arch/x86, we just go and slap it in without questioning its design?

Of course not; the whole point of posting code for review is to get
feedback on both general and specific issues, and I appreciate the time
you've spent on this.  But I have to say I don't really understand what
your objections are.  Are you objecting to the very principle of adding
a new microcode driver, or is there something specific about the code I
posted that you have issues with?

Thanks,
    J
--
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/