Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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 $ make install DESTDIR=tmp install -d tmp/lib/firmware ./copy-firmware.sh tmp/lib/firmware $ ls tmp/lib/firmware/amdtee/ -l total 16 -rw-r--r-- 1 supermario supermario 12864 Feb 15 12:44 773bd96f-b83f-4d52-b12dc529b13d8543.bin lrwxrwxrwx 1 supermario supermario39 Feb 15 12:44 amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
'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) 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. For reference on the size: $ du -sh amdgpu 60M amdgpu $ du -sh du -sh amdtee/ 20K amdtee/ $ du -sh amd-ucode/ 112Kamd-ucode/ $ du -sh amd 268Kamd These aren't yet upstream, but so you can see the size: $ du -sh amdnpu/ 3.3Mamdnpu/ 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. 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.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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/ > 112Kamd-ucode/ > > $ du -sh amd > 268Kamd 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.3Mamdnpu/ 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 signature.asc Description: This is a digitally signed message part.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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. signature.asc Description: This is a digitally signed message part.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On 2/12/2024 14:11, Diederik de Haas wrote: 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 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. To me using the nomenclature of "CPU" is confusing. We should be calling these SoCs. Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly called PSP) and various others. The TEE environment is part of the ASP, which is present on all Zen and later SoCs. 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. This specific TEE firmware is only for mobile APUs, but you're right the TEE environment is on socketed client desktop SoCs 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 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. '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? 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. 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.
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
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 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 signature.asc Description: This is a digitally signed message part.
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-
