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]
Date:	Fri, 24 Sep 2010 18:24:34 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Greg KH <greg@...ah.com>
Cc:	"Roedel, Joerg" <Joerg.Roedel@....com>, Greg KH <gregkh@...e.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Erratum 383 fix for 32 bit x86 kernels

From: Greg KH <greg@...ah.com>
Date: Fri, Sep 24, 2010 at 12:02:06PM -0400

> >  extern unsigned long setup_trampoline(void);
> > +extern void __init setup_trampoline_page_table(void);
> >  extern void __init reserve_trampoline_memory(void);
> >  #else
> >  static inline void reserve_trampoline_memory(void) {};
> > +extern void __init setup_trampoline_page_table(void) {};
> >  #endif /* CONFIG_X86_TRAMPOLINE */
> 
> I don't think that last setup_trampoline_page_table() line is correct
> here.
> 
> Shouldn't it be:
> 	static inline void setup_trampoline_page_table(void) {};
> instead?
> 
> Otherwise I get the following error building the .32 code with this
> patch:
> 	  CC      arch/x86/kernel/setup.o
> 	  arch/x86/kernel/setup.c: In function ‘setup_arch’:
> 	  arch/x86/kernel/setup.c:1001:2: error: implicit declaration of function ‘setup_trampoline_page_table’
> 
> Is this really how the code looks upstream?
> 
> Hm, even with changing the function prototype, I still get an error
> building on the .32-stable tree on x86-64, so I'm dropping this patch
> from there.

Yeah, Joerg forgot 8848a91068c018bc91f597038a0f41462a0f88a4.

> Also, it didn't apply cleanly to .32-stable, I had to apply this chunk
> by hand, no big deal.
> 
> So, why not I just take the original git commits that are in Linus's
> tree?  That should work, right?  If so, do I just need to use those two
> above-mentioned commits?  Or something else?  I prefer taking the
> original commits as it makes spelunking over time much easier.

Sure, you need

1. fd89a137924e0710078c3ae855e7cec1c43cb845	<-- erratum fix
2. 8848a91068c018bc91f597038a0f41462a0f88a4	<-- build fix
3. b7d460897739e02f186425b7276e3fdb1595cea7	<-- VMSPLIT_* fix

in that order and they should cherry-pick fine.

Let me know if you need something tested on our end.

Thanks and sorry for the confusion.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ