Re: [PATCH v2 1/4] powerpc/64: Add INTERRUPT_SANITIZE_REGISTERS Kconfig

["Nicholas Piggin" <npiggin@gmail.com>]

On Tue Nov 8, 2022 at 2:39 AM AEST, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 07, 2022 at 02:31:59PM +1100, Rohan McLure wrote:
> > Add Kconfig option for enabling clearing of registers on arrival in an
> > interrupt handler. This reduces the speculation influence of registers
> > on kernel internals.
>
> Assuming you are talking about existing PowerPC CPUs from the last 30
> years:
>
> There is no data speculation.  At all.  Ever.
>
> There is branch prediction, but that is not influenced by register
> contents, either (for any current CPUs at least).  (Except when you get
> a flush because of a mispredict, but if this zeroing changes anything,
> we will have used wild (but user controlled) values in the old
> non-zeroing situation, and that is a much bigger problem itself already,
> also for security!  This can be an unlikely kernel bug, or a very
> unlikely compiler bug.)

This is not about data speculation, it is about speculative execution
in kernel mode that uses architected value that were set by user, and
that value being used to influence a speculative gadget that can expose
data to user via a side channel.

> All GPRs are renamed, always.  If you zero all GPRs on interrupt entry
> (which is context synchronising, importantly), this will guarantee there
> can be no timing influence from the GPRs, because all of the physical
> registers depend on nothing that happened before. So that is good, at
> least it can give some peace of mind.  Except that this makes 30 new
> registers in just a few cycles, which *itself* can cause stalls, if the
> renaming things are still busy.

It will have some pipeline effect like any instruction I suppose. At
least in latest processors, zeroing idiom should release registers
AFAIK.

> Context synchronising does not
> necessarily help there, the renaming machinery can do stuff *after* an
> insn completes.

Possibly context synchronization does not push everything prior to
completion, certainly it does not drain prior stores from store queues
even if they had previously completed, so there can be things going on
there. Software does not really have the ability to do anything about
that though, so that's more of a hardware problem if that exposes a
security issue IMO. Or at least a separate issue if there is some
architecture that could deal with it.

Thanks,
Nick