[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