> Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.
To get 192-bit security with RSA you'd need 7680-bit RSA key and with ECC you need 384-bit key as mentioned in the article. That assumes classical attacks only. For quantum attacks, the smaller key sizes used with ECC do make it weaker.
What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.
FWIW, nothing stops Librem 5 users from just throwing away all that nonsense code they wrote to load the firmware from a dedicated flash, and just flash standard U-Boot (which already includes a mechanism to embed the blob, which is the normal way to do it), at which point you can of course modify it or replace it.
Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).
> storing the firmware in a way that prevents the user from updating it via software
Nothing prevents the firmware being updated by the user on the Librem 5. The default kernel marks the SPI flash as read-only (mostly to prevent accidental soft-brick situations), but you can simply lift it up, or reflash it from the bootloader where there's no such restriction applied.
The firmware update is not intended to be done by the user - PureOS does not ever ask you to do that and it does not even provide the blobs in its repos; but if you want to update it for some reason, you're not prevented from doing so. You could always reflash the SPI flash with a hardware flasher (or even completely replace it) anyway, so it would be pointless to artificially prevent a motivated user from doing so in software. After all, they may be trying to use a free replacement that may show up in the future.
> That's why so few of them tend to advertise transmit capabilities.
Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.
This polling is not done by the CPU, this is a common misconception. In a typical modern system the only polling that happens with USB is done by the USB host controller and only when there is actual data the host controller generates interrupts for the CPU to process it. Obviously, when you configure the mouse at higher frequency you will get more interrupts and hence higher CPU usage but that has nothing to do with the polling.
This has nothing to do with "weakening of ECC". Dual_EC_DRBG is an RNG that happens to use Elliptic Curves but its problems have nothing to do with that, they have to do with the design of the RNG itself. And those problems don't say anything about the strength of ECC used for encryption and digital signatures.
The 802.11 header has 4 MAC addresses: Source Address (SA), Destination Address (DA), Transmitter Address (TA), Receiver Address (RA). The TA and RA are those of the Wifi station and SA and DA are the Ethernet addresses. This allows bridging Ethernet and Wifi interfaces and it is how many (most?) Linux-based Wifi routers work.
Yes, if you're using WDS, otherwise you only have three addresses used. Since you need the transmitting device to populate the DA, you can't just turn on bridging on a client and have everything work - you need both ends of the link to be involved.
Yes, for a wifi client (like in the article) you're right. manuel_w was talking about bridging on the AP and for that you do just enable bridging and it works fine.
> Until spoofing, amplification attacks on UDP are properly tackled
This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.
> if your users are untrusted and not under your direct administrative control (e.g. students in a dorm, hotel guests, et c) then default-allow-everything jeopardizes your upstream transit connection (e.g. if they start spamming).
How is that different from an ISP? Or do you think ISPs should also block everything except TCP ports 80 and 443?
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.