andreiw

Dumb question, but how would it fare on a ppc64le box like the (OpenPower) Power9 Talos II? https://www.raptorcs.com/TALOSII/prerelease.php

On a related note, another interesting CPU design - http://multiclet.com/index.php/en/support/general-technical-...

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...

Maybe. I'll look.

There's a few problems there, but these amount to UEFI being a terrible, abominable spec.

The specification doesn't say that an implementation must not change the memory map inside ExitBootServices, and in practice many runtime drivers clean up or even perform RT Data allocations in that path. This results in the "MapKey is incorrect" error returned to the caller. (I've seen some that modify ACPI and SMBIOS on the fly inside the ExitBootServices path, awful, awful, awful).

So yes, the program calling ExitBootServices must be written to retry the call even if it really did avoid sandwiching any calls to UEFI between the last GetMemoryMap and ExitBootServices.

The other big Achille's heel of UEFI in general is the SetVirtualAddressMap() RT call and RT Services support in general, but Tiano's driver model makes it particularly easy to shoot yourself in the face and end up with an implementation that forces the OS to call RT services with identity mappings or even with mappings for supposedly non-RT regions. Ugh. MMIO is a favorite one to "forget" to add to the memory map as an RT entry.

UEFI uses the PE format for binaries, but doesn't actually mandate how PE should be used or what the allowed relocations are. You could build a PE binary that amounted to, say, tons of executable segments, each of which will be a separate memory map entry. Now since UEFI doesn't mandate exactly how an OS will assign virtual addresses (for SetVirtualAddressMap), nor exposes relative grouping of memory descriptors (forcing the OS to relocate these keeping relative distances) I can imagine a situation where RT drivers could break if the OS decided to aggressively compact the address map or instead introduce random large VA gaps between RT memory map entries.

Author here, feel free to AMA.

If you run the “mmap” command in UEFI shell, and count the memory regions marked as Runtime Code and Runtime Data, that will give you the total resident (after booting OS) memory footprint.

Note that these numbers will also include Arm Trusted Firmware and firmware tables.

Yep, and being able to claim that U-boot can boot Windows (on x64 or Arm) would be a really strong statement around completeness. I hope someone gets to work on it soon (Alexander Graf ;-)?).

RaspberriPiPkg can’t boot Raspbian today, since the latter is 32-bit. Can boot stock 64-bit SUSE and Ubuntu, though.

A lot of it really is code quality issues, both in the core and some of the contributed I/O drivers.

Author here.

If you wanted to run you own drivers, or had code written specifically against protocols exported by Tiano components I believe the answer is - yes.

RaspberryPiPkg is the $35 64-bit Arm UEFI devkit.

Of couse the U-boot implementation of UEFI spec is getting better and better day by day, and that’s obviously awesome. I am sure someone will add ACPI support to it any day now. Having choice is good, and I wouldn’t want to live in a world with a single implementation. That said, Tiano (like it or not) /is/ the reference implementation, and you’re much less likely to run into surprises (today). Notice how I didn’t say Tiano is /better/, because in a number of ways (code quality, complexity, fragmentation) it’s pretty awful.

One thing the U-boot implementation excels at is embedded Arm board support - U-boot is the defacto firmware for most embedded hardware, and now all of that hardware is EFI-capable. Porting Tiano is effort you don’t want to spend.

That said, there are hybrid approaches - EFIDroid (efidroid.org) runs Tiano on top of LK, using LK’s platform support for drivers.

Actually, good question to flip back to you.

As a random person stumbling upon this, what value would you assign to it? What could you imagine the end goal to be?

Arm derived: 32-bit Cortex-A and a Cortex-M for radio. Curious what the security arch is...

I think the bigger news here is the custom MCU design. What is it? Is it Arm-derived, and if not - why? Anyone pay attention lately to MSFT’s activity on LKML?

No concrete goal beyond having a reasonably useful UEFI development environment (more so than the 96boards one).

It’s been useful to be able to run the same Ubuntu and SUSE images as VMs and servers do, but that’s only really possible because the built kernels have RPi3 support (but at least you now don’t need a custom image with U-Boot).

I dunno dude. I just pointed out the obvious, and all I get is a passive-aggressive minusing. Most people won’t care enough to even give you “a rant”, they’ll just move on.

If you don’t want feedback, don’t ask for feedback by posting publicly. My “rant” is a collection of issues I’ve seen for at least the last 7 years of actively paying attention to the project.

Not to invalidate all of your arguments, but it does “just install” in a VM without needing technical experience.

To reach any mass of users (outside of turnkey solutions where the end users may not know or care), you need commercial support and the later needs concrete identified market segments. To parallel Wine - ROS needs its own CrossOver (but not Cedega).

Firefox 48 worked, but the autoupdate crashed.

If you install 7Zip, you should know that 7Zip does not associate itself with file extensions by default. This is 7zip behavior. You need to run 7zip, go to options, and set associations by clicking on the '+' button.

AMD PCnet-PCI II as the NIC works fine for me (VBox 5.2.4 r119785 (Qt5.6.3) on the Mac, if that helps)