The relevance to plan 9: we have this thing we've used for about 30y now, known to many of us as sdE0/nvram.
IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea being you had some bit of NVRAM on your system, hard to get to, which was a good place to stash a key. X86 has always had the battery-backed CMOS memory, and it's always been too small to hold anything useful, certainly not big enough for NVRAM, so I always assumed that is why we ended up with sdE0/nvram. [Although, note, on the LANL supercomputers, we did use a few bytes of CMOS to remember a node's location on the source-routed Myrinet: not totally useless :-)] Creating a 512B partition on persistent storage to hold a secret key is, I guess, what you do when you are on systems without a decent place to put it. It never struck me as safe. I figure that at some point somebody is going to come in and show us a better way to do it. Should that happen, it's good to be aware of just how real the threats are. So I thought it would be nice to know, and possibly interesting as well. On Fri, Mar 28, 2025 at 8:06 AM <tlaro...@kergis.com> wrote: > On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: > > search for: keysight rp2350 hardware attacks > > > > (I'm done including links :-) > > > > Short form: it's getting easier by the day to put together glitching > > hardware, for under $1000, and uncover those keys! > > [From the PR departement] This demonstrates once more: > - That security relies first on simplicity (despite the > conclusion, there is a mention about software too, i.e. compilers: > "Due to an unlucky arrangement of instructions emitted by the > compiler, injecting a fault which skips one out of two very specific > instructions confuses the chip into rebooting to the hazardous boot > type".); > - That security has a cost and to maintain efficiency, > strong security has to be done only once, and that it would > be more secure for a task, verified, to execute once on a dedicated > core than having to verify it at each running slot of time, having > verified too that it had not been altered while sleeping and that the > context on the core or the caches have not been "polluted" by a > concurrent task. > > On the obvious side---it will probably not be a scoop to a lot of > people---, I discovered, while working on the driver for the > RTL 8125 and al. NICs, that there are instructions to allow > to turn off the blinking led showing that there are network exchanges... > > All in all, trusting something that one doesn't build entirely (from > hardware to software)---it may exhibit then errors but from involuntary > faults---is, at best, naivety. > -- > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M023cc872fbda4674c9b7178f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
