Build errors in v4.4-stable-queue (i386)

Build errors in v4.4-stable-queue (i386)

[Guenter Roeck]

Building i386:defconfig ... failed
--------------
Error log:
arch/x86/entry/entry_32.S: Assembler messages:
arch/x86/entry/entry_32.S:230: Error: too many memory references for `mov'

Guenter

Re: Build errors in v4.4-stable-queue (i386)

[Greg Kroah-Hartman]

On Thu, Jan 18, 2018 at 08:41:58AM -0800, Guenter Roeck wrote:
> Building i386:defconfig ... failed
> --------------
> Error log:
> arch/x86/entry/entry_32.S: Assembler messages:
> arch/x86/entry/entry_32.S:230: Error: too many memory references for `mov'

Ick, no good, 0-day has pointed this out as well.

Razvan and David, any ideas?

thanks,

greg k-h

Re: Build errors in v4.4-stable-queue (i386)

[David Woodhouse]

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

On Thu, 2018-01-18 at 19:10 +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 18, 2018 at 08:41:58AM -0800, Guenter Roeck wrote:
> > 
> > Building i386:defconfig ... failed
> > --------------
> > Error log:
> > arch/x86/entry/entry_32.S: Assembler messages:
> > arch/x86/entry/entry_32.S:230: Error: too many memory references
> > for `mov'
> Ick, no good, 0-day has pointed this out as well.
> 
> Razvan and David, any ideas?


	CALL_NOSPEC PT_EBX(%esp)

That turns into a retpoline with

        mov PT_EBX(%esp), 0(%esp)

Which is doubly wrong, because not only can't you have two memory
operands to a 'mov' but %esp has already *moved* by the time we get
here so we'd be using the wrong source anyway.

We need to pick a victim register and load PT_EBX(%esp) into it, then
CALL_NOSPEC %\reg.

We'll fix this and also the RSP-clobbering in context switch that you
just sent a "fails to apply" message for.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: Build errors in v4.4-stable-queue (i386)

[David Woodhouse]

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

On Fri, 2018-01-19 at 10:34 +0100, David Woodhouse wrote:
> On Thu, 2018-01-18 at 19:10 +0100, Greg Kroah-Hartman wrote:
> > 
> > On Thu, Jan 18, 2018 at 08:41:58AM -0800, Guenter Roeck wrote:
> > > 
> > > 
> > > Building i386:defconfig ... failed
> > > --------------
> > > Error log:
> > > arch/x86/entry/entry_32.S: Assembler messages:
> > > arch/x86/entry/entry_32.S:230: Error: too many memory references
> > > for `mov'
> > Ick, no good, 0-day has pointed this out as well.
> > 
> > Razvan and David, any ideas?
> 
> 	CALL_NOSPEC PT_EBX(%esp)
> 
> That turns into a retpoline with
> 
>         mov PT_EBX(%esp), 0(%esp)
> 
> Which is doubly wrong, because not only can't you have two memory
> operands to a 'mov' but %esp has already *moved* by the time we get
> here so we'd be using the wrong source anyway.
> 
> We need to pick a victim register and load PT_EBX(%esp) into it, then
> CALL_NOSPEC %\reg.
> 
> We'll fix this and also the RSP-clobbering in context switch that you
> just sent a "fails to apply" message for.

Try this. Not even build tested. I think we can have %edx here, as it
would be the second argument to the kthread function, and clobbered by
it too.

Signed-off-by-if-it-works: David Woodhouse <dwmw@amazon.co.uk>

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -227,7 +227,8 @@ ENTRY(ret_from_kernel_thread)
        pushl   $0x0202                         # Reset kernel eflags
        popfl
        movl    PT_EBP(%esp), %eax
-       CALL_NOSPEC PT_EBX(%esp)
+       movl    PT_EBX(%esp), %edx
+       CALL_NOSPEC %edx
        movl    $0, PT_EAX(%esp)
 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: Build errors in v4.4-stable-queue (i386)

[Greg Kroah-Hartman]

On Fri, Jan 19, 2018 at 11:21:54AM +0100, David Woodhouse wrote:
> On Fri, 2018-01-19 at 10:34 +0100, David Woodhouse wrote:
> > On Thu, 2018-01-18 at 19:10 +0100, Greg Kroah-Hartman wrote:
> > > 
> > > On Thu, Jan 18, 2018 at 08:41:58AM -0800, Guenter Roeck wrote:
> > > > 
> > > > 
> > > > Building i386:defconfig ... failed
> > > > --------------
> > > > Error log:
> > > > arch/x86/entry/entry_32.S: Assembler messages:
> > > > arch/x86/entry/entry_32.S:230: Error: too many memory references
> > > > for `mov'
> > > Ick, no good, 0-day has pointed this out as well.
> > > 
> > > Razvan and David, any ideas?
> > 
> > 	CALL_NOSPEC PT_EBX(%esp)
> > 
> > That turns into a retpoline with
> > 
> > � � � � mov PT_EBX(%esp), 0(%esp)
> > 
> > Which is doubly wrong, because not only can't you have two memory
> > operands to a 'mov' but %esp has already *moved* by the time we get
> > here so we'd be using the wrong source anyway.
> > 
> > We need to pick a victim register and load PT_EBX(%esp) into it, then
> > CALL_NOSPEC %\reg.
> > 
> > We'll fix this and also the RSP-clobbering in context switch that you
> > just sent a "fails to apply" message for.
> 
> Try this. Not even build tested. I think we can have %edx here, as it
> would be the second argument to the kthread function, and clobbered by
> it too.
> 
> Signed-off-by-if-it-works: David Woodhouse <dwmw@amazon.co.uk>
> 
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -227,7 +227,8 @@ ENTRY(ret_from_kernel_thread)
> ��������pushl���$0x0202�������������������������# Reset kernel eflags
> ��������popfl
> ��������movl����PT_EBP(%esp), %eax
> -�������CALL_NOSPEC PT_EBX(%esp)
> +�������movl����PT_EBX(%esp), %edx
> +�������CALL_NOSPEC %edx
> ��������movl����$0, PT_EAX(%esp)
> �

I don't have a way to test this, I'll merge it into the existing patch
and push out a new tree to see how 0-day and Guenter's build-farm handle
it.

thanks,

greg k-h

Re: Build errors in v4.4-stable-queue (i386)

[David Woodhouse]

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

On Fri, 2018-01-19 at 13:26 +0100, Greg Kroah-Hartman wrote:
> 
> I don't have a way to test this, I'll merge it into the existing patch
> and push out a new tree to see how 0-day and Guenter's build-farm handle
> it.

It seems to work (and boot in qemu) here.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: Build errors in v4.4-stable-queue (i386)

[Greg Kroah-Hartman]

On Fri, Jan 19, 2018 at 02:08:35PM +0100, David Woodhouse wrote:
> On Fri, 2018-01-19 at 13:26 +0100, Greg Kroah-Hartman wrote:
> > 
> > I don't have a way to test this, I'll merge it into the existing patch
> > and push out a new tree to see how 0-day and Guenter's build-farm handle
> > it.
> 
> It seems to work (and boot in qemu) here.

Ok, great, thanks for the fix.

greg k-h

Re: Build errors in v4.4-stable-queue (i386)

[Guenter Roeck]

On Fri, Jan 19, 2018 at 02:08:35PM +0100, David Woodhouse wrote:
> On Fri, 2018-01-19 at 13:26 +0100, Greg Kroah-Hartman wrote:
> > 
> > I don't have a way to test this, I'll merge it into the existing patch
> > and push out a new tree to see how 0-day and Guenter's build-farm handle
> > it.
> 
> It seems to work (and boot in qemu) here.

Same here.

Guenter

Re: Build errors in v4.4-stable-queue (i386)

[Greg Kroah-Hartman]

On Fri, Jan 19, 2018 at 10:28:40AM -0800, Guenter Roeck wrote:
> On Fri, Jan 19, 2018 at 02:08:35PM +0100, David Woodhouse wrote:
> > On Fri, 2018-01-19 at 13:26 +0100, Greg Kroah-Hartman wrote:
> > > 
> > > I don't have a way to test this, I'll merge it into the existing patch
> > > and push out a new tree to see how 0-day and Guenter's build-farm handle
> > > it.
> > 
> > It seems to work (and boot in qemu) here.
> 
> Same here.

Great, thanks for letting me know.  It also looked to pass the 0-day
bot, so I'll keep the update in the patch queue.

greg k-h