View Single Post
  #2  
Old June 6th 18, 06:42 AM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default Concesus of AMD PSP security issue?

xJumper wrote:
There's been a lot of talk lately about CPU vulnerabilities ala Meltown
but what is the general consensus with the obvious built in back doors
being put into CPU's at the OEM level.


AMD Platform Security Processor/Trust Zone Secure Technology which is
AMD's version of Intel AMT/Intel Management Engine/vPro

The processor within a processor with it's own unknown closed source OS
that has access to literally all functions of the system. I don't think
AMD currently has an equivalent to Intels vPro which is the 3G chips in
the CPU that can receive secret forced updates, access to the TCP/IP
stack even before the OS is booted, etc...

In any case there was a lot of talk surrounding this as this is ripe for
potential exploits/vulnerabilities/back doors and there's almost nothing
we can do to prevent them/stop them nor do we even really understand the
full ramifications.

I recall seeing some attempts at getting AMD to release the code open
source, there was various petitions, etc, and then everything died out.

So what's been the consensus on this issue? Has there been any
advancements in getting the code open sourced or at the very least being
able to disable it? I gather I heard a few mobo makers added the option
to disable AMD PSP in BIOS updates, I don't think it's come to mine yet
nor does it seem to be something widespread.


The second half of this page has an answer.

https://security.stackexchange.com/q...cure-processor

The purpose of the two implementations is different.

The Intel VPro setup, the NIC chip has to be an Intel chip,
and those are "split-in-half" NICs. They have a section for
the ME to do communications, and a section for the main CPU
to use.

The AMD implementation doesn't have special hardware paths,
and is more of a dis-embodied processing core inside the CPU.
And like the Intel implementation, has some means of loading
a signed code module as part of the BIOS image.

The AMD implementation still has full access to resources
in the computer, but it can't really use them smoothly,
without upsetting the OS state that also uses the resources.

*******

As for this notion of "back doors in firmware", you're missing
a giant one. The SMM (System Management Mode) allows time-sliced
BIOS operation, while the OS is running. And the OS has *no*
resources to tell it's been swapped out. (You can only tell
indirectly by "missing" time when time-keeping.) If someone
wanted to bug your machine, all they'd need to do is load a special
firmware, and you'd never know it was running. It wouldn't
need to leave any tracks. It would be like a hardware
rootkit.

But nobody worries about that.

I don't think, at least for 5+ year older machines, there's
any signing requirement for such firmwares. So if someone could
gain physical access to your machine, they wouldn't need to put
a bug into your OS (where your AV could detect it), they could
just do something to gain access via SMM.

Intel did add something (which may actually be switched on
with business class computers), where the BIOS signing is
checked at POST time. And this prevents easy insertion
of bogus firmware serial EEPROMs. The OEM designing the
motherboard, has to make sure this is working right
before shipping. This feature would, say, prevent a
computer from being switched to CoreBoot.

*******

I would agree with a need for paranoia concerning the Intel ME.
That scares the crap out of me, because all the hardware paths
are there to "make trouble". The AMD one, just doesn't seem to
have the same level of exposure. They could probably exploit it,
but you might notice something at OS level if they did. AMD
may try to make a remote management solution out of it some
day, so the possibility remains.

At least AMD has potentially put a disable feature in AGESA
for it, but Intel, I don't think I've seen them just flat out
offer an OFF switch for theirs. They offer some shabby workarounds
that still don't satisfy me.

Paul