On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote:
On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote:
This is about "AMD Platform Management Framework TA", which seems to be
about AMD CPU features. The first (and only) commit message has this:
```
amd_pmf: Add initial PMF TA for Smart PC Solution Builder
AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
```
Firmware for AMD graphics belongs in firmware-nonfree, but the
``amdtee`` directory seems to fit better in amd64-microcode?
Could be, yes. It isn't needed at early boot at all, but then neither is
AMD-SEV, and it is in amd64-microcode.
So yeah, I could carry it on amd64-microcode, but we need to coordinate it
re. linux-firmware packages, since it has to move from one package to the
other. Unless it has never made it to any linux-firmware packages ?
It has never made it into any firmware-nonfree package, so nothing needs to
move.
I'm working on a 20230804 update where I have added AMD-SEV to the Files-
Excluded section. I then came across the 'amdtee' dir and was wondering what
(best) to do with that, hence this bug.
And I need to know what I should do about it on the backport branches and
security update branches.
I don't know/understand what you mean by this. Can you clarify?
On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello
<mario.limonciello@amd.com> wrote:
The firmware is only used on mobile APUs (which contain graphics). So
if needing to pick an existing binary package instead of a new one I can
see a stronger argument to bundle it with the graphics package.
My logic was that this is about AMD TEE (Trusted Execution Environment), which
I *assumed* is part of/tied to the CPU. This thought is based on that on ARM
platforms, you also have a TEE and that is part of the CPU (and implemented in
TF-A IIUC). I can be wrong here ofc.
There's no need to pick an existing binary package. I could add it to amd-
graphics, but I consider that a poor choice. I could create a new binary
package `amdtee` in firmware-nonfree (source package).
That would be fine afaic.
But as I assumed AMD TEE is a CPU feature, adding it to a package which
already deals with AMD CPU features seems the most logical.
And if AMD TEE becomes available in the future in 'normal' desktop CPUs
(without graphics) it would be 'weird' to have to install firmware-amd-graphics
to make use of it (and then a move probably would be needed).
So I have no strong feelings about it, just trying to find the best place for
the `amdtee` dir.
Cheers,
Diederik