Hi.

I just ran the Device Guard and Credential Guard hardware readiness tool:

Zitat

---

The following additional qualifications, if present, can enhance the security of Device Guard / Credential Guard on this system:
HSTI is absent
NX Protector is absent
SMM Mitigation is absent

---

Is there a way to add those feature to a BIOS image (ASUS Z170-A)?


Thanks in advance!

HSTI never heard of and not in BIOS, I looked it up and sounds like maybe software solution.
NX is in BIOS already, this is NX-Bit aka Execute Disable Bit (it's enabeld by default once you load optimized) Located at Advanced >> CPU Config page (if you can't see it, I can make visible for you, show me image of your BIOS at this page, scroll up/down if needed)
SMM options I can make visible to you as well, they are located at same place as above, once I see your BIOS images from this page I will make visible for you too. There is no specific setting named SMM mitigation though, but a handful of related settings, probably same just named differently (you can see all this in AMIBCP)
This may be referring to BIOS Lock needs to be enabled as well, without that enabled SMM protections cannot be loaded >> BIOS Lock >> Enable/Disable the PCH BIOS Lock Enable feature. (Required to be enabled to ensure SMM protection of flash.)

Zitat von Lost_N_BIOS im Beitrag #2

---

HSTI never heard of and not in BIOS, I looked it up and sounds like maybe software solution.

---

Zitat von Lost_N_BIOS im Beitrag #2

---

NX is in BIOS already, this is NX-Bit aka Execute Disable Bit

---

Zitat von https://uefi.org/sites/default/files/resources/Fei%20Zhou%20-%20General%20FW%20Overview_Microsoft.pdf

---

VBS enablement of NX protection for UEFI RUNTIME SERVICES

– VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory
regions. UEFI runtime service code must support read-only page protections, and UEFI runtime
service data must not be executable implement the UEFI 2.6
EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be
described by this table

• PE sections need to be page-aligned in memory (not required in non-volatile storage)
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for
  configuration by the OS
  – All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both.
  – No entries may be left without either of the above attributes, indicating memory that is
  both executable and writable. Memory must be either readable and executable or
  writeable and non-executable (Documented on MSDN)

Notes:

• Only applies to UEFI runtime service memory and not UEFI boot service memory. Protection is
  applied by VBS on OS page tables
• Do not use sections that are both writable and executable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code

Microsoft has open sourced our test tool for Memory Map and EMAT verification on
GitHub

---

SMM Mitigations refers to the WSMT ACPI table. It is present on the system but the Protection Flags field (last 4 bytes) is set to 0x00000000, so it's basically disabled.

Zitat von https://uefi.org/sites/default/files/resources/Fei%20Zhou%20-%20General%20FW%20Overview_Microsoft.pdf

---

Firmware Support for SMM Protection (WSMT table)

– Firmware vendors must re-design System Management Interrupts
(SMIs) to only read or write to an “allowed” list of regions that
include MMIO and EFI-allocated memory. It is not enough to check
that pointers are outside of SMM, they must only be within these
“safe” regions. This prevents SMM from becoming a confused
deputy which can bypass Windows flagship “Guard” features

• NOTE: Page protections that “enforce” pointers being in only “safe” regions
  are not yet required

– If, and only if, you do the above re-design, then you may
implement WSMT to assert you have completed this work. If you
implement WSMT without doing this work, you are leaving an
open attack portal

– WSMT, once implemented, confirms that the commbuffer has been
fixed for SMI processing. Details on WSMT are on MSDN

---

Well, I guess this isn't something that is going to be easy to implement into a closed source binary blob.

Zitat von Lost_N_BIOS im Beitrag #2

---

BIOS Lock >> Enable/Disable the PCH BIOS Lock Enable feature. (Required to be enabled to ensure SMM protection of flash.)

---

These all would be commonly "As noted below"
Error 0x00000002 Platform Security Specification - Boot Guard Configuration - Boot Guard disabled << Needs private key burned into PCH, not something Asus does at consumer board level
Error 0x00010001 Platform Security Specification - SPI Flash Configuration - SPI Flash not write protected << Assume this means FPRR/PRR - also usually disabled, but can be enabled if you want BIOS flashing issues
Error 0x00010002 Platform Security Specification - SPI Flash Configuration - SPI Flash descriptor overridden << Not true
Error 0x00010004 Platform Security Specification - PCH Security Configuration - SPI Controller BIOS Interface unlocked << Probably true, so you can BIOS flash
Error 0x00010008 Platform Security Specification - SPI Flash Configuration - ME FW not in Normal Working State << This may be true, if your ME FW is corrupted, not working/disabled etc
Error 0x0001000A Platform Security Specification - SPI Flash Configuration - SPI Region Access Rights Invalid << Unsure what it refers to
Error 0x00020001 Platform Security Specification - BIOS Guard Security Configuration - BIOS Guard disabled << usually disabled, but can be enabled if you want BIOS flashing issues
Error 0x00080003 Platform Security Specification - Memory Map Security Configuration - Non lockable MMIO ranges overlap other critical regions << unsure, possibly true / BIOS bug / Poor BIOS construction etc
Error 0x000A0001 Platform Security Specification - PCH Security Configuration - Thermal Configuration unlocked << I saw this when looking up SMM @ DTS SMM, didn't understand how/why ANY thermal configuration setting would have anything to do with anything you mentioned. But, this can be set if you want

NX Stuff you mentioned, you'd have to speak to Asus about that.

SMM thing you mention, if you know the module which contains those bytes I can modify for you, give me the GUID

BIOS Lock is a hidden setting, I can make visible for you if you want. Yes it should appear in what you exported, if that usually exports hidden settings as well.
Look at BIOS in AMIBCP (5.02.0023 or 5.02.0031), or extract setup module and generate IFR using universal IFR Extractor (Let me know if you need tool, or I can upload IFR txt for you too), you will find in either at Advanced >> PCH Configuration >> Security Configuration

Zitat von Lost_N_BIOS im Beitrag #4

---

Error 0x00010008 Platform Security Specification - SPI Flash Configuration - ME FW not in Normal Working State << This may be true, if your ME FW is corrupted, not working/disabled etc

---

Zitat von Lost_N_BIOS im Beitrag #4

---

Look at BIOS in AMIBCP (5.02.0023 or 5.02.0031), or extract setup module and generate IFR using universal IFR Extractor (Let me know if you need tool, or I can upload IFR txt for you too), you will find in either at Advanced >> PCH Configuration >> Security Configuration

---

ME FW looks healthy to me, but I am not ME FW expert. MEBx is not present in all ME FW, or BIOS disabled etc, so that is normal.
As long as you see healthy and no errors in verbose it should be OK, and you can see ME FW version in windows tools/BIOS main page (if shown) and not 0.0.0.0 or N/A then it's OK
ME Region is writable via ME FW update tool this is normal, this is how it should be (unless either disabled in BIOS via setting, or FW corrupted).
If ME Region is unlocked in FD, then you could also write ME region with FPT, but usually this is locked on Asus unless previous owner of that chip unlocked the FD (or you did and programmed back in)

You can set many things to user in "Already visible menus/submenus" and they should show up in BIOS, unless suppressed in setup.
If you set something to user and it doesn't appear, then set back to default and make a list of such items, I will unsuppress in setup for you, or show you how.
Then first you test unsuppressing, then if still doesn't show up you add AMIBCP user edit on top of that.

Leaving a changed thing that didn't work can cause issues later, but shouldn't brick or cause problems while you test things.
Mainly it may cause issue later when you try to do other edits, forgetting this XXX you set failed, or doing something on top of that failed setting that needs it not set etc.
So best to set back once done testing and it failed, that way you're not working on top of something that may not be needed and may cause conflict with other edit you are trying so change never happens

I have this board here, so anything you get stuck on I could test for you, but in general I know how to unlock it all for this kind of BIOS blindly so probably wouldn't need to setup the board.

Main menu sections that you cannot see (such as chipset for a general usual example), may need other edits in setup first, then may also need Access Level change in AMIBCP or an AMITSE/SetupData edit first (before, and possibly without needing an AMIBCP edit on top of that)
Sorry, I just noticed, that does not apply here, no hidden chipset. All items within the "Setup" area can be made visible though. None of this ^ applies, since it's all visible already, the main sections anyway.
So any missing submenu, such as Advanced >> PCH Config for example, you set Access Level to User at ROOT of Advanced, then test, if it doesn't show, then set back and setup edit is needed first and then tested, if still fail, then add back AMIBCP edit on top of setup edit.
This just example I picked, PCH Config may be visible, I forget. Actually, here would be better example >> Advanced >> Power & Performance << This looks to be suppressed in setup, so that would need undone first, then you see if it shows or not, if not then AMIBCP Access Level on top of setup unsupress.

If you need me to show you how to do setup edits let me know and I will give you some tool links and a more in-depth info than I'm about to give below This is done with UEFITool (V25) + Universal IFR extractor + Hex Editor.
For the last mentioned edit above here's how you would unsuppress that

Default -
Form: Advanced, FormId: 0x2719 {01 86 19 27 20 00}
0x49C96 Ref: CPU Configuration, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BB, FormId: 0x272F {0F 0F ED 00 EE 00 BB 01 00 00 FF FF 00 2F 27}
0x49CA5 Suppress If {0A 82}
0x49CA7 True {46 02} << Here's what we change, this is suppressing the submenu below it, change to 47 02, becomes false
0x49CA9 Ref: Power & Performance, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BC, FormId: 0x2731 {0F 0F 27 01 28 01 BC 01 00 00 FF FF 00 31 27}

Mod Edit -
Form: Advanced, FormId: 0x2719 {01 86 19 27 20 00}
0x49C96 Ref: CPU Configuration, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BB, FormId: 0x272F {0F 0F ED 00 EE 00 BB 01 00 00 FF FF 00 2F 27}
0x49CA5 Suppress If {0A 82}
0x49CA7 False {47 02} << Post-Edit
0x49CA9 Ref: Power & Performance, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1BC, FormId: 0x2731 {0F 0F 27 01 28 01 BC 01 00 00 FF FF 00 31 27}