[CC: +affected coreboot folks, +coreboot mailing list]
Dear Thomas,
More affected people discussed this issue on the coreboot mailing list [1].
On 2019-01-14 18:37, Lendacky, Thomas wrote:
> On 1/14/19 11:09 AM, Paul Menzel wrote:
>> On 01/14/19 18:00, Lendacky, Thomas wrote:
>>> On 1/10/19
On 1/14/19 11:09 AM, Paul Menzel wrote:
> Dear Thomas,
>
>
> Thank you for checking this, and coming back with the results so quickly.
>
> On 01/14/19 18:00, Lendacky, Thomas wrote:
>> On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
>>> On 1/10/19 10:49 AM, Paul Menzel wrote:
Dear Boris, dear
Dear Thomas,
Thank you for checking this, and coming back with the results so quickly.
On 01/14/19 18:00, Lendacky, Thomas wrote:
> On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
>> On 1/10/19 10:49 AM, Paul Menzel wrote:
>>> Dear Boris, dear Thomas,
>>>
>>>
>>> On 01/10/19 17:00, Borislav Petkov
On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
> On 1/10/19 10:49 AM, Paul Menzel wrote:
>> Dear Boris, dear Thomas,
>>
>>
>> On 01/10/19 17:00, Borislav Petkov wrote:
>>> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
Thank you very much. Indeed, the machine does not crash. I
On 1/10/19 10:49 AM, Paul Menzel wrote:
> Dear Boris, dear Thomas,
>
>
> On 01/10/19 17:00, Borislav Petkov wrote:
>> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
>>> Thank you very much. Indeed, the machine does not crash. I used Linus’
>>> master branch for testing, and applied
Dear Boris, dear Thomas,
On 01/10/19 17:00, Borislav Petkov wrote:
> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
>> Thank you very much. Indeed, the machine does not crash. I used Linus’
>> master branch for testing, and applied your patch on top. Please find
>> the full log
On Thu, Jan 10, 2019 at 03:53:11PM +, Lendacky, Thomas wrote:
> Checking the original log file again, it showed the mitigation message
> for IBPB that is just after the above switch statement, so this print
> output is expected. What about applying this patch on top of the patch
> from Boris:
On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
> Thank you very much. Indeed, the machine does not crash. I used Linus’
> master branch for testing, and applied your patch on top. Please find
> the full log attached.
> 80.649: [3.197107] Spectre V2 :
On 1/10/19 7:57 AM, Paul Menzel wrote:
> Dear Borislav,
>
>
> On 01/09/19 22:11, Borislav Petkov wrote:
>> On Wed, Jan 09, 2019 at 05:34:11PM +0100, Paul Menzel wrote:
>>> Is there a way to trace the value of `boot_cpu_data` from
>>> `arch/x86/include/asm/cpufeature.h` with some Linux Kernel
On Wed, Jan 09, 2019 at 05:34:11PM +0100, Paul Menzel wrote:
> 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(_cpu_data, bit)
>
> Or is rebuilding with print statements
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
On 1/9/19 8:34 AM, Paul Menzel wrote:
> Dear Thomas,
>
>
> 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.
Dear Thomas,
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:
On 1/9/19 7:35 AM, Paul Menzel wrote:
> Dear Thomas,
>
>
> 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:
Dear Thomas,
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
>>
Dear Jiri, dear Thomas, dear Borislav,
On 01/09/19 13:06, Paul Menzel wrote:
> On 01/04/19 17:42, Jiri Kosina wrote:
>>
>> [ added some CCs ]
>
> Thank you for your reply and taking care of that. I am sorry for the
> late reply. It took a while to test this.
>
>> On Thu, 3 Jan 2019, Paul
Paul,
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
On 1/4/19 9:47 AM, Borislav Petkov wrote:
> On Fri, Jan 04, 2019 at 01:41:25PM +0100, Paul Menzel wrote:
>> Dear Linux folks,
>>
>>
>> On 01/03/19 22:45, Paul Menzel wrote:
>>
>>> On the server board Asus KGPE-D16 with AMD Opteron 6278 processor updating
>>> the microcode update in the firmware
[ added some CCs ]
On Thu, 3 Jan 2019, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On the server board Asus KGPE-D16 with AMD Opteron 6278 processor updating the
> microcode update in the firmware from 0x0600062e to 0x0600063e seems to cause
> a general protection fault with Linux 4.14.87
On Fri, Jan 04, 2019 at 01:41:25PM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On 01/03/19 22:45, Paul Menzel wrote:
>
> > On the server board Asus KGPE-D16 with AMD Opteron 6278 processor updating
> > the microcode update in the firmware from 0x0600062e to 0x0600063e seems to
> >
Dear Linux folks,
On 01/03/19 22:45, Paul Menzel wrote:
> On the server board Asus KGPE-D16 with AMD Opteron 6278 processor updating
> the microcode update in the firmware from 0x0600062e to 0x0600063e seems to
> cause a general protection fault with Linux 4.14.87 and 4.20-rc7.
>
>> 46.859:
21 matches
Mail list logo
