From: Jeremy Fitzhardinge <jeremy@goop.org> To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Xen Devel <Xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Date: Mon, 31 Jan 2011 10:17:03 -0800 [thread overview] Message-ID: <4D46FC9F.6090309@goop.org> (raw) In-Reply-To: <20110131070241.GA22071@liondog.tnic> On 01/30/2011 11:02 PM, Borislav Petkov wrote: >> Well, I was trying to avoid putting Xen-specific code into the existing >> Intel/AMD loaders. That doesn't seem any cleaner. >> >> I could export "my firmware pathname" functions from them and have the >> Xen driver call those, rather than duplicating the pathname construction >> code. Would that help address your concerns? > Well, I was thinking even more radically than that. How about > > 1. microcode_xen.c figures out which struct microcode_ops to use based > on the hw vendor; > > 2. overwrites the ->apply_microcode ptr with the hypercall wrapper > > 3. dom0 uses it to load the firmware image and do all checks to it That could be made to work, but I don't really see it as being an improvement. The whole "overwriting bits of other people's ops structures" thing seems like a pretty bad idea for long term maintainability. > 4. eventually, the hypervisor gets to apply the _verified_ microcode > image (no more checks needed) using the vendor-specific application > method. > > This way there's almost no code duplication, you'll be reusing the > vendor-supplied code in baremetal which gets tested and updated > everytime it needs to and will save you a bunch of work everytime > there's change to it needed to replicate it into the hypervisor. In general Xen tries to avoid trusting its domains. Admittedly, dom0 is special in that it is already somewhat trusted, but even dom0 is constrained by Xen. For microcode, Xen just depends on it to provide a best-possible microcode file, then Xen+the CPU do the work of fully validating it and installing it. > Btw, if the code within the hypervisor is similar to the kernel's, you > could even save the original ->apply_microcode() pointer from step 2 and > call it in the hypervisor when the XENPF_microcode_update hypercall op > gets called. This way you have 0 code duplication. The hypervisor and its domains are completely separate pieces of code. This is akin to suggesting the kernel directly jump through a pointer and to run some usermode code. J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org> To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger> Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Date: Mon, 31 Jan 2011 10:17:03 -0800 [thread overview] Message-ID: <4D46FC9F.6090309@goop.org> (raw) In-Reply-To: <20110131070241.GA22071@liondog.tnic> On 01/30/2011 11:02 PM, Borislav Petkov wrote: >> Well, I was trying to avoid putting Xen-specific code into the existing >> Intel/AMD loaders. That doesn't seem any cleaner. >> >> I could export "my firmware pathname" functions from them and have the >> Xen driver call those, rather than duplicating the pathname construction >> code. Would that help address your concerns? > Well, I was thinking even more radically than that. How about > > 1. microcode_xen.c figures out which struct microcode_ops to use based > on the hw vendor; > > 2. overwrites the ->apply_microcode ptr with the hypercall wrapper > > 3. dom0 uses it to load the firmware image and do all checks to it That could be made to work, but I don't really see it as being an improvement. The whole "overwriting bits of other people's ops structures" thing seems like a pretty bad idea for long term maintainability. > 4. eventually, the hypervisor gets to apply the _verified_ microcode > image (no more checks needed) using the vendor-specific application > method. > > This way there's almost no code duplication, you'll be reusing the > vendor-supplied code in baremetal which gets tested and updated > everytime it needs to and will save you a bunch of work everytime > there's change to it needed to replicate it into the hypervisor. In general Xen tries to avoid trusting its domains. Admittedly, dom0 is special in that it is already somewhat trusted, but even dom0 is constrained by Xen. For microcode, Xen just depends on it to provide a best-possible microcode file, then Xen+the CPU do the work of fully validating it and installing it. > Btw, if the code within the hypervisor is similar to the kernel's, you > could even save the original ->apply_microcode() pointer from step 2 and > call it in the hypervisor when the XENPF_microcode_update hypercall op > gets called. This way you have 0 code duplication. The hypervisor and its domains are completely separate pieces of code. This is akin to suggesting the kernel directly jump through a pointer and to run some usermode code. J
next prev parent reply other threads:[~2011-01-31 18:17 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-29 0:26 [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Jeremy Fitzhardinge [not found] ` <cover.1296260656.git.jeremy.fitzhardinge@citrix.com> 2011-01-29 0:26 ` [PATCH 1/2] xen dom0: Add support for the platform_ops hypercall Jeremy Fitzhardinge 2011-01-29 0:26 ` Jeremy Fitzhardinge 2011-01-29 0:26 ` [PATCH 2/2] xen: add CPU microcode update driver Jeremy Fitzhardinge 2011-01-30 11:33 ` [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Borislav Petkov 2011-01-31 2:34 ` Jeremy Fitzhardinge 2011-01-31 7:02 ` Borislav Petkov 2011-01-31 7:02 ` Borislav Petkov 2011-01-31 18:17 ` Jeremy Fitzhardinge [this message] 2011-01-31 18:17 ` Jeremy Fitzhardinge 2011-01-31 23:41 ` Borislav Petkov 2011-02-01 0:15 ` Jeremy Fitzhardinge 2011-02-01 0:15 ` Jeremy Fitzhardinge 2011-02-01 1:11 ` H. Peter Anvin 2011-02-01 22:52 ` Jeremy Fitzhardinge 2011-02-01 22:52 ` Jeremy Fitzhardinge 2011-02-02 19:52 ` H. Peter Anvin 2011-02-02 20:05 ` Jeremy Fitzhardinge 2011-02-02 20:34 ` Thomas Gleixner 2011-02-02 20:34 ` Thomas Gleixner 2011-02-03 0:55 ` Henrique de Moraes Holschuh 2011-02-03 0:58 ` H. Peter Anvin 2011-02-03 7:47 ` Borislav Petkov 2011-02-03 16:05 ` Henrique de Moraes Holschuh 2011-02-03 16:05 ` Henrique de Moraes Holschuh 2011-02-02 20:57 ` Borislav Petkov 2011-02-02 20:57 ` Borislav Petkov 2011-02-02 21:47 ` H. Peter Anvin 2011-02-02 21:47 ` H. Peter Anvin 2011-02-03 18:25 ` Borislav Petkov 2011-02-03 18:33 ` H. Peter Anvin 2011-02-03 18:33 ` H. Peter Anvin 2011-02-01 11:00 ` Borislav Petkov 2011-02-01 23:12 ` Jeremy Fitzhardinge 2011-02-01 23:12 ` Jeremy Fitzhardinge 2011-02-02 9:54 ` Borislav Petkov 2011-02-02 9:54 ` Borislav Petkov 2011-02-02 12:48 ` Henrique de Moraes Holschuh 2011-02-02 12:48 ` Henrique de Moraes Holschuh 2011-02-02 18:05 ` Jeremy Fitzhardinge 2011-02-02 18:05 ` Jeremy Fitzhardinge 2011-02-02 18:29 ` Jeremy Fitzhardinge 2011-02-02 18:29 ` Jeremy Fitzhardinge 2011-01-31 2:34 ` Jeremy Fitzhardinge
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4D46FC9F.6090309@goop.org \ --to=jeremy@goop.org \ --cc=Xen-devel@lists.xensource.com \ --cc=bp@alien8.de \ --cc=hpa@zytor.com \ --cc=jeremy.fitzhardinge@citrix.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@elte.hu \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.