public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Werner Sembach <wse@tuxedocomputers.com>
To: Richard Hughes <richard@hughsie.com>,
	Mario Limonciello <mario.limonciello@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Richard Hughes <hughsient@gmail.com>,
	ggo@tuxedocomputers.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: Avoid putting some root ports into D3 on some Ryzen chips
Date: Tue, 17 Dec 2024 00:37:24 +0100	[thread overview]
Message-ID: <2b762f16-fe50-4dec-8f3f-dfe21977d807@tuxedocomputers.com> (raw)
In-Reply-To: <vVLu9MdNWVCG96sN3xqjkmMVQpr_1iu61hX0w0q5dSQtFBi9ERc3b6hSoCjobPSTNgkIp3PBheheyUlayhMeQjShsx62zNqxWnPsrHt-xaM=@hughsie.com>

Hi,

Am 13.12.24 um 11:05 schrieb Richard Hughes:
> On Thursday, 12 December 2024 at 19:01, Mario Limonciello <mario.limonciello@amd.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.

  reply	other threads:[~2024-12-16 23:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-09 19:36 [PATCH v2] PCI: Avoid putting some root ports into D3 on some Ryzen chips Werner Sembach
2024-12-09 19:45 ` Mario Limonciello
2024-12-10 15:24   ` Werner Sembach
2024-12-10 16:00     ` Mario Limonciello
2024-12-11 12:47       ` Werner Sembach
2024-12-11 21:24         ` Mario Limonciello
2024-12-12 18:47           ` Werner Sembach
2024-12-12 19:01             ` Mario Limonciello
2024-12-13 10:05               ` Richard Hughes
2024-12-16 23:37                 ` Werner Sembach [this message]
2024-12-17 10:10                   ` Richard Hughes
2024-12-17 11:58                     ` Werner Sembach
2024-12-17 14:12                       ` Mario Limonciello
2024-12-17 14:07           ` Werner Sembach
2024-12-17 14:11             ` Mario Limonciello
2024-12-17 15:58               ` Werner Sembach
2024-12-17 16:08                 ` Werner Sembach
2024-12-17 16:18                   ` Mario Limonciello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b762f16-fe50-4dec-8f3f-dfe21977d807@tuxedocomputers.com \
    --to=wse@tuxedocomputers.com \
    --cc=bhelgaas@google.com \
    --cc=ggo@tuxedocomputers.com \
    --cc=hughsient@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=richard@hughsie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox