Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)

But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)

Microchip XC compiler has support for those. They recently dropped the licensing requirement, so while it's not FOSS, it's freeware now, without limits.

you can also recompile xc gcc sources with some the paid features baked on, if you're so inclined and use mplabx pretty heavily

not for PIC

I don't like attestation. That is dangerous to user freedom. I don't mind other parts of this technology.

Attestation already destroyed user freedom in mobile app ecosystem. You can't just implement your version of some mobile banking app or whatever just by using original app's API, because dark overlords of gated app comunities allowed app authors to prevent this on OS level by giving them attestation tools.

That's actually a good use case for HW keys. Since untrusted computers are much more likely to have keyloggers/malware, etc. So you don't need to reset password and invalidate all sessions after each such login on an untrusted computer.

I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.

I'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse.

You can achieve 50MiB/s if that's all that you're doing. I've worked with some DSPs (TI's DaVinci line) where some operations would abort if DDR was overwhelmed.

For example, passing a frame of video (YUV) into the peripheral which can resize the overall image, would fail if the system was busy with other DMA transfers. You could attempt to resize again, but there were no guarantee that it would complete successfully. Your options are to reduce overall DDR utilization or drop frames. In an application like Flock's, dropping frames is likely something they need to avoid.

The system in question is doing similar tasks, and I don't think that what I'm suggesting is out of the question.

They can choose the SoC that would be able to fill the requirements. Eg. almost all Rockchip SoCs have NoC with configurable QoS on master ports (even the cheapest IP camera targetted SoCs that cost like 2-3$), or some other interconnect mechanism that can make it so that SDRAM controller gets tasks in some user selected priority order (eg. you deprioritize CPU in favor of camera interface and other things). This is not a new tech. It already existed when Flock was founded.

And in any case. Passing compressed video streams or pictures through HW encryption engine will not saturate 1.5+ GiB/s or whatever even the lousiest 16-bit DDR3 at 400MHz would give you, not even close. It would be like a fraction of a percent of total bandwidth.

That's why I was asking if it was an older model initially.

I'm glad it died in GNOME, though. That's where it matters.

Who cares if german company wants to use this mess for their weapons.

Sadly, people will happily go with this crypto-lockdown until there's no personal computing whatsoever. Only way to fight is not to play, or hack this in some way.

they can fetch the key or its hash from DNS. it's not like the current system is that much more involved. current system is basically a third party signed cache of such ownership claims validated based on ability of someone to modify DNS records.

All caches are just functionally useless layers..., so that's that.

How do I know that the DNS record is owned by the entity they are claiming to be? CAs have nothing to do with caching.

You don't know that even with DNS validated certificates. There's no separate "entity" claim other than "anybody with DNS record modification rights for a given domain".

You can give out the same claim over DNS directly without any extra third party involvement in the form of CA.

Huh, wow. I kind of thought the whole point of CAs was to do identity verification. It they have dropped that entirely, what is the point?

DNS can be trivially MITM'd as well, it's certainly not a secure mechanism for distributing keys.

You just taken down the whole business of dns validated CA issued certificates. Go claim your bounty. :)