Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #81739 > unrolled thread

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? Diederik de Haas <didi.debian@cknow.org> - 2024-02-02 18:00 +0100
    Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? Diederik de Haas <didi.debian@cknow.org> - 2024-02-12 21:30 +0100
    Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? Diederik de Haas <didi.debian@cknow.org> - 2024-02-13 01:30 +0100
    Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? Diederik de Haas <didi.debian@cknow.org> - 2024-02-13 21:10 +0100
      Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? "Henrique de Moraes Holschuh" <hmh@debian.org> - 2024-02-15 19:20 +0100
        Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? "Henrique de Moraes Holschuh" <hmh@debian.org> - 2024-02-15 19:50 +0100
    Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode? "Henrique de Moraes Holschuh" <hmh@debian.org> - 2024-02-15 20:10 +0100

#81739 — Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

Package: amd64-microcode
Version: 3.20231019.1
Severity: normal
X-Debbugs-Cc: debian-kernel@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

While working on a firmware-nonfree update I came across a commit where
a new file was added in a new directory: ``amdtee``:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdtee

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?

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

amd64-microcode depends on no packages.

Versions of packages amd64-microcode recommends:
ii  initramfs-tools  0.142

amd64-microcode suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZb0dXwAKCRDXblvOeH7b
bhbwAQDt0VW65WhlRttuxWFueuSVHvzo/3zN4deCEESRxvVFrAEA+WrBIu/CWSX+
tMw/Lg8VsnRIstVaqZbTMeAyjgv8fQA=
=3uCZ
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#81865

[Multipart message — attachments visible in raw view] — view raw

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.

That it *currently* is only used on mobile APUs is something I consider to be 
an implementation detail. I can be wrong on this too.

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

[toc] | [prev] | [next] | [standalone]

#81869

[Multipart message — attachments visible in raw view] — view raw

On Monday, 12 February 2024 21:25:35 CET Mario Limonciello wrote:
> > 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.
> 
> To me using the nomenclature of "CPU" is confusing.  We should be
> calling these SoCs.

While SoC may be technically more accurate, I'm not in favor of using it in 
this context as it doesn't give any hint on what it does.

I'd use CPU for general processing and GPU for graphics processing.

> Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly
> called PSP) and various others.

I would describe an APU as a CPU with integrated GPU.
My guess is most people/end-users aren't even aware of the ASP/PSP.

I would classify the various ASICs (like IPU/NPU) as part of the CPU, but it 
is (by definition?) an arbitrary qualification/separation.

> > 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.
> > 
> > So I have no strong feelings about it, just trying to find the best place
> > for the `amdtee` dir.
> 
> My general feeling is that having separated binary packages for all the
> AMD 'things' makes things "generally" confusing for end users and is
> needless extra work for you to maintain.

I mostly agree. It isn't (much) extra work for 'me' though.

> 'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries
> will go to linux-firmware.git and then where do those go?

My (current) thinking is to have 2 categories:
- AMD CPU related
- AMD GPU/graphics related

> Current products only put the IPU/NPU in APU chips, but who is to stay;
> those might end up in SoCs without graphics in the future too.

I think it's important to facilitate people having f.e. the following combos:
- Intel CPU with AMD GPU
- AMD CPU with Nvidia GPU
- AMD CPU with AMD GPU (discrete or integrated)

Preferably without having to install 100s of MB of firmware files of which 95% 
the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786)

> How would you feel about making a master "amd" metapackage that pulls
> them all?  You can split as you see fit then and people who want the
> 'easy button' can just install that package.

I'm not much of a fan of such metapackages. I think it mostly indicates that 
the purpose of the various packages isn't clear, so let's install all of them.
Clarifying the purpose better is a better solution imo.
I'm aware others feel different: https://bugs.debian.org/522415

I prefer to keep that discussion out of this bug though, feel free to open a 
new bug for that if you do want it.

[toc] | [prev] | [next] | [standalone]

#81875

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, 13 February 2024 17:59:55 CET Mario Limonciello wrote:
> > I think it's important to facilitate people having f.e. the following
> > combos: 
> > - Intel CPU with AMD GPU
> > - AMD CPU with Nvidia GPU
> > - AMD CPU with AMD GPU (discrete or integrated)
> > 
> > Preferably without having to install 100s of MB of firmware files of which
> > 95% the user doesn't actually need. (See f.e.
> > https://bugs.debian.org/1057786)
> You don't currently split up the AMD APU integrated graphics and dGPU,
> and I doing this is a bad idea as it's possible to reuse IP versions on
> APU and dGPU hardware.  If they are the same then they would use the
> same firmware binaries.

I have/had no plan to make a split for iGPU and dGPU, both would need to 
install the `firmware-amd-graphics` package.

For the 3 scenario's above:
- `intel-microcode` + `firmware-amd-graphics`
- `amd64-microcode` + `firmware-nvidia`*
- `amd64-microcode` + `firmware-amd-graphics`

AMD APU's would fall into scenario 3.

*) If my MR gets accepted, otherwise `firmware-misc-nonfree`

> For reference on the size:
> 
> $ du -sh amdgpu
> 60M     amdgpu
> 
> $ du -sh du -sh amdtee/
> 20K     amdtee/
> 
> $ du -sh amd-ucode/
> 112K    amd-ucode/
> 
> $ du -sh amd
> 268K    amd

What I want(ed) to prevent is that for scenario 2, the user should NOT have to 
install the `firmware-amd-graphics` package to get the amdtee firmware.

> These aren't yet upstream, but so you can see the size:
> 
> $ du -sh amdnpu/
> 3.3M    amdnpu/

And that seems like a future candidate too for amd64-microcode package.

> I think your suggestion to combine all the non graphics related binaries
> to a single package and all graphics related binaries to another is fine.

Excellent, then I think we're all in agreement :)

I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and Henrique 
can add those files to the amd64-microcode package.

Cheers,
  Diederik

[toc] | [prev] | [next] | [standalone]

#81885

On Tue, Feb 13, 2024, at 17:04, Diederik de Haas wrote:
> I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and Henrique 
> can add those files to the amd64-microcode package.

Agreed.   For now, let's have amd64-microcode package to be the "SoC-and-CPU-related" firmware distribution for AMD, and keep the firmware for other AMD hardware, such as GPU adapter cards in the other firmware packages.

Since Diederik confirmed that amd-tee has never been shipped in a firmware-* package in Debian, it will not cause issues for amd64-microcode backports.  Good, I can just have it on every branch, then.

I am currently waiting my updated gpg subkey to be activated (it is already in keyring.d.o, but it needs to wait for the monthly push).  It should happen in about 10 days, and then I will upload the new packages to unstable.

Meanwhile, I will prepare the updated packages in salsa.debian.org, if there's a need for a faster upload, we can ask someone to sponsor it next week.

PS: Mario, we're considering the newer AMD processor microcode sitting in linux-firmware to be a non-critical functional update since nobody was informed otherwise AFAIK, and I could not find the newer revisions listed in any AMD advisories.   If you know otherwise, drop us a note privately (e.g. inform the Debian security team, or inform me directly) and we will issue it as a security update.

-- 
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#81887

While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode package, I have noticed that  the linux-firmware WHENCE file mentions a symbolic link that is not present in the git repository.

The missing symlink is:
amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin

Is the amd_pmf driver functional without that symlink ?

-- 
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#81888

On Thu, Feb 15, 2024, at 15:45, Mario Limonciello wrote:
> On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:
>> While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode package, I have noticed that  the linux-firmware WHENCE file mentions a symbolic link that is not present in the git repository.
>> 
>> The missing symlink is:
>> amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin
>> 
>> Is the amd_pmf driver functional without that symlink ?
>> 
>
> symlinks are created by copy-firmware.sh

Thanks. I have to take that into account, then.  Hopefully this is the first instance of that bug in the amd64-microcode packaging, I will check every other file in there to ensure no links were missed.

-- 
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web