Port forwarding from RPi to Windows machine

Well, verifying gcc sources could be included in the above - 'between kernel and web browser'. At least if you are installing compilers

The point of Ken Thomson's attack is that you have to compile those gcc sources and that compiler can poison the binary you produce from the clean gcc sources. So inspecting sources doesn't help you.

Obviously one must write one's own compiler!

A mere snap for any greybeard unix sysadmin...

So what do you compile it with ? If the compiler you use to compile your clean room compiler is poisoned then so will be the compiled compiler despite your clean room code. That's the Thompson trap.

The only way out of the Thompson trap is to write a new compiler from scratch in assembler and assemble it by hand. Then you just have to trust the hardware.

You don't. You already wrote your own assembler. In machine code!

You compile the proto-compiler with THAT.

THEN you can use it to compile future versions of itself.

An assemblers is - or ought to be - a 1:1 translator from human readable to machine readable commands.

It cant be corrupted.

Unless the chip itself is compromisesd :-)

So design your own chip!

That is what happened with the early days of ARM chips. I know people involved in writing those compilers..

If the compiler you use to compile

Or design it yourself.

The ARM is a special CPU that was designed initially to beat the 6502 and walk all over z80s and 8080s.

Because they couldn't afford massive wafers, it was strictly limited in hardware. All they could do was a very basic instruction set and a lot of on-chip registers. And a three instruction set pipeline and clock it as fast as it would go. And a 32 bit address bus. To take advantage of a lot more RAM that was getting cheaper by the day. The low power was simply a cost saving measure - a plastic cased low dissipation chip was

And a few - maybe only one - very bright boys (sophie wilson) , looked at the absolute minimum of what those instructions had to do.

Complex instructions could be written to use those registers and accessing them was super fast.

In a way it mimicked what was happening in CISC but pulled the microcode out of the chip into external software libraries.

And there it was. The Acorn Risc Machine. Not a very much used chip until mobile computing came along, when its low power performance and ability to be integrated under license into anyone else's hardware chips made it a world beater.

Ah, oh, didn't know that.

It was a classic eye-opening paper, it is extremely hard to get a system that is certain not to contain any hidden surprises - you have have to write your own assembler in machine code, compiler in assembler and build your own hardware, from scratch.

Do you trust the chip layout software not to embed a backdoor or something ? What do you run that chip layout software on and why do you trust that system. You'd best start from MSI TTL/CMOS logic and build your own system to run the chip design software (that you write or at least audit) to design the chips.

I know - I was in Cambridge and in the business when it was being done. I knew about the ARM before it was released, they were pretty good at keeping it out of the rumour mill but nothing is completely secret in Cambridge. Earliest rumours had Andy Hopper involved.

The modern ARMv8 architecture bears little resemblance to the original ARM used in the Archimedes, it has become massively complex. Even so for the time the performance of the original ARM was stunning, matched only by the Transputer which was weird and expensive. Once thought to be the future of computing the Transputer is all but forgotten, while ARMv8 has become the dominant 64 bit architecture (measured in numbers of CPUs manufactured).

I think that its pretty difficult to encode an invisible backdoor in the silicon and not have it spotted at some fairly early stage.

So many of these 'threat narratives' are, when examined closely, implausible to the point of downright impossibility.

You can examine the machine code that your compiler and linker assembles. And people do. I certainly have done. If it doesn't match what you asked for in the high level language, there are questions to be answered.

And of course the lower level the language the easier it is to check. One reason why I don't like C++ and friends.

And likewise, if the silicon is updating bits of memory you didn't ask it to, or doing stuff that you dont recognise as valid...

lets face it, I was watching an illicit free stream of an F1 race and suddenly frames started dropping...and I looked at my network widget and saw my uplink to the internet was being saturated. I was it seemed, part of some javascript botnet. It finished as soon as I closed the browser window.

These things get *noticed*.

True, but not germane to the point that its possible for a very small number of people to create a CPU, write an assembler, write a compile in assembler and bootsrtap their way to a known (to them, at least) good secure chipset and toolchain.

And the antidote to all these people who assure you that lizards are running the earth and bugging their brains with embedded chips is to tell them to do precisely that.

Or assure them that the only reason they think that, is *because the lizards want then to*.

:-)

I have a Transputer T9000 coffee mug somewhere. It has 4 handles spaced

When I first read about the Transputer I wanted to hook 16 of them up into a hypercube.

I have programmed hypercubes of Analog Devices SHARC processors. The number crunching power was "awesome" back in the late 90s.

I wanted to do my final year project using transputers, unfortunately it turned out the department only had one dev board and couldn't get any more ... ended up using Apollo workstations instead.

Then don't hide it, have it there in plain sight - like the Intel Management Engine, and the AMD equivalent.

The more you examine details of the IME that we know about, the more worrying it gets. It's a CPU within CPU running closed software with higher privilege than main CPU, able to access all memory, any hardware and create its own network connections.

You can look at the assembler of the main CPU as much as you like, but you've no idea what is running on the IME.

Luckily ARM doesn't have a management engine - yet!

---druck

Arm doesn't have a management engine, because Arm (mostly) don't make chips. That's up to Qualcomm, Samsung or whoever. You don't get a full datasheet for what's in one of those.

In the case of the original Pi, the Arm *is* the management engine. It was used for managing the GPU, which was the main function of the chip originally.

(well sorta, the original Broadcom chips didn't have an Arm in them)

Theo

Indeed. CISC processors running microcode are definitely in the 'secret software' class. Which is the nice thing about ARM. Keep it simple and run it blazingly fast. Although my friend who worked on the first chip at Acorn says it is massively more complex today than the original incarnation.

But even microcode can be disassembled if you have the right kit and skills...

Tell me more. This is a corner of history I am only vaguely familiar with., Wasn't the original chip a failed set top box chip? Which is why it always had HDMI.....

When the Pi project was coming together, the folks at Cambridge Broadcom were looking for a suitable chip. The VC4 was already in production and did roughly what they wanted but had no CPU, so the decision was made to modify the existing chip. The story goes that they raided their parts bin, found an already-decade-old ARM1176 and slapped it in the VC4 - I heard the timeline for this was a month. The rest is history.

This is why the Pi Zero and 1 have the ancient ARMv6 CPU architecture, where other vendors were already shipping ARMv7 CPUs (Cortex A8 and similar) around 2007 or so. And also why the boot process on Pi 1-3 is backwards from what we're used to: they boot the GPU first and only later does the GPU start up the Arm. The GPU is the main processor in the system, the Arm is a secondary processor.

Theo

I've been poking around at these lately: