zerohp

CPU designers have been aware of this attack vector for a while, so many (maybe all) have controls to lock these registers. They are written and locked by vendor firmware before it hands off to the operating system.

You would have first break the firmware or locks before an attack like this on a modern CPU

Questionable behavior from YC companies is nothing new.

Apple Card already offers credit limits high enough for it

That’s exactly what this is.

9 months to production is completely impossible anyway.

9 months from design to early samples is probably impossible given than TSMC takes 3 months after tape out to produce them. Then it’s up to the customer to qualify and revise for production. TSMC doesn’t do that.

There’s no AI that makes this happen in 9 months.

The Buddha lived before writing in India. We have plenty of other stories that were passed by oral tradition before they were written down.

The time from tapeout to first samples is 3-4 months even for the biggest customers of TSMC.

Shorter for a metal only change.

In the chip design world, 2:1 for design verification to design is on the low end of normal.

Some organizations have gone as low as 1:1 but that is considered an emergency that must be fixed. It’s so important that designers will be intentionally underworked if there are not enough validation engineers on staff.

When you can’t fix bugs in the field, quality is important.

The joke is that AI companies pretend to care about doing legal things.

* * *

My solution is that I no longer contribute to the public internet in any meaningful way. No more open source projects. No more contributions to free software. Bug reports only when it helps me. The hacker ethos is dead. Selfishness and greed won.

Silicon Valley builds empires off the back of free intellectual labor. I'm done with all of it. If they want something from me they can (and do) pay for it.

Methodology doesn't support the conclusion.

Try using images that it wasn't trained on.

I don't know of any CPU that speculates both sides of a branch. I work on a CPU design team.

Modern CPUs speculate hundreds of instructions ahead, and with just a dozen branches you can have a few thousand different paths. It makes more sense to speculate down one path with very high accuracy.

Software table walk performance is bad on modern out of order processors because it has to finish every older instruction in flight and redirect the front end to the exception vector. This can take several hundred cycles. Hardware table walk can take <20 cycles to hit in the next level cache.

In AArch64, `BR LR` and `RET` do not perform the same logic when FEAT_BTI (Branch Target Identification) is present.