linux-kernel - Re: missing patch

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

Message-ID: <20190802081559.GL26174@kroah.com>
Date:   Fri, 2 Aug 2019 10:15:59 +0200
From:   Greg KH <greg@...ah.com>
To:     Evalds Iodzevics <evalds.iodzevics@...il.com>
Cc:     stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: missing patch

On Sun, May 26, 2019 at 10:32:29AM +0300, Evalds Iodzevics wrote:
> Hi, sorry for super long delay i was a little bit busy but i finally
> got time to work this out in full.
> This applies to 4.4 and 4.9.
> 
> Intel requires CPUID eax=1 for microcode operations, microcode
> routines use sync_core() for this.
> Back in December of 2016 Andy Lutomirski submitted few patches
> https://lore.kernel.org/lkml/cover.1481307769.git.luto@kernel.org/
> 
> Second patch does not apply to 4.4 and 4.9 as it is revert
> 
> Unfortunately only the first one got backported to 4.4 and 4.9 and
> broke microcode early loading on 32 bit platforms because it always
> jumps past cpuid in sync_core() as data structure boot_cpu_data are
> not populated so early in code.
> 
> Thanks to Your recent backport of 4167709bbf826512a52ebd6aafda2be104adaec9
> the only place that uses sync_core() is
> arch/x86/include/microcode_intel.h it should use native_cpuid_eax(1)
> as in original Boris submitt.
> To make this work we should apply
> 5dedade6dfa243c130b85d1e4daba6f027805033 witch defines
> native_cpuid_eax and others.
> 
> As for c198b121b1a1d7a7171770c634cd49191bac4477 i think it is a good
> idea to include this as sync_core in present state behaves differently
> depending on call time, those compiler warnings can be ignored, on
> older compiler they are not generated and this compiles fine. I tested
> it on GCC 5.5

Can you submit the proper patches backported as a series so that I can
queue them up correctly?

thanks,

greg k-h