[lkml]   [2018]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 08/24] x86,sme: Annotate indirect call
On Wed, Jan 31, 2018 at 10:29:21AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 26, 2018 at 10:37:30AM +0000, David Woodhouse wrote:
> > On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> > > This is boot code, we run this _way_ before userspace comes along to
> > > poison our branch predictor.
> >
> > Hm, objtool knows about sections, doesn't it? Why it is whining about
> > indirect jumps in inittext anyway?
> >
> > In fact, why are we even *doing* retpolines in inittext? Not that we
> > are; since we flipped the ALTERNATIVE logic around, at that point we
> > still have the 'oldinstr' which is a bare jmp anyway. We might as well
> > do this:

Ont the other hand, is there any harm in doing retpolines in .init.text?

I also had a similar question about the ANNOTATE_RETPOLINE_SAFE thing.

If there's no harm, it would be simpler and more robust to just do
retpolines everywhere and not worry about special cases.

(Forgetting paravirt for the moment, which is the eternal "special

I was also thinking about adding a debug option for _runtime_ retpoline
verification that decodes all kernel text and reports any indirect
branches it finds (yes, kind of like an in-kernel objtool). That would
be a lot more straightforward without special cases. Obviously
.init.text wouldn't be a problem there, but the other annotated safe
locations would.


 \ /
  Last update: 2018-01-31 16:05    [W:0.098 / U:0.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site