[svlug] Intel Active Management Technology (AMT): not necessarily your friend

[Rick Moen]

Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

The reason I'm not making any comment on RISC-V is personal ignorance,
but I thank you for your own comments.


> I'd say these kind of bugs are less frequent in AMD CPU compared to 
> Intel but I haven't done any serious research and it may be due just to 
> larger diffusion of Intel making them more scrutinized.

At the risk of being pedantic, bugs are a slightly different (but
overlapping) issue alongside, and separate from, that of featuritis.
For example, Intel is in the middle of producing (or may have just
produced) bugfixes for the recently noted, long-unfixed AMT problem.
(BTW, I saw claims that some of the NSA rootkitting exploits relied on
that bug to instrument machines in a fashion totally invisible to the
regular host and its OS.)

But the point is that, if you do not actually need the remote 'management'
of systems that Active Management Technology (AMT) and the underlying
Management Engine (ME) hardware, then its mere existence and potential
exposure to abuse is a problem even if there are no (known) 'bugs'.
Or, to put it more dramatically:  Gosh, an entire separate processor in
total control of the main computer, invisible to the main computer, and
accessible via a password.  What could possibly go wrong?


> I think the problem in the MIPS/bucks ratio is mainly a problem of 
> produced units and software support. x86 architecture is definitively 
> not superior to alternatives.

Moreover, it's really rare that for Linux use you particularly care
about CPU power.  In most use-cases and with most hardware (particularly
hardware aimed at MS-Windows), CPU grunt is just not the limiting
factor.

And:

> There is a market for media player/smart TV that requires fast CPU/GPU 
> to play high resolution video.

One of the biggest changes I've noticed in the market compared to a
decade or so is the rise of GPU circuitry -- one of the few examples of
dedicated coprocessors to have become truly prevalent.  Most of those
GPU designs have a secret-sauce problem, though.  E.g., Linux on my
MacBookAir has drastically worse video performance than OS X does.


> There is growing interest for ARM in the datacenter
> https://www.nextplatform.com/2017/05/05/red-hat-gatekeeper-arm-datacenter/
> 
> and when and if RH will decide the time has come you'll start to see 
> patches for server related features and optimizations coming to the 
> kernel and relevant software at a much faster speed.

I've been looking forward to that for many years, partly because it
would finally bring about a standard ARM architecture -- no more
special-snowflake sets of kernel patches and bootloaders.

> I don't know about architecture advantage of j-core vs RISC-V but 
> considering j-core is just on FPGA but you can buy real RISC-V and 
> considering who's behind RISC-V I'd bet on RISC-V.

The point of j-core is to be a vanishingly rare example of a totally
open, all the way down to the microcode and throughout all of its
functions, _and_ very inexpensive SoC that is powerful enough for many
types of current computing.  And no patent problems of any kind, as
Hitachi's (and everyone else's) SuperH design patents have all
expired.  

As I said, I don't know anything about RISC-V, but even purportedly
'open' hardware designs, even with Coreboot, etc., have specialised
proprietary hardware subsystems to run USB and hard-drive controllers,
run ACPI and low-level system management services, and much more.  With
a j-core SoC, none of those black boxes would exist.  It's turtles all
the way down.