[Linux-aus] CPU errors
dvalin at internode.on.net
dvalin at internode.on.net
Tue Feb 4 13:30:15 AEDT 2025
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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20250204/501e5f36/attachment.htm>
More information about the linux-aus
mailing list