All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jiri Kosina <jikos@kernel.org>, "x86@kernel.org" <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: General protection fault in `switch_mm_irqs_off()`
Date: Wed, 9 Jan 2019 17:34:11 +0100	[thread overview]
Message-ID: <9bca3e26-1dfc-6e86-cf28-90cadd983ff4@molgen.mpg.de> (raw)
In-Reply-To: <98ed83c0-3077-848b-9de4-add70e9b417a@amd.com>

[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]

Dear Thomas,


On 01/09/19 17:15, Lendacky, Thomas wrote:
> On 1/9/19 8:34 AM, Paul Menzel wrote:

>> On 01/09/19 15:29, Lendacky, Thomas wrote:
>>> On 1/9/19 7:35 AM, Paul Menzel wrote:
>>
>>>> On 01/09/19 14:16, Thomas Gleixner wrote:
>>>>
>>>>> On Wed, 9 Jan 2019, Paul Menzel wrote:
>>>>>> I get the same with microcode updates applied.
>>>>>>
>>>>>>     $ dmesg | grep 'microcode: CPU0: patch_level'
>>>>>>     [    3.809210] microcode: CPU0: patch_level=0x0600063e
>>>>>>     $ sudo modprobe msr
>>>>>>     $ sudo ./wrmsr 0x49 0x1
>>>>>>     wrmsr: CPU 0 cannot set MSR 0x00000049 to 0x0000000000000001
>>>>>>
>>>>>>> Could you please post /proc/cpuinfo from such a boot as well?
>>>>>
>>>>> /proc/cpuinfo unfortunately does not contain the amd specific IBPB flag,
>>>>> but the dmesg of the original report says:
>>>>>
>>>>>   Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
>>>>>
>>>>> which means, that the CPUID bit is set.
>>>>>
>>>>> Can you please provide the output of:
>>>>>
>>>>>   cpuid -1 -l 0x80000008 -r
>>>>>
>>>>> On my AMD Opteron(TM) Processor 6276 with microcode 0x600063d loaded I get:
>>>>>
>>>>>    0x80000008 0x00: eax=0x00003030 ebx=0x00000000 ecx=0x0000500f edx=0x00000000
>>>>>
>>>>> EBX is 0, which means that X86_FEATURE_AMD_IBPB is not enabled. So the
>>>>> kernel does not try to use the speculation control MSR (0x49).
>>>>
>>>> With CPUID 20180519, I get the output below with both microcode update versions.
>>>>
>>>> 0x600063d:
>>>>
>>>>     $ sudo ./cpuid -1 -l 0x80000008 -r
>>>>     CPU:
>>>>        0x80000008 0x00: eax=0x00003030 ebx=0x00000000 ecx=0x0000500f edx=0x00000000
>>>>
>>>> 0x600063e:
>>>>
>>>>     $ sudo ./cpuid -1 -l 0x80000008 -r
>>>>     CPU:
>>>>        0x80000008 0x00: eax=0x00003030 ebx=0x00000000 ecx=0x0000500f edx=0x00000000
>>>
>>> Hmmm... so ebx is 0 for both versions, so I'm not sure how IBPB is being
>>> set. What's the CPUID output for 0x07 (cpuid -1 -l 0x07 -r)?
>>
>>     $ sudo ./cpuid -1 -l 0x07 -r
>>     CPU:
>>        0x00000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
> 
> I'm confused then...  the only way that I can see that the IBPB feature
> can be set is if 0x80000008[EBX] bit 12 is set or if 0x07[EDX] bit 26 is
> set - neither of which is the case. I must be missing something...

Is there a way to trace the value of `boot_cpu_data` from
`arch/x86/include/asm/cpufeature.h` with some Linux Kernel magic?

    #define boot_cpu_has(bit)       cpu_has(&boot_cpu_data, bit)

Or is rebuilding with print statements the only solution?


Kind regards,

Paul


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]

  reply	other threads:[~2019-01-09 16:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03 21:45 General protection fault in `switch_mm_irqs_off()` Paul Menzel
2019-01-04 12:41 ` Paul Menzel
2019-01-04 15:47   ` Borislav Petkov
2019-01-04 17:32     ` Lendacky, Thomas
2019-01-04 16:42 ` Jiri Kosina
     [not found]   ` <cb7ba667-562b-1e4c-f16e-7c11804bc98a@molgen.mpg.de>
2019-01-09 13:16     ` Thomas Gleixner
2019-01-09 13:35       ` Paul Menzel
2019-01-09 14:29         ` Lendacky, Thomas
2019-01-09 14:34           ` Paul Menzel
2019-01-09 16:15             ` Lendacky, Thomas
2019-01-09 16:34               ` Paul Menzel [this message]
2019-01-09 21:11                 ` Borislav Petkov
     [not found]                   ` <9bbcbaa7-b164-fcef-0588-7c5f25aa2440@molgen.mpg.de>
2019-01-10 15:53                     ` Lendacky, Thomas
2019-01-10 16:02                       ` Borislav Petkov
2019-01-10 16:00                     ` Borislav Petkov
2019-01-10 16:49                       ` Paul Menzel
2019-01-10 18:34                         ` Lendacky, Thomas
2019-01-14 17:00                           ` Lendacky, Thomas
2019-01-14 17:09                             ` Paul Menzel
2019-01-14 17:37                               ` Lendacky, Thomas
2019-10-02 15:52                                 ` Paul Menzel
2019-01-09 13:19     ` Paul Menzel

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=9bca3e26-1dfc-6e86-cf28-90cadd983ff4@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --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: 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.