But that's not really flashing under Linux is it? That just sticking the file somewhere their non-linux flash tool can see. Not saying that it's not helpful to be able to do so, it does remove Windows from the equation (did it myself just last night as it happens).

The UEFI approach also isn't "flashing under Linux". It's "Stash a UEFI capsule somewhere into RAM, suspend, have UEFI update itself on wake-up before returning control to the OS"

Now, having the firmware run a seldomly used code path on resume sounds scary to me: That _must_ be accompanied with some OS-level check (eg hashing) that the firmware didn't touch any memory that it didn't originally reserve.

Luckily Windows is doing that, so Linux can ride the coattail again (as is usual with Intel-originated firmware standards) - except if Windows is guaranteeing some unused memory, because then, some UEFI implementation exploit that, inadvertently breaking things on Linux (yet again).

> But that's not really flashing under Linux is it?

Indeed not. But if we are going to nitpick, my first question would be what value does being able to flash new firmware from inside Linux achieve compared to what we have today: a OS-agnostic bootable update-medium?

Less steps. No manual process.

But now we can have malware hijacking our firmware, seamlessly through standard kernel APIs.

Is this really an improvement? Is it worth it?

You would require root on the machine, and if you have root anyway...

Anyway you can already flash the firmware, just without a standard interface: either with the uefi copy thing, or with a proprietary tool.

That's not the same thing.