linux-kernel - Re: [PATCH 3.17 100/141] x86, microcode: Fix accessing dis_ucode

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

Message-ID: <b4d424e6-81b2-4b21-ab2f-3d403a455f57@default>
Date:	Wed, 26 Nov 2014 19:13:02 -0800 (PST)
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	<bp@...e.de>
Cc:	<konrad.wilk@...cle.com>, <x86@...nel.org>,
	<gregkh@...uxfoundation.org>, <david.vrabel@...rix.com>,
	<stable@...r.kernel.org>, <rshendershot@...si.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3.17 100/141] x86, microcode: Fix accessing dis_ucode_ldr
 on 32-bit


----- bp@...e.de wrote:

> On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote:
> > https://lkml.org/lkml/2014/11/25/973 is all I have right now.
> 
> Ok, so the Code: section from this splat says:
> 
>   25:   55                      push   %ebp
>   26:   89 e5                   mov    %esp,%ebp
>   28:   83 ec 08                sub    $0x8,%esp
>   2b:*  80 3d c0 ee 97 01 00    cmpb   $0x0,0x197eec0           <--
> trapping instruction
>   32:   89 1c 24                mov    %ebx,(%esp)
>   35:   89 74 24 04             mov    %esi,0x4(%esp)
>   39:   74 12                   je     0x4d
>   3b:   8b 1c 24                mov    (%esp),%ebx
>   3e:   8b                      .byte 0x8b
>   3f:   74                      .byte 0x74
> 
> which I can correlate to the dis_ucode_ldr test here:
> 
>         .loc 1 134 0
>         .loc 1 137 0
>         cmpb    $0, dis_ucode_ldr+1073741824    #, *_11
>         je      .L46    #,
> 
> 
> so we must be faulting when accessing that dis_ucode_ldr thing. But
> you
> said that accessing it through its virtual address doesn't fix the
> issue
> either. Which is very very strange...


I was confusing you: accessing dis_ucode_ldr by virtual address does work on PV. But we then fail later, in load_ucode_intel_ap(), because it also tries to use __pa_nodebug() which can't be used by PV.

So if accessing dis_ucode_ldr by virtual address is acceptable (although I don't think it is?) then we can stick dis_ucode_ldr=1 into xen_start_kernel() and then things look OK.

A better solution may be to replace cpuid in x86_guest() with 'return pv_info.paravirt_enabled' (or paravirt_enabled(), I guess). I gave it a quick spin (32-bit only) and it seems to work. I'll see how my overnight tests behave.

-boris

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