From: Borislav Petkov
> Sent: 21 December 2018 10:47
> On Fri, Dec 21, 2018 at 05:33:47PM +0800, WANG Chao wrote:
> > On 12/11/18 at 12:37P, WANG Chao wrote:
> > > Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend
> > > on compiler support"), RETPOLINE has been replaced by CONFIG_RETPOLINE.
> > >
> > > Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
> > > Signed-off-by: WANG Chao <chao.wang@xxxxxxxxx>
> >
> > ping ...
>
> This one somehow slipped through the cracks... :-\
>
> Ok, let's see: this could be relevant for the case when a module built
> with a compiler which doesn't support retpolines, gets loaded on a
> system which is built with retpolines.
Isn't the real problem someone taking a kernel from (say) kernel.org
that is compiled for retpolines and then trying to compile an additional
module on a system that has an old compiler?
> Which is pretty seldom as the majority of setups out there should have
> a retpoline-enabled compiler. And should not allow loading external
> modules anyway, but that's a different story.
Most of an external module is likely to be a big '.o' file that (I expect)
has to be compiled without retpolines in order to be linkable into old
kernels.
(Either that or it doesn't matter at all because it is just a change
to the generated code.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
