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

Message-ID: <CADqhmmeCYNpYpCCG6Y0t+0gxacK-834Bshc+bLmav7ei+Xzx9g@mail.gmail.com>
Date:   Sun, 26 May 2019 10:32:29 +0300
From:   Evalds Iodzevics <evalds.iodzevics@...il.com>
To:     stable@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: missing patch

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

On Mon, Apr 1, 2019 at 7:59 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Apr 01, 2019 at 06:06:29PM +0200, Greg KH wrote:
> > On Sat, Mar 30, 2019 at 06:13:16PM +0200, Evalds Iodzevics wrote:
> > > Hi back in the December of 2016 there was commit
> > > "1c52d859cb2d417e7216d3e56bb7fea88444cec9"
> > >
> > > witch was followed shortly by  "c198b121b1a1d7a7171770c634cd49191bac4477"
> > >
> > > Unfortunately only the first commit was later included in long-term kernel
> > > branches such as 4.4 and 4.9 witch left some of microcode functionality
> > > broken on 32 bit systems
> > >
> > > I guess it should be easily fixed by including
> > > "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
> >
> > Now queued up, thanks!
>
> Hm, no, it causes a bunch of build warnings that look like things are
> about to break:
> arch/x86/kernel/alternative.o: warning: objtool: do_sync_core()+0x1b: unsupported instruction in callable function
> arch/x86/kernel/alternative.o: warning: objtool: text_poke_early()+0x83: unsupported instruction in callable function
> arch/x86/kernel/alternative.o: warning: objtool: apply_alternatives()+0x366: unsupported instruction in callable function
> arch/x86/kernel/alternative.o: warning: objtool: text_poke()+0x196: unsupported instruction in callable function
>
> So I'm going to drop this patch from both trees now.  Can you provide a
> working backported version, or find what else needs to be applied as
> well for this patch?
>
> thanks,
>
> greg k-h