How can UEFI block downgradind the dbx?

[korpe1]

How can UEFI block downgrading the dbx? Or is it UEFI?

dbx is located on writable storage, so how is this possible?

[superm1]

Dbx operations are only append. If you want to remove them, you'll need to reset the bios.

[hughsie]

In general you can't -- by design. Otherwise malware could just downgrade the dbx to a lower version and then install itself as a persistent firmware exploit. If it helps, sometimes resetting the BIOS settings to "factory defaults" clears the dbx completely.

[korpe1]

How it works is different for Intel and AMD, but essentially there is a write protect pin that is controlled by a trusted entity. OS can't change it, only the SoC can. Think about it as going through different trust boundaries. When the OS calls the UEFI API it will use an abstracted method to verify the signature. UEFI API then works with the SoC to actually arbitrate a write.

You didn't use reply, so please clarify, what part of my comment you talking about? Do you talk about the interface of bootROM or UEFI?

Also note that chips of Intel and AMD are mainly just CPUs and not SoCs. You might see integrated GPUs in laptop versions, but nothing level of SoCs used in mobile devices.

[hughsie]

Also note that chips of Intel and AMD are mainly just CPUs and not SoCs

Mario works for AMD.

[korpe1]

Also note that chips of Intel and AMD are mainly just CPUs and not SoCs

Mario works for AMD.

I think, also products by AMD are mainly CPU rather than SoCs. But this isn't important, just a sidenote.

[korpe1]

I really do appreciate both of your answers, but this conversation has going to sideways. I think maybe @superm1 think these things from different perspective than me. It isn't bad at all, but could it be better if something other try answer as well? Maybe @hughsie?

A set of straight questions to clarify this conversation:

• BootROMs on PCs typically doesn't check the signature of firmware on flash, yes or no?

• BootROMs typically gives ability to set unrestricted programming mode (alongside loading mode) and rewrite the flash, yes or no?

• UEFI standard a spesify abstract requiment to UEFIs to blocking downgrade the dbx, yes or no?

• UEFIs just simply doesn't allow downgrade the dbx through its APIs as per standard, yes or no?

• Though UEFIs doesn't allow this, you can downgrade dbx with rewriting the flash via low-level interface of the bootROM (SPI in test pins etc)?

• dbx is stored in a secure cryptoprocessor that guard all uses of the dbx. So even bootROM or anything doesn't can downgrade the dbx without right authorization? Yes or no?

• Most of UEFIs although give ability to reset dbx to default in the UEFI setup manager, yes or no?

• Many of UEFIs give ability to replace/set users own KEK (and PK, DB, DBX), how UEFI performs in this situation? What's the point of block DBX downgrades if the user can anyway replace KEK along with PK, DB, DBX?

Thank you already for all of your work, answers, and all other!

[superm1]

I think, also products by AMD are mainly CPU rather than SoCs. But this isn't important, just a sidenote.

I respectfully disagree. Legacy AMD products were true CPUs. Modern products by AMD have a ton of non-X86 blocks that do other tasks. NPU, ASP (TEE environment), GPU, MP1 (power management controller), MP2 (SFH), FCH. There is a fabric for communication between blocks. It's a true system on chip. When I compare to a mobile SoC, the only significant architectural difference is that there is WWAN or WLAN built into the chip.

I think maybe @superm1 think these things from different perspective than me.

Surely I do. But I'll try to comment from an outsider view.

BootROMs on PCs typically doesn't check the signature of firmware on flash, yes or no?

For generic PCs:

• Intel Boot Guard will verify the signature.
• For AMD, the ASP (formerly known as PSP) will verify the signature.

Some OEMs have implementations that the EC plays a role in trust for the SPI and SPI arbitration, but this can't be generically said.
For Chromebooks, Titan plays a role here.

BootROMs typically gives ability to set unrestricted programming mode (alongside loading mode) and rewrite the flash, yes or no?

Not in most modern PC architecture.

UEFI standard a spesify abstract requiment to UEFIs to blocking downgrade the dbx, yes or no?

Yes

UEFIs just simply doesn't allow downgrade the dbx through its APIs as per standard, yes or no?

The DBX API works off of signed payloads, which are delivered as append operations. I don't know if there is a way to distribute a signed variable that is a remove operation. Might need to ask someone else on that unless Richard knows.

Though UEFIs doesn't allow this, you can downgrade dbx with rewriting the flash via low-level interface of the bootROM (SPI in test pins etc)?

Yeah; if the implementation stores it a FV on the SPI and you end up turning off the machine and use a dediprog you can probably do this. Whether or not the BIOS rejects it on the next boot is another story.

dbx is stored in a secure cryptoprocessor that guard all uses of the dbx. So even bootROM or anything doesn't can downgrade the dbx without right authorization? Yes or no?

Where it's stored is implementation vendor specific.

Most of UEFIs although give ability to reset dbx to default in the UEFI setup manager, yes or no?

Yes

Many of UEFIs give ability to replace/set users own KEK (and PK, DB, DBX), how UEFI performs in this situation? What's the point of block DBX downgrades if the user can anyway replace KEK along with PK, DB, DBX?

DBX operations can happen without a user present. Think of it as if software can do it malware can do it too.
Replacing KEK/PK/DB/DBX require you to interactively open BIOS setup and do things. Software can't directly do this.