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