I was interested in the same issue and did some preliminary research. I'll try to answer some of the questions, though as a non-AMD engineer I cannot be certain.
Does it have software-updatable firmware?
Yes, it does. This firmware is part of the AGESA (AMD Generic Encapsulated Software Architecture), a binary blob distributed from AMD to UEFI firmware vendors.
Also to coreboot, where they come with release notes The PSP section mentions PSP version numbers for different platforms. This suggests that they are updatable.
and how is that firmware secured?
I have not been able to extract the firmware code, and don't know how it is protected. A possible indication would be how the SMU firmware is protected: with a HMAC-SHA in the header, with hidden secret key (see the Rudolf Marek's presentation).
Has it been used for remote management similar to Intel's AMT?
It is impossible to know what it has been used for. However, my findings suggest that remote management is not the primary purpose (unlike Intel's ME). What I've find it does:
The PSP plays a role in the boot process of the CPU (this is often-quoted, so I won't repeat).
The PSP offers the fTPM (firmware based TPM) API for private key management.
The PSP does key managment for SEV (Secure Encrypted Virtualization API), VM memory encryption. This uses an API to the PSP. To see the nuts and bolts there is a Linux patch RFC to introduce support.
The PSP can be used for cryptographic offloading. Support for this landed in the Linux kernel under drivers/crypto/ccp
.
However: there is evidence that code can be loaded dynamically,
- Loading of "trustlets" in coreboot. Pointer for further analysis: PSP library in coreboot
- A comment "Command to load Trusted Application binary into PSP OS" in
drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h
in the Linux kernel. This might deal with a different PSP on the GPU die, but as it is AMD code, even then there might be overlaps.
Is it known to have its own network stack?
No, it is not known to have a network stack in the stock configuration. All APIs seem to be facing the CPU, not the outside world.
Knowing how these processors are designed with vague specifications from "enterprise customers" and DRM vendors, it might be possible to load remote management modules, with network stack. However, nothing that I've found proves that conclusively.
Have there been any known exploits targeting it yet, or any public research done on its firmware?
There is a public vulnerability in the fTPM API.
I could not find any public research on the firmware.
On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?
At least the AMD security processor does not provide a remote management API out of the box (as far as we know), unlike Intel ME. To turn it into a network-listening backdoor, OS software has to provide further modules, or maybe even compromise it.
However, as we've found, it is a black box with very little public research put into it. In cryptography a system gains trust after it is often analyzed and no vulnerabilities are found. Security by obscurity is not acceptable. Unfortunately no one holds security processors to Kerckhoffs's principle.