Liste des Groupes | Revenir à c arch |
MitchAlsup1 wrote:Could be independent processes crunching on mmap() memory.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.
And, as I said above, if the threads are in the same
process/address-space
then the BP should be preserved across that switch. But not if there
were
other intervening processes on the same core.
BTBs are supposed to get rid of much of the non-sequential Fetch delay.>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}}
Admittedly I am going on intuition here but it is based on the
assumption
that a mispredicted taken branch that initiates a non-sequential fetch
is costlier than a mispredicted untaken branch that continues
sequentially.
In other words, assuming that resetting *ALL* branch predictors toI think you mean weakly untaken: not just untaken.
untaken,
not just conditional branches but indirect branches and CALL/RET too,Certainly CALL/RET as we are now in a completely different context.
and fetching sequentially is always cheaper than fetching off in randomSame motivation for My 66000 Predication scheme--do not disrupt the
directions at random points. Because fetching sequentially uses
resources
of I-TLB, I$L1 and prefetch buffer that are already loaded,
whereas non-sequential mispredictions will initiate unnecessary loadsI am sitting around wondering if ASID might be used to avoid resetting
of essentially random information.
It also depends on how quickly in the pipeline the mispredict can be
detected, some can be detected at Decode and others not until execute,
and how quickly unnecessary pending loads can be canceled and the
correct flow reestablished.
Les messages affichés proviennent d'usenet.