* Re: Plumbers CF MCs
2021-03-23 8:35 ` Peter Zijlstra
@ 2021-03-23 8:45 ` Peter Zijlstra
2021-03-23 19:29 ` Andrew Cooper
` (3 subsequent siblings)
4 siblings, 0 replies; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-23 8:45 UTC (permalink / raw)
To: Nick Desaulniers
Cc: linux-toolchains, clang-built-linux, Steven Rostedt,
Jose E. Marchesi, Kees Cook, Florian Weimer, Christian Brauner,
nick.alcock, Segher Boessenkool, Josh Poimboeuf, Will Deacon,
andrew.cooper3
On Tue, Mar 23, 2021 at 09:35:10AM +0100, Peter Zijlstra wrote:
> There's the endless UB debate... can we define more to reduce the UB? I
> mean, we're already bound by architecture ABI on the one hand, and
> actual use on the other. It would be so very nice to be able to get more
> -fwrapv and -fno-strict-aliasing knobs that define UBs away.
One that might be nice is -fcdecl that tells the compiler about the
calling convention and gives us leaway to abuse function pointers (like
we already do anyway).
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Plumbers CF MCs
2021-03-23 8:35 ` Peter Zijlstra
2021-03-23 8:45 ` Peter Zijlstra
@ 2021-03-23 19:29 ` Andrew Cooper
2021-03-23 19:53 ` Peter Zijlstra
2021-03-23 22:26 ` Nick Desaulniers
2021-03-24 8:47 ` Christian Brauner
` (2 subsequent siblings)
4 siblings, 2 replies; 30+ messages in thread
From: Andrew Cooper @ 2021-03-23 19:29 UTC (permalink / raw)
To: Peter Zijlstra, Nick Desaulniers
Cc: linux-toolchains, clang-built-linux, Steven Rostedt,
Jose E. Marchesi, Kees Cook, Florian Weimer, Christian Brauner,
nick.alcock, Segher Boessenkool, Josh Poimboeuf, Will Deacon
On 23/03/2021 08:35, Peter Zijlstra wrote:
> There also is talk about straight line speculation mitigations. for x86
> we should probably emit an INT3 after every JMP and RET. Although this
> might not be controversial and be sorted by the time Plumbers happens.
I guess this one is levied at me.
Hopefully it isn't controversial in any way. I have just had sufficient
tuits to get around to making an x86 straight line speculation feature
request to the GCC and Clang communities yet.
For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
function pointers, jump tables) and RET instructions may speculatively
execute the next sequential instruction(s) before taking the control
flow change into account. Having some toolchain support to deal with
this would be great, and preferable to some of the asm hackary currently
under suggestion.
~Andrew
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Plumbers CF MCs
2021-03-23 19:29 ` Andrew Cooper
@ 2021-03-23 19:53 ` Peter Zijlstra
2021-03-23 22:12 ` Peter Zijlstra
` (2 more replies)
2021-03-23 22:26 ` Nick Desaulniers
1 sibling, 3 replies; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-23 19:53 UTC (permalink / raw)
To: Andrew Cooper
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper wrote:
> On 23/03/2021 08:35, Peter Zijlstra wrote:
> > There also is talk about straight line speculation mitigations. for x86
> > we should probably emit an INT3 after every JMP and RET. Although this
> > might not be controversial and be sorted by the time Plumbers happens.
>
> I guess this one is levied at me.
>
> Hopefully it isn't controversial in any way. I have just had sufficient
> tuits to get around to making an x86 straight line speculation feature
> request to the GCC and Clang communities yet.
Yep, just making sure it doesn't get lost.
> For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
> function pointers, jump tables) and RET instructions may speculatively
> execute the next sequential instruction(s) before taking the control
> flow change into account.
So JMP and RET can trivially have INT3 following in such a way that that
instruction is never in the actual execution path. This is obviously not
possible for CALL.
For CALL we can follow with LFENCE (hurts), or if we can get a limit
on how many instructions deep the speculation gap is, a bunch of NOPs.
Or possibly nothing at all.
As such it might make sense to have these two cases separated out.
Another utterly disguisting option is to align all CALL instructions on
8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then
have every function prologue round up the return address. This should
work with tail-call optimizations because the round-up is NOP when
repeated. The obvious down-side is that it will utterly wreck the RSB
For unaffected chips we could then NOP both the trailing INT3s and the
alignment prologue at runtime.
> Having some toolchain support to deal with
> this would be great, and preferable to some of the asm hackary currently
> under suggestion.
Agreed, hence the inclusion in this list.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Plumbers CF MCs
2021-03-23 19:53 ` Peter Zijlstra
@ 2021-03-23 22:12 ` Peter Zijlstra
2021-03-24 0:36 ` Steven Rostedt
2021-03-23 22:23 ` Andrew Cooper
2021-04-02 12:40 ` Segher Boessenkool
2 siblings, 1 reply; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-23 22:12 UTC (permalink / raw)
To: Andrew Cooper
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote:
> Another utterly disguisting option is to align all CALL instructions on
> 8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then
> have every function prologue round up the return address. This should
> work with tail-call optimizations because the round-up is NOP when
> repeated. The obvious down-side is that it will utterly wreck the RSB
Slightly less horrible: "CALL func; INT3" + "INC (%RSP); RET; INT3".
It still completely wrecks RSB, but isn't nearly as wasteful.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 22:12 ` Peter Zijlstra
@ 2021-03-24 0:36 ` Steven Rostedt
2021-03-24 8:15 ` Peter Zijlstra
0 siblings, 1 reply; 30+ messages in thread
From: Steven Rostedt @ 2021-03-24 0:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Cooper, Nick Desaulniers, linux-toolchains,
clang-built-linux, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On Tue, 23 Mar 2021 23:12:46 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote:
>
> > Another utterly disguisting option is to align all CALL instructions on
> > 8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then
> > have every function prologue round up the return address. This should
> > work with tail-call optimizations because the round-up is NOP when
> > repeated. The obvious down-side is that it will utterly wreck the RSB
>
> Slightly less horrible: "CALL func; INT3" + "INC (%RSP); RET; INT3".
> It still completely wrecks RSB, but isn't nearly as wasteful.
I'm confused. Why is speculation after a CALL dangerous? That code will
be executed on the return of the call anyway. That is, it's not
speculating something that wont execute in the future, whereas code
after RET and JMP wont be executed.
-- Steve
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-24 0:36 ` Steven Rostedt
@ 2021-03-24 8:15 ` Peter Zijlstra
0 siblings, 0 replies; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-24 8:15 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Cooper, Nick Desaulniers, linux-toolchains,
clang-built-linux, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On Tue, Mar 23, 2021 at 08:36:12PM -0400, Steven Rostedt wrote:
> On Tue, 23 Mar 2021 23:12:46 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote:
> >
> > > Another utterly disguisting option is to align all CALL instructions on
> > > 8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then
> > > have every function prologue round up the return address. This should
> > > work with tail-call optimizations because the round-up is NOP when
> > > repeated. The obvious down-side is that it will utterly wreck the RSB
> >
> > Slightly less horrible: "CALL func; INT3" + "INC (%RSP); RET; INT3".
> > It still completely wrecks RSB, but isn't nearly as wasteful.
>
> I'm confused. Why is speculation after a CALL dangerous? That code will
> be executed on the return of the call anyway. That is, it's not
> speculating something that wont execute in the future, whereas code
> after RET and JMP wont be executed.
Like I just wrote to Andrew; it mostly isn't going to be. But there will
be cases where running the code after, with the register contents from
before, will get you a nice speculation gadget.
The big problem is, like with Spectre-v1 compiler mitigations,
recognising when it is and isn't a problem. Mostly compilers tend to
take the safe option (understandably) and we end up with an incredible
amount of LFENCE instructions and performance will suck.
For SLS at least the CALL+LFENCE pattern is trivial enough to recognise
and we can patch it out at runtime, with the only side effect being
code bloat and I$ fail. That same isn't true for Spectre-v1 mitigations,
where LFENCEs are emitted at less obviously recognised places.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 19:53 ` Peter Zijlstra
2021-03-23 22:12 ` Peter Zijlstra
@ 2021-03-23 22:23 ` Andrew Cooper
2021-03-24 8:08 ` Peter Zijlstra
2021-04-02 12:40 ` Segher Boessenkool
2 siblings, 1 reply; 30+ messages in thread
From: Andrew Cooper @ 2021-03-23 22:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On 23/03/2021 19:53, Peter Zijlstra wrote:
> On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper wrote:
>> For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
>> function pointers, jump tables) and RET instructions may speculatively
>> execute the next sequential instruction(s) before taking the control
>> flow change into account.
> So JMP and RET can trivially have INT3 following in such a way that that
> instruction is never in the actual execution path. This is obviously not
> possible for CALL.
>
> For CALL we can follow with LFENCE (hurts), or if we can get a limit
> on how many instructions deep the speculation gap is, a bunch of NOPs.
> Or possibly nothing at all.
>
> As such it might make sense to have these two cases separated out.
Agreed.
There is architectural execution following an indirect CALL, so we will
only be speculating what we will execute non-speculatively later. I
can't see any situation where this would be speculatively dangerous.
For indirect JMP, whether you care about stopping speculation depends on
how likely it is that you'll enter case 0 of a switch statement. That
said, for profile optimised code, the chances are that the hotpath(s)
are in an if/else chain, so I don't think it is worth attempting to do
anything interesting here.
Both the Intel and AMD documents on the matter say to use LFENCE, but
that is a simplified set of instruction to cover all 3 cases. Given
that we probably want to split CALL away from JMP/RET, then INT3 is the
shortest speculation block at a single byte, and thus has least .text
size impact.
~Andrew
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 22:23 ` Andrew Cooper
@ 2021-03-24 8:08 ` Peter Zijlstra
2021-03-24 11:30 ` Andrew Cooper
0 siblings, 1 reply; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-24 8:08 UTC (permalink / raw)
To: Andrew Cooper
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On Tue, Mar 23, 2021 at 10:23:10PM +0000, Andrew Cooper wrote:
> There is architectural execution following an indirect CALL, so we will
> only be speculating what we will execute non-speculatively later. I
> can't see any situation where this would be speculatively dangerous.
Playing the devils advocate, suppose you have something like:
x = array[foo(bar)];
Then the speculative flow potentially does an array dereference with
values prior to foo() having executed.
Now, on x86_64 we have the (fortunate in this case) situation that the
return register isn't the arg1 register, so exploiting this is going to
be more work, but I can see it being done in some cases.
(And, that's only the easy half of the spec leak story ofcourse.)
Anyway, CALL + LFENCE should be trivial enough to recognise and generate
a sites list for. Then all we need is a CPU list that is affected. If
only we had a shorter non-exception speculation fence... :/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-24 8:08 ` Peter Zijlstra
@ 2021-03-24 11:30 ` Andrew Cooper
0 siblings, 0 replies; 30+ messages in thread
From: Andrew Cooper @ 2021-03-24 11:30 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon
On 24/03/2021 08:08, Peter Zijlstra wrote:
> On Tue, Mar 23, 2021 at 10:23:10PM +0000, Andrew Cooper wrote:
>
>> There is architectural execution following an indirect CALL, so we will
>> only be speculating what we will execute non-speculatively later. I
>> can't see any situation where this would be speculatively dangerous.
Sorry - I should have been more precise. "... on its own".
> Playing the devils advocate, suppose you have something like:
>
> x = array[foo(bar)];
>
> Then the speculative flow potentially does an array dereference with
> values prior to foo() having executed.
Playing devils advocate, the issue here isn't caused by straight-line
speculation, but by the array access.
Consider foo() being a plain call rather than a function pointer call,
and having:
if ( cond )
return bar; // or any junk really
at its head. This is a split half Spectre gadget - the conditional in
the callee, and the (single) array access in the caller.
i.e. you require an array_index_nospec()/etc to fix this issue even when
there is no straight line speculation.
> Now, on x86_64 we have the (fortunate in this case) situation that the
> return register isn't the arg1 register, so exploiting this is going to
> be more work, but I can see it being done in some cases.
>
> (And, that's only the easy half of the spec leak story ofcourse.)
Don't underestimate half spectre gadgets. With virt and hyperthreading,
it can be read directly out of the cache with L1TF.
Pulling it out of the load ports with MLPDS is in principle doable on
native and virt, but requires far more precise timing.
~Andrew
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 19:53 ` Peter Zijlstra
2021-03-23 22:12 ` Peter Zijlstra
2021-03-23 22:23 ` Andrew Cooper
@ 2021-04-02 12:40 ` Segher Boessenkool
2 siblings, 0 replies; 30+ messages in thread
From: Segher Boessenkool @ 2021-04-02 12:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Cooper, Nick Desaulniers, linux-toolchains,
clang-built-linux, Steven Rostedt, Jose E. Marchesi, Kees Cook,
Florian Weimer, Christian Brauner, nick.alcock, Josh Poimboeuf,
Will Deacon
On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper wrote:
> > For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
> > function pointers, jump tables) and RET instructions may speculatively
> > execute the next sequential instruction(s) before taking the control
> > flow change into account.
>
> So JMP and RET can trivially have INT3 following in such a way that that
> instruction is never in the actual execution path. This is obviously not
> possible for CALL.
What about
call ; jmp 0f ; int3 ; 0:
? Only the jmp can be speculatively executed (if your (u)arch executes
jumps at all), but that cannot be a problem, no data is involved.
> > Having some toolchain support to deal with
> > this would be great, and preferable to some of the asm hackary currently
> > under suggestion.
I fail to see how it is anything more than some boring backend-specific
patches? By nature you pretty much have to emit this as canned
instruction sequences, so all the rest of the compiler sees it is just a
call or jump or whathaveyou.
Segher
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 19:29 ` Andrew Cooper
2021-03-23 19:53 ` Peter Zijlstra
@ 2021-03-23 22:26 ` Nick Desaulniers
2021-03-24 7:52 ` Peter Zijlstra
1 sibling, 1 reply; 30+ messages in thread
From: Nick Desaulniers @ 2021-03-23 22:26 UTC (permalink / raw)
To: Andrew Cooper, Peter Zijlstra, Will Deacon
Cc: linux-toolchains, clang-built-linux, Steven Rostedt,
Jose E. Marchesi, Kees Cook, Florian Weimer, Christian Brauner,
nick.alcock, Segher Boessenkool, Josh Poimboeuf, Jian Cai,
Luis Lozano, Kristof Beyls
On Tue, Mar 23, 2021 at 12:29 PM Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>
> On 23/03/2021 08:35, Peter Zijlstra wrote:
> > There also is talk about straight line speculation mitigations. for x86
> > we should probably emit an INT3 after every JMP and RET. Although this
> > might not be controversial and be sorted by the time Plumbers happens.
>
> I guess this one is levied at me.
>
> Hopefully it isn't controversial in any way. I have just had sufficient
> tuits to get around to making an x86 straight line speculation feature
> request to the GCC and Clang communities yet.
>
> For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
> function pointers, jump tables) and RET instructions may speculatively
> execute the next sequential instruction(s) before taking the control
> flow change into account. Having some toolchain support to deal with
> this would be great, and preferable to some of the asm hackary currently
> under suggestion.
There is some prior art here, for ARM in -fharden-sls=*.
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
It's not clear from the kernel thread that the existing compiler
mitigations are amenable with live patching in/out mitigations for
hardware that is affected or not, respectively.
https://lore.kernel.org/lkml/20210305095256.GA22536@willie-the-truck/
Perhaps worth a discussion on the mailing list in
https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html ?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 22:26 ` Nick Desaulniers
@ 2021-03-24 7:52 ` Peter Zijlstra
0 siblings, 0 replies; 30+ messages in thread
From: Peter Zijlstra @ 2021-03-24 7:52 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Andrew Cooper, Will Deacon, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Jian Cai, Luis Lozano, Kristof Beyls
On Tue, Mar 23, 2021 at 03:26:29PM -0700, Nick Desaulniers wrote:
> On Tue, Mar 23, 2021 at 12:29 PM Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
> >
> > On 23/03/2021 08:35, Peter Zijlstra wrote:
> > > There also is talk about straight line speculation mitigations. for x86
> > > we should probably emit an INT3 after every JMP and RET. Although this
> > > might not be controversial and be sorted by the time Plumbers happens.
> >
> > I guess this one is levied at me.
> >
> > Hopefully it isn't controversial in any way. I have just had sufficient
> > tuits to get around to making an x86 straight line speculation feature
> > request to the GCC and Clang communities yet.
> >
> > For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
> > function pointers, jump tables) and RET instructions may speculatively
> > execute the next sequential instruction(s) before taking the control
> > flow change into account. Having some toolchain support to deal with
> > this would be great, and preferable to some of the asm hackary currently
> > under suggestion.
>
> There is some prior art here, for ARM in -fharden-sls=*.
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
Yes, I'm aware of that.
> It's not clear from the kernel thread that the existing compiler
> mitigations are amenable with live patching in/out mitigations for
> hardware that is affected or not, respectively.
> https://lore.kernel.org/lkml/20210305095256.GA22536@willie-the-truck/
ARM64 doesn't (yet) have objtool. Using objtool I could easily generate
a sites list to patch out things.
That said, the JMP,RET things don't need patching out (ARM's retbr
option) they're never on the execution path. It's the CALL thing (blr)
that would need runtime tinkering.
But I appreciate Will's stance; it would be very good to have a thread
analysis vs Spectre-v1.
> Perhaps worth a discussion on the mailing list in
> https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html ?
All of this is public by now, hence security@k.org isn't interested.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 8:35 ` Peter Zijlstra
2021-03-23 8:45 ` Peter Zijlstra
2021-03-23 19:29 ` Andrew Cooper
@ 2021-03-24 8:47 ` Christian Brauner
2021-03-30 14:13 ` Will Deacon
2021-04-02 12:33 ` Segher Boessenkool
4 siblings, 0 replies; 30+ messages in thread
From: Christian Brauner @ 2021-03-24 8:47 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, Will Deacon, andrew.cooper3
On Tue, Mar 23, 2021 at 09:35:10AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 01:23:03PM -0700, Nick Desaulniers wrote:
> > Hi all,
> > I saw plumbers opened call for microconferences:
> > https://www.linuxplumbersconf.org/blog/2021/index.php/2021/03/18/cfp-open-microconferences/
> >
> > I was going to put together a submission; do we want to do a combined
> > toolchain MC, or have distinct ones this year?
> >
> > I know in 2020 the GNU cauldron was co-located with Plumbers, as well
> > as a GNU Tools Track MC and LLVM MC.
>
> A combined MC focussed on kernel issues seems very interesting. We still
Seeing the discussion here unfold already in such great detail it might
be worth considering either really running a separate MC focussed on
Compilers & Kernel as Peter suggests or have a full Track (combined or
not) and taking out a day just for this topic.
Both cases would guarantee that you have a "full" day available for
discussing these issues. But maybe these things are so fundamental that
having a Compilers & Kernel Track might be worth thinking about
(presupposing we'll have time in the schedule to accomodate it in
addition to e.g. a GNU Tools Track. But I think we would.).
Christian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 8:35 ` Peter Zijlstra
` (2 preceding siblings ...)
2021-03-24 8:47 ` Christian Brauner
@ 2021-03-30 14:13 ` Will Deacon
2021-04-01 7:17 ` Kees Cook
2021-04-02 12:33 ` Segher Boessenkool
4 siblings, 1 reply; 30+ messages in thread
From: Will Deacon @ 2021-03-30 14:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Segher Boessenkool,
Josh Poimboeuf, andrew.cooper3
On Tue, Mar 23, 2021 at 09:35:10AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 01:23:03PM -0700, Nick Desaulniers wrote:
> > Hi all,
> > I saw plumbers opened call for microconferences:
> > https://www.linuxplumbersconf.org/blog/2021/index.php/2021/03/18/cfp-open-microconferences/
> >
> > I was going to put together a submission; do we want to do a combined
> > toolchain MC, or have distinct ones this year?
> >
> > I know in 2020 the GNU cauldron was co-located with Plumbers, as well
> > as a GNU Tools Track MC and LLVM MC.
>
> A combined MC focussed on kernel issues seems very interesting. We still
> have the control dependency (volatile-if?) thing pending. We had a bit
> of a discussion on that after last year, but I don't think anything
> really came of that, can we pick that up? Ideally a compiler person does
> an actual proposal for this year.
>
> If we can sort that, there's the rest of the dependencies Will outlined
> :-)
>
> Then there seemed to be people that thought __always_inline was a
> suggestion... I think we need to explore how that was ever possible.
>
> There's the endless UB debate... can we define more to reduce the UB? I
> mean, we're already bound by architecture ABI on the one hand, and
> actual use on the other. It would be so very nice to be able to get more
> -fwrapv and -fno-strict-aliasing knobs that define UBs away.
>
> There also is talk about straight line speculation mitigations. for x86
> we should probably emit an INT3 after every JMP and RET. Although this
> might not be controversial and be sorted by the time Plumbers happens.
>
> There was some talk about how compilers could help objtool make sense of
> jump tables.
>
> GCC's status on asm-goto with outputs?
>
> Clang's getting asm-constraints wrong ("rm" and it always picks "m").
>
>
> And I'm sure there was more..
One thing I'd like to add, and which I think is possibly relevant to the SLS
mitigation for arm64, is whether there is scope for allowing the compiler to
generate alternative instruction sequences (e.g. in a separate section),
which the kernel could then patch in during boot. We already do a tonne of
code patching on arm64 for things like CPU errata workarounds but also
for enabling support for optional architecture features, where the kernel
code would trap on CPUs without hardware support.
Another use of this would be to enable stack-taggging with MTE, where the
instrumentation is generated by the compiler but may use instructions which
are undefined if the CPU doesn't support MTE.
Will
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Plumbers CF MCs
2021-03-30 14:13 ` Will Deacon
@ 2021-04-01 7:17 ` Kees Cook
0 siblings, 0 replies; 30+ messages in thread
From: Kees Cook @ 2021-04-01 7:17 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Zijlstra, Nick Desaulniers, linux-toolchains,
clang-built-linux, Steven Rostedt, Jose E. Marchesi,
Florian Weimer, Christian Brauner, nick.alcock,
Segher Boessenkool, Josh Poimboeuf, andrew.cooper3
On Tue, Mar 30, 2021 at 03:13:12PM +0100, Will Deacon wrote:
> On Tue, Mar 23, 2021 at 09:35:10AM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 22, 2021 at 01:23:03PM -0700, Nick Desaulniers wrote:
> > > Hi all,
> > > I saw plumbers opened call for microconferences:
> > > https://www.linuxplumbersconf.org/blog/2021/index.php/2021/03/18/cfp-open-microconferences/
> > >
> > > I was going to put together a submission; do we want to do a combined
> > > toolchain MC, or have distinct ones this year?
> > >
> > > I know in 2020 the GNU cauldron was co-located with Plumbers, as well
> > > as a GNU Tools Track MC and LLVM MC.
> >
> > A combined MC focussed on kernel issues seems very interesting. We still
> > have the control dependency (volatile-if?) thing pending. We had a bit
> > of a discussion on that after last year, but I don't think anything
> > really came of that, can we pick that up? Ideally a compiler person does
> > an actual proposal for this year.
> >
> > If we can sort that, there's the rest of the dependencies Will outlined
> > :-)
> >
> > Then there seemed to be people that thought __always_inline was a
> > suggestion... I think we need to explore how that was ever possible.
> >
> > There's the endless UB debate... can we define more to reduce the UB? I
> > mean, we're already bound by architecture ABI on the one hand, and
> > actual use on the other. It would be so very nice to be able to get more
> > -fwrapv and -fno-strict-aliasing knobs that define UBs away.
> >
> > There also is talk about straight line speculation mitigations. for x86
> > we should probably emit an INT3 after every JMP and RET. Although this
> > might not be controversial and be sorted by the time Plumbers happens.
> >
> > There was some talk about how compilers could help objtool make sense of
> > jump tables.
> >
> > GCC's status on asm-goto with outputs?
> >
> > Clang's getting asm-constraints wrong ("rm" and it always picks "m").
> >
> >
> > And I'm sure there was more..
>
> One thing I'd like to add, and which I think is possibly relevant to the SLS
> mitigation for arm64, is whether there is scope for allowing the compiler to
> generate alternative instruction sequences (e.g. in a separate section),
> which the kernel could then patch in during boot. We already do a tonne of
> code patching on arm64 for things like CPU errata workarounds but also
> for enabling support for optional architecture features, where the kernel
> code would trap on CPUs without hardware support.
>
> Another use of this would be to enable stack-taggging with MTE, where the
> instrumentation is generated by the compiler but may use instructions which
> are undefined if the CPU doesn't support MTE.
Or swapping out SCS and stack-protector for PAC when the hardware
supports it...
--
Kees Cook
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Plumbers CF MCs
2021-03-23 8:35 ` Peter Zijlstra
` (3 preceding siblings ...)
2021-03-30 14:13 ` Will Deacon
@ 2021-04-02 12:33 ` Segher Boessenkool
4 siblings, 0 replies; 30+ messages in thread
From: Segher Boessenkool @ 2021-04-02 12:33 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nick Desaulniers, linux-toolchains, clang-built-linux,
Steven Rostedt, Jose E. Marchesi, Kees Cook, Florian Weimer,
Christian Brauner, nick.alcock, Josh Poimboeuf, Will Deacon,
andrew.cooper3
On Tue, Mar 23, 2021 at 09:35:10AM +0100, Peter Zijlstra wrote:
> GCC's status on asm-goto with outputs?
http://gcc.gnu.org/g:e3b3b59683c1 (and later patches fixing issues).
asm goto with outputs is a jump instruction for GCC, like any other asm
goto is.
Segher
^ permalink raw reply [flat|nested] 30+ messages in thread