The issue was this leaking of previously stored data in system memory, due to reusing the system memory without re-initializing it.
> If the userspace aapplication requests to initialise 1 byte,
> the driver will round that up to a full 4096 bytes, and allocate that much memory.
>
> However, it will only initialise the first byte, leaving the rest in its prior state.
> The user can then access the remaining 4095 bytes which have been untouched,
> thus gaining access to the contents of uninitialised memory.
Apparently patched in the currently available latest drivers starting from
Could I install those drivers to a Linux machine? I remember a couple of years ago I tried because of a Ryzen instability issue, but there seemed to be no way.
ASLR might make exploits a more cumbersome to implement. But the PSP is a co-processor with full access to hardware. So it can read the kernel's memory maps and fully deterministically access whatever it wants to access.
If you find or share any information to correlate your point, I'd be happy to read about it and change my mind. I can't prove a negative with the information that I have.
Until then, both AMD and myself both agree that this only affects the method that the Windows implementation uses. I don't think the AMD PSIRT team would misrepresent their findings too.
I wont say it will never affect the Linux PSP implementation, however the driver behaves differently.
I hate 'throwing credentials', but I do work for the Red Hat Product Security team and we have a line of communication with hardware vendors for this reason.
Ok. I think we are mixing 2 things here. This concrete CVE might not affect Linux. So my question how to install the given drivers is irrelevant.
However, in general all sources I read say that the PSP runs some closed source firmware and it has full access to the main memory. So that will always remain a nasty source of insecurity unless there is a switch to disable it (reportedly some BIOSes have such switch, but I have not heard about any 3rd party audit what such switch does.) Vendors will always tell you that their proprietary solution is secure and does not leak any data until someone can somewhat trustworthy demonstrate that they were wrong. Experience has shown that typically it's not a question of whether it happens, but when it happens. It can take years but someday some smart person finds a way. Some create a logo and a website to earn reputation. others earn money secretly.
No, I don't have any insider information you would not have. I just believe the information that it's an ARM processor running closed firmware and it has memory access.
For those who like myself don't know what PSP might be, from the article:
> In short, it’s a coprocessor that has access to just about every part of the computers to which it’s inside. This makes it a prime target for attacks. Introduced around 2013, it’s also entirely closed source, existing as an unknown black box within modern AMD CPUs, which makes the security-conscious highly wary. Operating at a low-level, entirely outside the purview of the main CPU and operating system, the PSP, like the IME, is often considered a potential backdoor into a machine.
My AMD build machine is sold by MSI for gaming. I don't remember having seen such option, there are options for overclocking... Cannot double check now, the machine is in the office and I won't be there before it crashes (knocking on wood) or there is some high priority kernel update.
God I HATE this beneath-the-bottom-of-the-barrel quality enterprise value add shite. And the enterprises that keep paying for them without any idea of just how bad the quality is...
That said...
Don't you have to turn the PSP on (like IME) for it to be vulnerable to exploitation?
> The first part of the problem is when a user makes a call to the AMD driver to allocate some uninitialised memory using the AMD PSP
> The second problem involves calls to the driver to free up contiguous memory space that has previously been allocated.
Surely (LOL) unprivileged code isn't allowed to make these calls?
13 comments
[ 5.4 ms ] story [ 40.8 ms ] threadThe issue was this leaking of previously stored data in system memory, due to reusing the system memory without re-initializing it.
Apparently patched in the currently available latest drivers starting from- AMD PSP driver 5.17.0.0
- AMD Chipset Driver 3.08.17.735
https://www.amd.com/en/corporate/product-security/bulletin/a...
What causes (and avoids) it in drivers can be reproduced/bypassed elsewhere
Until then, both AMD and myself both agree that this only affects the method that the Windows implementation uses. I don't think the AMD PSIRT team would misrepresent their findings too.
I wont say it will never affect the Linux PSP implementation, however the driver behaves differently.
I hate 'throwing credentials', but I do work for the Red Hat Product Security team and we have a line of communication with hardware vendors for this reason.
However, in general all sources I read say that the PSP runs some closed source firmware and it has full access to the main memory. So that will always remain a nasty source of insecurity unless there is a switch to disable it (reportedly some BIOSes have such switch, but I have not heard about any 3rd party audit what such switch does.) Vendors will always tell you that their proprietary solution is secure and does not leak any data until someone can somewhat trustworthy demonstrate that they were wrong. Experience has shown that typically it's not a question of whether it happens, but when it happens. It can take years but someday some smart person finds a way. Some create a logo and a website to earn reputation. others earn money secretly.
No, I don't have any insider information you would not have. I just believe the information that it's an ARM processor running closed firmware and it has memory access.
> In short, it’s a coprocessor that has access to just about every part of the computers to which it’s inside. This makes it a prime target for attacks. Introduced around 2013, it’s also entirely closed source, existing as an unknown black box within modern AMD CPUs, which makes the security-conscious highly wary. Operating at a low-level, entirely outside the purview of the main CPU and operating system, the PSP, like the IME, is often considered a potential backdoor into a machine.
[0] - https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
[1] - https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSP-...
[2] - https://www.reddit.com/r/Amd/comments/852s99/q_is_there_any_...
My AMD build machine is sold by MSI for gaming. I don't remember having seen such option, there are options for overclocking... Cannot double check now, the machine is in the office and I won't be there before it crashes (knocking on wood) or there is some high priority kernel update.
That said...
Don't you have to turn the PSP on (like IME) for it to be vulnerable to exploitation?
> The first part of the problem is when a user makes a call to the AMD driver to allocate some uninitialised memory using the AMD PSP
> The second problem involves calls to the driver to free up contiguous memory space that has previously been allocated.
Surely (LOL) unprivileged code isn't allowed to make these calls?