andreiw

Also 64-bit Arm...

Yeah I’d say that modern OoO Arm implementations (A57, A72, ...) are worth trying to speculate into trapped VFP state. Lazy FPU is definitly a thing everywhere.

My hunch says that chips affected by 4a could easily be fair game (4a is speculating reads into priviledged regs... I wonder if 4a would work on regs that are trapped, not inconceivable)

Not numerating it? Variant 6 is as good as anything...

Do we have PoC code? Has anyone tried attacking FP/SIMD state on other ISAs like Power or AArch64?

What are we calling this Spectre variant?

As usual, Carl Icahn...

Then tell your SiP to do better.

On Arm the conditional speculation barrier couldn’t be more lightweight (CSDB).

“break”? no, but spectre is a confidentiality attack, and not even the only confidentiality attack that can be done...

yes you could, but the noise floor won’t be great

Depends on how you define hardware and software. There are global workarounds that amount to crippling CPU behavior, to provide guarantees for code not written to be spectre safe. I guess that’s what you mean by “hardware”. But “software” approaches are localized mitigations to code written to avoid spectre attacks - and these localized mitigations use arch specific sequences to do so.

Considering the hardware mitigations aren’t some magic bullet, but are a “big hammer” that cripples CPU OoO behavior in crrtain ways for everything, software mitigations don’t seem that unreasonable. Of course, “software mitigations” use CPU facilities as well, and can allow for making critical sections safe. In practice, it is well understood what code needs to be written in a spectre-safe way. The difficult question isnhow to write code to anticipate the next 10 varieties of speculation attacks...

Anyone else use the hex “assembler” on the TI-83+? After a while you just memorize the hex opcodes for z80 insns...

TI-GCC for my TI-89 was nice...a few years back I tried to dust-off my IMSA-issued 89, and...it didn’t turn on. Sad. Replaced all batteries. Nothing... Then the flex connector on my 83+ started flaking out (the LCD corruption issue plaguing these...).

Not yet... the good news is that iPXE supports the SMSC USB NIC on the Pi. I don't know if iPXE will work out of the box, but I certainly intend on porting the iPXE NIC driver as a standalone (and GPL-licensed, of course) SNP implementation so you can use it with UEFI's own PXE implementation or anything else (like, shudder, it's shitty network tools...).

The biggest possible barrier to that today, which is still unknown, is the quality of the USB host controller. NICs use bulk, but there's no guarantee that the host controller driver is good enough. Time will tell, I suppose...