All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
To: Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>,
	lguest-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>,
	xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org
Subject: Re: lguest: unhandled trap 13 and CONFIG_MICROCODE_INTEL_EARLY
Date: Mon, 06 May 2013 13:52:32 +0930	[thread overview]
Message-ID: <87li7srb3r.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1367450300.11532.32.camel-uMdlDhfIn7prKue/0VVhAg@public.gmane.org>

Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org> writes:
> 0) Since v3.9 launching a guest kernel with the lguest tool triggers an
> "unhandled trap 13" error if CONFIG_MICROCODE_INTEL_EARLY is set (and
> one runs on an Intel CPU). That option was introduced in v3.9.

Yech... me too:

lguest: unhandled trap 13 at 0x537b8d (0x0)

> 1) For instance, on qemu I ran into this error:
>     lguest: unhandled trap 13 at 0x97087d (0x0)
>
> 2) Disassembling that address (with the page offset added) in vmlinux
> (in gdb) showed:
>
> Dump of assembler code for function collect_cpu_info_early:
>    0xc09707e4 <+0>:     push   %ebp
>    [...]
>    0xc097087d <+153>:   wrmsr  
>    [...]
>    0xc09708a5 <+193>:   ret    
> End of assembler dump.
>
> 3) The internet tells me wrmsr will trigger a general protection fault
> if the CPU is not running in ring 0. And a guest kernel seems to do that
> since v3.9:
>
> arch/x86/kernel/head_32.S:call load_ucode_bsp
>      arch/x86/kernel/microcode_core_early.c:load_ucode_bsp()
>          arch/x86/kernel/microcode_intel_early.c:_load_ucode_intel_bsp()
>                                                      collect_cpu_info_early()

Yes, there's also the known issue that CONFIG_OLPC breaks lguest boot.

HPA, how about we extend the KEEP_SEGMENTS flag to mean "don't touch
privileged registers" in general?  That's what it used to do when it
was introduced, and AFAIK only lguest uses it.  Xen folk CC'd.

%ebx seems to be free, how about something like this?

Subject: x86: treat KEEP_SEGMENTS flag as advice not to try any privileged operations

The i386 boot path used to only do one privileged thing before entering the
per-platform boot-path: load segments.  Thus KEEP_SEGMENTS was born, used
by lguest (and could be used by others like Xen).

CONFIG_OLPC and CONFIG_MICROCODE_EARLY were added since then, so with those
options, lguest guest crash.  I've been telling people to turn them off, but
that's a bit naff.

Expand KEEP_SEGMENTS to mean "don't try to do ring0 stuff" and it does the
right thing.

Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 73afd11..8b50829 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -89,8 +89,9 @@ ENTRY(startup_32)
 	movl pa(stack_start),%ecx
 	
 	/* test KEEP_SEGMENTS flag to see if the bootloader is asking
-		us to not reload segments */
-	testb $(1<<6), BP_loadflags(%esi)
+		us to not reload segments: keep in %ebx. */
+	movb BP_loadflags(%esi),%ebx
+	andb $(1<<6),%ebx
 	jnz 2f
 
 /*
@@ -138,6 +139,9 @@ ENTRY(startup_32)
 	movsl
 1:
 
+	/* KEEP_SEGMENTS implies we don't touch priv regs at all. */
+	andb %ebx,%ebx
+	jnz 2f
 #ifdef CONFIG_OLPC
 	/* save OFW's pgdir table for later use when calling into OFW */
 	movl %cr3, %eax
@@ -149,6 +153,7 @@ ENTRY(startup_32)
 	call load_ucode_bsp
 #endif
 
+2:
 /*
  * Initialize page tables.  This creates a PDE and a set of page
  * tables, which are located immediately beyond __brk_base.  The variable

       reply	other threads:[~2013-05-06  4:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1367450300.11532.32.camel@x61.thuisdomein>
     [not found] ` <1367450300.11532.32.camel-uMdlDhfIn7prKue/0VVhAg@public.gmane.org>
2013-05-06  4:22   ` Rusty Russell [this message]
     [not found]     ` <87li7srb3r.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2013-05-06 14:51       ` lguest: unhandled trap 13 and CONFIG_MICROCODE_INTEL_EARLY H. Peter Anvin
     [not found]         ` <5187C369.5020902-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2013-05-07  5:18           ` Rusty Russell
2013-05-08 17:20             ` [Lguest] " Konrad Rzeszutek Wilk
     [not found]               ` <20130508172040.GA1256-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2013-05-08 18:07                 ` [Xen-devel] " H. Peter Anvin
2013-05-10 14:51                   ` Is: paravirt docs and diet. Was:Re: [Lguest] " Konrad Rzeszutek Wilk
     [not found]                     ` <20130510145137.GJ19520-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2013-05-10 17:19                       ` Is: paravirt docs and diet. Was:Re: [Xen-devel] " H. Peter Anvin
2013-05-10 17:53                         ` Is: paravirt docs and diet. Was:Re: [Lguest] " Matt Wilson
     [not found]                           ` <20130510175326.GD10713-reOQivfqS6pSvVcqp95Imk58d5RJRbtSwVDGBwiNqrNWk0Htik3J/w@public.gmane.org>
2013-05-10 18:07                             ` [Xen-devel] Is: paravirt docs and diet. Was:Re: " H. Peter Anvin
2013-05-13 20:11                               ` Is: paravirt docs and diet. Was:Re: [Lguest] " Konrad Rzeszutek Wilk
2013-05-09  1:43                 ` [Xen-devel] " Rusty Russell
     [not found]                   ` <8738txnd13.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2013-05-09  3:24                     ` H. Peter Anvin
     [not found]                       ` <518B1702.7010307-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2013-05-09  8:24                         ` Paul Bolle
     [not found]             ` <87mws7nzag.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2013-05-09  2:50               ` H. Peter Anvin

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=87li7srb3r.fsf@rustcorp.com.au \
    --to=rusty-8n+1lvoiyb80n/f98k4iww@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=jeremy-TSDbQ3PG+2Y@public.gmane.org \
    --cc=lguest-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org \
    --cc=xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.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: link
Be 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.