linux-kernel - Re: [PATCH v2] PCI: Avoid putting some root ports into D3 on some Ryzen chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b762f16-fe50-4dec-8f3f-dfe21977d807@tuxedocomputers.com>
Date: Tue, 17 Dec 2024 00:37:24 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Richard Hughes <richard@...hsie.com>,
 Mario Limonciello <mario.limonciello@....com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
 "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>,
 Richard Hughes <hughsient@...il.com>, ggo@...edocomputers.com,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] PCI: Avoid putting some root ports into D3 on some
 Ryzen chips

Hi,

Am 13.12.24 um 11:05 schrieb Richard Hughes:
> On Thursday, 12 December 2024 at 19:01, Mario Limonciello <mario.limonciello@....com> wrote:
>>>>>> Sadly fwupd/LVFS does not support executing arbitrary efi binaries/
>>>>>> nsh scripts which still is the main form ODMs provide bios updates.
> Of course fwupd can't do this; it would be a huge security hole as the nsh script isn't signed.
>
>> It sounds like some bugs in the implementation of the capsule handler
>> for this system.
> I've seen this with AmiFlash + BIOS.ROM, but never from a capsule. I'm pretty sure Aptio builder is more than capable of constructing a capsule file with the correct DMI data.

The DMI data also includes a serial number that cannot be baked into the 
capsule. And I don't have access to the Aptio builder or other AMI dev tools, 
just the Afu* flash tools.

The command provided by the ODM:

AfuEfix64.efi <bios>.bin /p /b /n /r /x /l /k /capsule

with <bios>.bin being a capsule and:

/p Program Main BIOS -- With recovery flash this does not include DMI strings, 
but does with capsule flash. -> Does flash some /k regions in /capsule flash 
(but not, for example, the logo region).
/b Program Boot Block
/n Programm NVRAM
/r Preserve ALL SMBIOS structure during programming
/x Don't check ROM ID
/l Programm all ROM Holes
/k Programm all non-critical Blocks -- No effect in /capsule flash, does include 
both the logo and the DMI string region.
/capsule Flash using the capsule update process (without it the bios is flashed 
directly by AfuEfix64.efi)

I played around with the command with the conclusion:

- AfuEfix64.efi <bios>.bin /p /capsule -> overwrites DMI strings
- AfuEfix64.efi <bios>.bin /p /r /capsule -> overwrites nothing

I also flashed with fwupd with the result:

- DMI strings where overwritten
- Main BIOS was flashed
- I don't know if Boot Block was flashed
- I don't know if NVRAM was flashed
- I don't know if ROM Holes were flashed
- I don't know if non-critical Blocks were flashed

I tried to explain fwupd and the requirements to our contact at the ODM, but 
just got the unhelpful reply to use the command above.

Do you know how these AfuEfix64.efi flags are passed over to the capsule flash 
process? Then it might be possible to implement them in fwupd too.

>
>> It's not an Insyde problem. I use Insyde capsules regularly myself from
>> fwupd. I also know several other OEMs that ship capsules to LVFS that
>> use Insyde.
> 100% agreed; Insyde firmware makes up more than 20% of the updates on the LVFS now.

Good to know. Sadly the ODM does not care :(.

To be fair all my work I described here is now 2 or 3 years old. I didn't start 
a second try since.

Kind regards,

Werner

>
> Richard.