Re: CPU errors
dvalin--- via linux-aus <[email protected]> Tue, 04 Feb 2025 02:30:15 +0000
| Newsgroups | gmane.linux.australia |
|---|---|
| Message-ID | <3399b47a-4068-44e9-bf41-f3a1254cd56d@localhost> |
On 04.02.25 11:12, Russell Coker via linux-aus wrote: > https://www.theregister.com/2021/06/04/google_chip_flaws/ > > I've been considering this issue of flaws in CPUs ever since it first was > reported 4 years ago. In 30 years developing embedded systems, using much less complex processors, I've only encountered one case of a risky CPU hardware bug - the v850 RISC processor. An engineer visiting from NEC head office asked me what risk there was in my use of the GNU toolchain, given that the v850's SLD and SST instructions could be corrupted by interrupts - i.e. did gcc issue them unprotected? To his considerable surprise, a quick search revealed http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01554.html in which Nick Clifton said: > Hi Guys, > NEC have discovered a hardware bug on the v850 series of processors > which means that under some conditions the SLD and SST instructions > will behave badly. They have asked me to update the GCC sources so > that these instructions are no longer generated by default, but can > still be emitted if the "-mep" command line switch is used. ... It would surprise me if the answer could have been found almost instantly, if proprietary tools had been employed. In general, security is put at risk by most forms of unnecessary complexity, not just bloated CPUs. It is my contention that IoT stands for "Introduction of Threats", as letting the internet into an embedded systems network, even domestic, is just plain nuts, if it can be avoided. I preferentially run 8-bitters there, with unalterable ROM-resident code, no bootloader for remote SW updates, and no general purpose comms protocol - only the data queries and commands needed. Then I set the chip lock fuse, so the code can't even be read with physical access and a chip programmer. That we can't readily control all risk has to be admitted. I no longer have responsibility, first or secondhand, for a corporate development network, but the controller on my off-grid solar installation runs a Linux distro - VenusOS. And it phones home, so lacks the total security of a network gap, that off-grid otherwise could offer. Life is the art of the possible, I figure. Erik P.S. The substantial EV-charging off-grid solar installation can be seen in an article on p74 of the current issue of Renew magazine, published by the ATA. (Though +1.5°C GW in 2023, and +1.6°C in 2024, may be a transient on the trend, +2°C is exponentially closer than generally acknowledged, I suspect, so please forgive a little prodding in the direction of building personal climate resilience. Total reliance on an above-ground wired network will become increasingly uncomfortable, I submit.) _______________________________________________ linux-aus mailing list [email protected] https://lists.linux.org.au/mailman/listinfo/linux-aus To unsubscribe from this list, send a blank email to linux-aus-unsubscribe-cunTk1MwBs8iFSDQTTA3OBCuuivNXqWP@public.gmane.org