no difference when verifying Sinkclose fix in agesa ComboAM4v2PI-1.2.0.Cc

[j4nn]

Tried to use platbox_cli in linux, it seems to work, at least dump_spi retrieves correct bios flash content and chipset command shows some info similar to screenshots in the project's readme.

But comparing the behavior when running bios with agesa ComboAM4v2PI-1.2.0.B vs the case when running bios with ComboAM4v2PI-1.2.0.Cc (which should fix Sinkclose), there is no change in platbox_cli output that would hint the vulnerability got actually fixed, basically differing only in SMM_BASE - please see the attached logs. Flash content could also be read in all cases.

Could you please explain what we should see when a platform is vulnerable vs when a platform is not vulnerable?
Thank you.

Please note, the BIOS has been flashed via external SPI programmer in case of platbox-agesa-ComboAM4v2PI-1.2.0.Cc-ROMarmorYES.txt file.

platbox-agesa-ComboAM4v2PI-1.2.0.B-ROMarmorNO.txt
platbox-agesa-ComboAM4v2PI-1.2.0.B-ROMarmorYES.txt
platbox-agesa-ComboAM4v2PI-1.2.0.Cc-ROMarmorNO.txt
platbox-agesa-ComboAM4v2PI-1.2.0.Cc-ROMarmorYES.txt

[j4nn]

Enabled secure boot in bios and configured linux to boot in secure boot mode, hoping to see some change with platbox regarding Sinkclose when using bios with agesa ComboAM4v2PI-1.2.0.Cc, but there is no change visible either (apart from SMM_BASE) - attaching the log from platbox-cli of this test run.

[    0.004427] Secure boot enabled
[   12.810472] PEFILE: Unsigned PE binary
[  136.091693] Loading of unsigned module is rejected
[ 1109.636118] Creating Device KernetixDriver
[ 1173.919964] kernetix device has been opened
[ 1241.979266] kernetix device successfully closed

platbox-agesa-ComboAM4v2PI-1.2.0.Cc-SecureBootYES-ROMarmorYES.txt
Quite confused here.

Any ideas?

[j4nn]

Just bricked my motherboard after running Platbox/pocs/SecureCoreAcer.
And that has been with ComboAM4v2PI-1.2.0.Cc agesa version.

Is that mitigation for CVE-2023-31315 supposed to allow direct spi writes to bios flash?

After running the poc two times in a single session, while having RomArmor and SecureBoot active in linux boot, the poc showed only FF data, but clearly the write somehow succeeded as I even could read the data back from platbox_cli with dump_spi, spotting the string in the spi dump file.

Reboot failed, as it hang in power cycling endless loop without even showing any post code on the postcode display on the motherboard (the display did not light up at all).

Dumped the spi flash content via spi programmer, got many strange changes there, but the two runs of the poc clearly went through, even though they somehow miss the first char:

-00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
-00000060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
+00000050  ff ff ff ff 68 69 73 20  69 73 20 63 6c 65 61 72  |....his is clear|
+00000060  6c 79 20 6e 6f 74 20 61  20 67 69 62 73 6f 6e ff  |ly not a gibson.|

-00100050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
-00100060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
+00100050  ff ff ff ff 68 69 73 20  69 73 20 63 6c 65 61 72  |....his is clear|
+00100060  6c 79 20 6e 6f 74 20 61  20 67 69 62 73 6f 6e ff  |ly not a gibson.|

The following does not really look healthy:

-00110000  24 50 53 50 50 98 be 61  18 00 00 00 30 05 00 00  |$PSPP..a....0...|
-00110010  00 00 00 00 40 02 00 00  00 04 11 ff 00 00 00 00  |....@...........|
-00110020  01 00 00 00 80 c5 00 00  00 07 11 ff 00 00 00 00  |................|
-00110030  02 00 00 00 4c 22 04 00  00 cd 11 ff 00 00 00 00  |....L"..........|
+00110000  00 50 50 50 10 98 20 00  00 00 00 00 00 00 00 00  |.PPP.. .........|
+00110010  00 00 00 00 00 00 00 00  00 00 11 00 00 00 00 00  |................|
+00110020  00 00 00 00 80 00 00 00  00 01 11 00 00 00 00 00  |................|
+00110030  00 00 00 00 00 00 00 00  00 01 11 00 00 00 00 00  |................|

Fixed the output from chipset command in linux to get the error/ok tags on proper places (used stdout instead of stderr) and got following output with ComboAM4v2PI-1.2.0.Cc agesa both romarmor and secure boot enabled:

/dev/KernetixDriver0 opened successfully: 3
>>> chipset
Detected chipset:
=> Family: 19
=> Model: 21

warning: SPI_ERASE could not be found!
MemoryRange: 0


=== SPI Range Protections ===
Rom Protect 0: 00000000
  - Base: 00000000
  - RangeUnit: 0
  - Range: 00000000
  - Protected size: 00000000
  - WriteProtected: 0
  - ReadProtected: 0
  - Total range [00000000, 00000fff]
  - STATUS: Warning - Unused ROM Range Protection
Rom Protect 1: 00000000
  - Base: 00000000
  - RangeUnit: 0
  - Range: 00000000
  - Protected size: 00000000
  - WriteProtected: 0
  - ReadProtected: 0
  - Total range [00000000, 00000fff]
  - STATUS: Warning - Unused ROM Range Protection
Rom Protect 2: 00000000
  - Base: 00000000
  - RangeUnit: 0
  - Range: 00000000
  - Protected size: 00000000
  - WriteProtected: 0
  - ReadProtected: 0
  - Total range [00000000, 00000fff]
  - STATUS: Warning - Unused ROM Range Protection
Rom Protect 3: 00000000
  - Base: 00000000
  - RangeUnit: 0
  - Range: 00000000
  - Protected size: 00000000
  - WriteProtected: 0
  - ReadProtected: 0
  - Total range [00000000, 00000fff]
  - STATUS: Warning - Unused ROM Range Protection

SPI ROM SMM Write Enable: 1

SPI BASE: fec10000
SPIx00 - SPI_Cntrl0: 4fce309f
  -  SpiAccessMacRomEn: 1 - FAILED
  - SpiHostAccessRomEn: 1 - FAILED

 RestrictedCmd: 00 00 00 00
RestrictedCmd2: 00 00 00 00
  - Write Enable Op (0x06): FAILED (Not blocked)

SPIx0C [SPI_Cntrl1] - ByteCommand: 02
SPIx10 - CmdVal0
  - MacLockCmd0: 06
  - MacLockCmd1: 20
  - MacUnlockCmd0: 04
  - MacUnlockCmd1: 04
SPIx14 - CmdVal1
  - WREN: 06
  - WRDI: 04
  - RDID: 9f
  - RDSR: 05
SPIx18 - CmdVal2
  - Read: 03
  - FRead: 0b
  - PAGEWR: 0a
  - BYTEWR: 02
SPIx1D - Alt_SPI_CS
  - lock_spi_cs: 0 - FAILED
  - SpiProtectEn0: 1 - OK
  - SpiProtectEn1: 1 - OK
  - SpiProtectLock: 0 - FAILED
  - AltSpiCsEn: 0

Flash Base: 00000000ff000000
Flash Size: 01000000

MSR C001_0111 SMM Base Address (SMM_BASE)
 => Base: bff49000
   -> SMI-Handler Entry Point: bff51000
   -> SMM Save-State Area    : bff58e00

MSR C001_0112 SMM TSeg Base Address (SMMAddr)
 => Base : bf000000
 => Limit: bfffffff

MSR C001_0113 SMM TSeg Mask (SMMMask)
 => Value: 0000ffffff006003
   -> TSegMask: 000000ffff000000
   -> TMTypeDram: 6
   -> AMTypeDram: 0
   -> TMTypeIoWc: 0
   -> AMTypeIoWc: 0
   -> TClose: 0
   -> AClose: 0
   -> TValid: 1
   -> AValid: 1

MSR C001_0015 Hardware Configuration (HWCR)
 => Value: 189000011
   -> SMMLock: 1 - OK

MSR C001_0010 System Configuration (SYS_CFG)
 => Value: 0000000000740000
   -> Tom2ForceMemTypeWB: 1
   -> MtrrTom2En: 1
   -> MtrrVarDramEn: 1
   -> MtrrFixDramModEn: 0
   -> MtrrFixDramEn: 1
   -> SysUcLockEn: 0

MSR C001_0054 IO Trap Control (SMI_ON_IO_TRAP_CTL_STS)
 => Value: 0000000000000000
   -> IoTrapEn: 0
   -> SmiEn3 (MSR C001_0053): 0
   -> SmiEn2 (MSR C001_0052): 0
   -> SmiEn1 (MSR C001_0051): 0
   -> SmiEn0 (MSR C001_0050): 0

MSR 0000_001B APIC Base Address (APIC_BAR)
 => Value: fee00800
   -> BA: fee00000
   -> Enabled: 1
   -> BSC: 0

MSR C001_0058 MMIO Configuration Base Address
 => Value: 00000000f000001d
   -> MmioCfgBaseAddr: 00000000f0000000
   -> BusRange: 7
   -> Enable: 1

D0F0x4C PCI Control.MMIOEnable: 1
 -> MMIO Base/Limit pair is enabled

D0F0x64_x00 Northbridge Control.HwInitWrLock: 1
D0F0x64_x17 Memory Mapped IO Base Address: ffffffff
D0F0x64_x18 Memory Mapped IO Limit: ffffffff

D0F0x64_x19-1A Top of Memory 2: 0ffffffffffffffe
  -> Enabled: 1

MSR C001_001D Top Of Memory 2 (TOM2)
 => Value: 0000001840000000

D0F0x90 Northbridge Top of Memory: c0000000

MSR C001_001A Top Of Memory (TOM)
 => Value: 00000000c0000000

PSP Config at +10994h: 00000000
 - Platform vendor ID: 00
 - Platform model ID: 00
 - BIOS key revision ID: 0000
 - Root key select: 00
 - Platform Secure Boot Enable: 0
 - Disable BIOS key anti-rollback:  0
 - Disable AMD key usage:  0
 - Disable secure debug unlock:  0
 - Customer key unlock:  0

PSP Config at +10998h: 50004022
- PSB status: 22
- PSB fusing readiness: 0
- HSTI state: 05

HSTI State: 0
PSP Feature REG: 0
PSP Feature REG (Security Capabilities): 0
 - PSP Security Fused Part: 0
 - PSP Security Debug Lock On: 0
 - PSP Security TSME STATUS: 0
 - PSP Security Anti-Rollback Status: 0
 - PSP Security RPMC Production Enabled: 0
 - PSP Security RPMC SPIROM Available:  0
 - PSP Security HSP TPM Available:  0
 - PSP Security ROM ARMOR Enforced:  0
>>> exit

[n3k]

The output shows that ROM Armor is not enabled:

- PSP Security ROM ARMOR Enforced:  0

To your original question, there is no update made at this point to Platbox that checks the state of the sinkclose vulnerability. The new code is going to be released mid November.