Re: YASV (Yet Another Security Vulnearability)

On Fri, 26 Jul 2024 20:27:04 +0000, EricP wrote:

Anton Ertl wrote:

EricP <ThatWouldBeTelling@thevillage.com> writes:

One thing they mention is Intel and AMD incorporating privilege level
tagging into the BTB, as I suggested when this all started.
Combine that with purging the user mode entries from the predictor
tables
on thread switch and I would think that would shut this all down.

>
1) The attacker can still attack the context (even if the notion of
   context includes the privilege level) from within itself.  E.g.,
   the kernel can be attacked by training the kernel-level branch
   prediction by performing appropriate system calls, and then
   performing a system call that reveals data through a
   mis-speculation side channel.  IIRC such Spectre attacks have
   already been demonstrated years ago.

>
I hadn't thought of this but yes, if JavaScript can contain remotely
exploitable gadgets then syscall might too. And its not just syscall
args
but any values that enter the kernel from outside that are used as
indexes
after bounds checking. So the image file mapper, network packets, etc.
>
But if I recall correctly the fix for JavaScript was something like
a judiciously placed FENCE instruction to block speculation.
And for the kernel this attack surface should be quite small as all of
these values are already validated.
>
So wouldn't it just be a matter of replacing certain kernel value
validation IF statements with IF_NO_SPECULATE?
>

2) Users are supposedly not prepared to pay the cost of invisible
   speculation (-5-20%, depending on which paper you read) , are they
   prepared to pay the cost of purging the user-mode entries of branch
   predictors on thread switches?

>
Its actually thread switches that also switch the process because if the
new thread is in the same process then there is no security domain
switch.
Plus that peer thread could likely make use of the old user mode
predictions.
>
I have difficulty believing that the branch predictor values from some
thread in one process would be anything but a *negative* impact on a
random different thread in a different process.

47 threads in one process all crunching on one great big array/matrix.
This will show almost complete positive impact on sharing the BP.

                                                 Because if you retain
the predictor values then the new thread has to unlearn what it learned,
before it starts to learn values for the new thread. Whereas if the
predictor is flushed it can immediately learn its own values.

The BP only has 4-states as 2-bits, anything you initialize its state
to will take nearly as long to seed as a completely random table one
inherits from the previous process. {{BTBs are different}}

>

   My guess is that the stuff plays out as usual: The hardware
   manufacturers don't want to implement a proper fix like invisible
   speculation, and they suggest software mitigations like purging
   user-mode entries on thread switch.  The software people then
   usually consider the mitigation too expensive in performance or in
   development effort, so only a miniscule amount of software contains
   Spectre mitigations.
>
- anton