On 2/22/2023 4:11 AM, Skybuck Flying wrote:
> AWESOME TOOL FROM GIBSON RESEARCH:
>
> https://www.grc.com/inspectre.htm
>
> PLEASE TEST AND REPORT BACK.
>
> BYE,
> SKYBUCK.
>

It's pretty easy to lose track of these. Does Gibson Research
have the time to test for all of these ?

https://en.wikipedia.org/wiki/Spectre_%28security_vulnerability%29

The topic is a busy one.

https://www.phoronix.com/review/amd-zen4-spectrev2

With AMD, their arch is consistent from end to end.
A $100 desktop processor has the same address bus
width as a $7000 Milan multi-socket processor setup.
Then tend to do only one die version, and via chiplets,
use it over and over again.

Sure, laptop processors are custom and monolithic, but
the core is just copy/paste of some other core they've
already done.

Intel, on the other hand, can afford to have more than
one core arch on the go at the same time. The chip with
the 500 errata against it, that is likely to have a "fresh"
core design. The errata in that case, are probably not
against the CPU core, but more to do with some of the
custom accelerators or the like. If you've ever done
silicon design, testing all the corners and pathological
conditions is exhausting, and it takes months to do the
simplest of things. And this is where errata come from,
if the boss hurries you too much. A testing program,
can be as much as two years behind production (people
are buying your gadget, while some dude is still testing
the correctness of the thing!).

It is the server customers who are the most picky about
these mitigations. Consumers benefit, just from the
server business existing. If there was no server business,
quality would slide downwards.

If one CPU brand has two uncorrected exploits and the
other CPU brand has one uncorrected exploit, the customers
can switch camp, based on that. There is a lot of pressure
to do those correctly. If an exploit shows up late in the
design process, it might have to be fixed with a microcode
patch (both OSes load these now, I don't think the patches
are optional any more).

*******

The average processor has around 100 errata. Some have
a status of "Will Not Fix", which means the errata is
not considered "customer affecting". Other errata can
be fixed in a silicon die revision (A,B,C). A die revision
is not necessarily an "all layers" revision -- you can fix
some processor problems with first-level-metal patching
and the spare gates and flops up top. One of the chips
I was working with at work, some of its patching was done
that way.

At a certain point in production, they switch die revisions,
and then some of the errata are "fixed". The die revision is
reflected in the long part number stamped on the box.

But other issues, may never be fixed. Like, the floating point noise issue
on the die, that was never fixed, because the feeling was,
high level compilers don't produce an FP-dense output stream
so why worry.

When it comes to branch prediction, speculative execution,
the presence of multiple cores, these are things that cannot
be removed. The mitigations that use "fences" or "timing fuzz"
tricks, they still need compiler support, so not every software
project a user carries out, is properly protected. I expect
where these matter most, is in authentication code (handling
your password) or crypto code (handling a key).

Paul

On Wednesday, February 22, 2023 at 7:03:26 AM UTC-8, Paul wrote:
> On 2/22/2023 4:11 AM, Skybuck Flying wrote:
> > AWESOME TOOL FROM GIBSON RESEARCH:
> >
> > https://www.grc.com/inspectre.htm
> >
> > PLEASE TEST AND REPORT BACK.
>
> When it comes to branch prediction, speculative execution,
> the presence of multiple cores, these are things that cannot
> be removed. The mitigations that use "fences" or "timing fuzz"
> tricks, they still need compiler support, so not every software
> project a user carries out, is properly protected. I expect
> where these matter most, is in authentication code (handling
> your password) or crypto code (handling a key).
>
> Paul

It's like anything that has multiple teams of people working on it, and it's nearly impossible for one person to fully
understand and comprehend it all. There will be bugs, and their will be exploits. And there will never be a 100% secure
system that is allowed on the public internet.

So now it comes down to stamping out the bugs you do know about, running some tests to find these bugs (which will never
get everything with all of the future use cases out there that could potentially uncover a new exploit or bug), and accepting the
fact that there is no locking down the world 100%, and there will always be risks no matter what.

There is a 100% chance of someone dying in their lifetime. Do people really want to waste their limited time by being shit paranoid
about every little thing?