Re: Putting together a computer from old components

On 03 Dec 2021 13:56:52 +0000 (GMT)
Theo <[email protected]> wrote:
> Jaimie Vandenbergh <[email protected]> wrote:
> > On 29 Nov 2021 at 18:46:48 GMT, "Spiros Bousbouras" <[email protected]>
> > wrote:
> > > - Do ARM processors have anything analogous to the Intel management engine ?
> > > If not then yes , that's a plus in my book. Plus I want to learn some ARM
> > > assembly so having an ARM processor would be a bonus.
> > 
> > I am fairly sure (but not 100%) that they do not. Raspberry have solid
> > documentation, and I've not found an extra controller inside but also
> > they don't make a statement that there isn't (I mean why would they
> > think to?)
> > https://www.raspberrypi.com/documentation/computers/processors.html#bcm2835
> 
> Arm designs processors, it doesn't design chips.  It's up to the chip designer
> to decide what else to put in there.  For example you can get the same Arm
> core with an Arm, Qualcomm or Broadcom GPU.
> 
> It is quite common for systems on chip to have additional microcontroller
> cores for managing things, for example booting, clocks, power and DDR
> timing.  Some of those may be exposed (as a 'system control unit'), but
> others aren't.  For example the battery will have a microcontroller in it to
> keep an eye on the charging/discharging profile, the touchpad will have a
> microcontroller for speaking USB, etc etc.  Many of those microcontrollers
> don't have access to system memory (especially not the ones off-chip), but
> some do.  They don't often appear on the datasheet as a 'processor' but
> simply as a functional block for doing those things (eg a battery monitoring
> unit).  Almost none of the firmware that runs on all of these pieces is open
> source.
> 
> In the Raspberry Pi case there's a GPU that runs closed-source firmware, so
> it's not unusual in that respect.  Whether it's analogous to the Intel ME
> depends on what you're concerned about: the GPU doesn't have a network
> socket on it, but then it can reach the ethernet controller (maybe another
> CPU!) over the memory interconnect.  (Arm offers a System MMU to provide
> some degree of protection here, but the RPi doesn't use one).
> 
> So if you were worried about a supply chain attack providing you malicious
> GPU firmware then it's not going to help.  If you're worried about malicious
> network traffic attacking the GPU, that won't get to the GPU in normal
> operation.
> 
> I'm not familiar with the internals of the 15-20 year old AMD systems you're
> talking about, but I would be unsurprised if there were similar control
> processors in there for doing similar kinds of tasks - just more basic ones. 
> And of course those systems haven't had a BIOS update in 15 years so any
> vulnerability lurking in there is not going to be patched.  When you start
> building a system with a GPU, network card, storage controller, etc, that's
> all firmware that hasn't seen updates in a decade or more.
> 
> TL;DR: you need to boil down to exactly what is objectionable in the Intel
> ME before asking whether the same threat exists on other platforms.  'Other
> things running software you can't see / isn't open source' is a given, on
> anything more complex than a Sinclair Spectrum.

What is objectionable is the increase in the attack surface created by the
management engines (both Intel and AMD) without sufficient explanations on
what functionality they offer (useful to the user or in general). There is
also the fact that many respectable sources express similar concerns. The
question "Do ARM processors have anything analogous to the Intel management
engine ?" indirectly also asks whether similar concerns have been expressed
about ARM processors ; and it's not just a matter of existence but also of
degree. By degree I mean the degree of at least the following 2 parameters :

- Complexity of the functionality ; larger complexity means greater opportunity
  for security flaws.

- Justification of the functionality from the point of view of the end user
  (me !).

There is of course also the binary parameter of whether it's secret or not.
The more things are secret , the worse. I probably can't avoid all secret
firmware (as you point out) but I will try to avoid what I can. I note also
that there is a political component which seems to parallel the time when
Stallman started his GNU efforts towards open source software , at least
according to how he tells the story. According to Stallman , most software
used to be free , not necessarily in the modern legal sense as embodied by
the GPL and other licenses but in a practical sense in that you could inspect
the software and modify it. Then the trend started to move towards close
source and Stallman tried to oppose this with some success. In an analogous
fashion , in hardware the trend seems to be towards more secrecy and more
taking control away from the end user and owner of the hardware for unknown
ends. I'm trying to resist this. I don't expect I will be anywhere near as
successful as Stallman was with software but I (will) do what I can.

Anyway , thanks for all the technical information. Even if I don't manage to
mitigate my risks with my proposed measures (you seem to think that I may
even be increasing my risks) , I'm learning useful relevant information.

-- 
vlaho.ninja/prog