There is "Allow local user to change UEFI settings" setting in DFCI config profile, but these is no document to describe which UEFI variable save this setting value.

For example: I can see "CPU and IO virtualization" description in here or DfciSettings.h, so I know "Dfci.CpuAndIoVirtualization.Enable" UEFI variable save this setting value.

Group settings provider may return ENABLE_INCONSISTENT, but ProviderValueAsAscii() in SettingsManagerProvider.c only process Enabled and Disabled values.
Enhance ProviderValueAsAscii() to return "Inconsistent" string for ENABLE_INCONSISTENT value.

Example:
if (v == ENABLE_TRUE) {
AsciiStrCpyS(Value, ENABLED_STRING_SIZE , "Enabled");
}
else if (v == ENABLE_INCONSISTENT) {
AsciiStrCpyS(Value, ENABLED_STRING_SIZE , "Inconsistent");
}
else {
AsciiStrCpyS(Value, ENABLED_STRING_SIZE, "Disabled");
}

NuGet feeds fail for the following during compile:

• NASM
• IASL
• EDK2 BaseTools

After addition of VersionInfo feature to HelloWorld, I would expect Windows Explorer > Properties > Details tab to show version information (note, you must rename HelloWorld.efi to HelloWorld_.EXE_ for this Explorer to perform this. Compare with \Windows\Boot\EFI\bootmgfw.efi (after renaming to .EXE). FileVer.exe reproduces this issue as well.

You can see perhaps the worst offender here:
https://github.com/microsoft/mu_basecore/blob/c4d0d1130454b3e5051bb601c707234e3a91713a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c#L2185

But the idea is to wrap each of these tests in a descriptive macro or function so that it's more readable AND we don't have to change multiple places if we ever change the logic (like adding a new PCD).

Example: WillVarExceedHwErrQuota( VarSize );, or something like that.

In most of the Mu repos, the pip-requirements is pinning edk2 py extentions to version 12...

edk2-pytool-extensions==0.12.*

This should probably move forward

In the documentation page Documentation Sample... the mention of mkdocs-macros refers to the github site.

As the maintainer of that project, I just wanted to let you know that there is now a very detailed documentation on mkdocs-macros available on readthedocs. You may want the refer to it, especially since there is information that specifically applies to large projects.

They also are calling out VS2017 when our build actually uses vs2019
There is no user clickable link to see the builds.

On this PR, microsoft/mu_plus#22 some comments were made that weren't addressed but it was agreed they would be addressed in a future PR.

Mike K:
The use of the term 'Shared' 'SHARED' should be removed from all types, variables, functions, library, and module names. The private protocol/ppi/smm protocol are an abstraction for the CryptoPkg/Include/BaseCryptLib.h, so the name of the protocol and the modules should make this relationship obvious. Perhaps using the names listed below for includes. The use of 'Base' in the name of the library class is unfortunate. The term 'Base' in the name of a lib instance implies module compatibility with all module types. Private/Protocol/BaseCrypt.h EDKII_BASE_CRYPT_PROTOCOL_GUID EDKII_BASE_CRYPT_PROTOCOL gEdkiiBaseCryptProtocolGuid Private/Protocol/SmmBaseCrypt.h EDKII_SMM_BASE_CRYPT_PROTOCOL_GUID EDKII_SMM_BASE_CRYPT_PROTOCOL gEdkiiSmmBaseCryptProtocolGuid Private/Ppi/BaseCrypt.h EDKII_PEI_BASE_CRYPT_PROTOCOL_GUID EDKII_PEI_BASE_CRYPT_PROTOCOL gEdkiiPeiBaseCryptProtocolGuid Library Instances (not using keyword 'Base') DxeCryptLibOnProtocol SmmCryptLibOnProtocol PeiCryptLibOnPpi Drivers CryptDxe CryptSmm CryptPei We could define a few feature flag PCDs that select between a NULL value and function pointer value when filling in the structure of crypto services. This can reduce the number of INFs and C files. Can we also consider making this a pull request against CryptoPkg in mu_tiano_plus?

There was also the issue of moving the publishing tools outside the code itself

Some test updates were missed in the 2102 integration and had to be fixed after the fact.

Hello,
it was reported by one of our customers, that incremental build does not work. We tracked it down to the GNUmakefile
RELEASE_GCC5/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/GNUmakefile
where a dependency is missing: instead of:

$(FFS_OUTPUT_DIR)/$(MODULE_GUID).efi :
test -f $(OUTPUT_DIR)/ArmPlatformPrePiUniCore.efi && $(CP) $(OUTPUT_DIR)/ArmPlatformPrePiUniCore.efi $(FFS_OUTPUT_DIR)/$(MODULE_GUID).efi

the incremental build works fine with:

$(FFS_OUTPUT_DIR)/$(MODULE_GUID).efi : $(OUTPUT_DIR)/ArmPlatformPrePiUniCore.efi
test -f $(OUTPUT_DIR)/ArmPlatformPrePiUniCore.efi && $(CP) $(OUTPUT_DIR)/ArmPlatformPrePiUniCore.efi $(FFS_OUTPUT_DIR)/$(MODULE_GUID).efi

It means that copy will happen not only if the destination file is missing, but also if the source file (=makefile rule dependency) has changed. (Possibly similar issue for *.map file above in the same GNUmakefile).
I can provide more details if needed, and can debug the whole GNUmakefile generation process in mu_basecore/BaseTools/Source/Python. But it is too big to debug for external person so hopefully somebody can look into it.
Can this be fixed?

Sometimes a Package needs more overview documentation than reasonably should be in 1 markdown file in the root folder. Add support for a Docs subdirectory to contain this Package-wide documentation that is promoted in the twiddle tree, then demote the individual component docs to a subfolder in the twiddle tree.

Is there any testing available for the Mu DFCI implementation for a BIOS Vendor?

I'm not sure if it's my fault or there's a bug in build system but I have problem in building mu for qemu. I followed guides and even I did more investigations by checking Azure Pipeline yaml files but I can't find solution to this error:

Building using this command on debian:
stuart_build -c Platforms/QemuQ35Pkg/PlatformBuild.py TOOL_CHAIN_TAG=GCC5 QEMU_HEADLESS=TRUE TARGET=RELEASE -a IA32,X64

Also I think it's nice to have prebuilt binaries for qemu in Releases section of github.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Update install components to include Microsoft.VisualStudio.Component.Windows10SDK.17763

Many of the CI DSC's lack ARM and AARCH64 in their SUPPORTED_ARCHITECTURES. Lets add these architectures where possible to get build and host unit test coverage.

Examples:

FmpDevicePkg\Test\FmpDeviceHostPkgTest.dsc:15:  SUPPORTED_ARCHITECTURES = IA32|X64
SourceLevelDebugPkg\SourceLevelDebugPkg.dsc:22:  SUPPORTED_ARCHITECTURES        = IA32|X64

Many of the CI DSC's lack ARM and AARCH64 in their SUPPORTED_ARCHITECTURES. Lets add these architectures where possible to get build and host unit test coverage.

Examples:
AdvLoggerPkg\AdvLoggerPkg.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
DfciPkg\DfciPkg.dsc:16: SUPPORTED_ARCHITECTURES = IA32|X64
MfciPkg\MfciPkg.dsc:15: SUPPORTED_ARCHITECTURES = IA32|X64
MsCorePkg\MsCorePkg.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
MsGraphicsPkg\MsGraphicsPkg.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
MsWheaPkg\MsWheaPkg.dsc:16: SUPPORTED_ARCHITECTURES = IA32|X64
MsWheaPkg\Test\MsWheaPkgHostTest.dsc:15: SUPPORTED_ARCHITECTURES = IA32|X64
PcBdsPkg\PcBdsPkg.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
XmlSupportPkg\Test\XmlSupportPkgHostTest.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
XmlSupportPkg\XmlSupportPkg.dsc:14: SUPPORTED_ARCHITECTURES = IA32|X64
ZeroTouchPkg\ZeroTouchPkg.dsc:15: SUPPORTED_ARCHITECTURES = IA32|X64

coreboot open source BIOS is already there and supports a lot of real motherboards. https://coreboot.org/status/board-status.html Instead of reinventing the wheel as "mu" it would have been more efficient to join our forces. I am addressing those 25 people who thought this repository is worthy of forking and would like to know their opinions : @Abhimanyu121 , @Shreya-khandelwal , @abhiraj963 , @adi23arora , @akshay196 , @c-stauffer , @DalavanCloud , @FY1043031060 , @gauravano , @gus33000 , @Justinha , @Man-Jain , @mknutsen , @moulikcipherX , @netroby , @panwalas, @pristineVedansh , @ramyhhh , @ritwik787 , @sanchittanwar7 , @sk9331657 , @skshetry , @StefMa , @uzerjamal , @vbhaip

I am led to understand from your documentation that this is basically the upstream development of the MS Surface UEFI, so I'll repeat here the question and issue that I raised on MS Answers forums here: https://answers.microsoft.com/en-us/surface/forum/all/surface-go-boot-from-usb/4668ec45-af97-4766-9130-53ff75e2e0e2

Can anyone explain to me what are the technical reasons that Surface Go (eMMC version) UEFI refuses to directly boot any UEFI bootable USB other than that with a Windows OS on it?

The issue is as follows: assume you want to install a GNU/Linux OS on your Surface Go. You create a bootable USB with Rufus, you insert it in the USB-C slot and you turn on your system while holding down the volume-down button to toggle the alternate-boot sequence (that's of course enabled in your firmware). But this doesn't seem to boot anything other than whatever OS is already installed on your system, not the LiveUSB.

You then boot into your UEFI settings and change the boot order manually, setting the USB on top. You boot up, but - alas! - USB still won't boot. Finally you boot up your Windows and go to advanced restart. From there you try to boot from USB, and yet again if you try selecting the option to boot from EFI USB the system will simply reboot into the OS already on your Surface.

You do the advanced restart again but this time instead of EFI USB you select the weird named option Linpus Lite - and finally you are able to boot from your GNU/Linux USB (Which is any distro - I tried with Ubuntu, Fedora and PopOS!).

The above jumping though hoops demonstrates that Surface Go doesn't boot non-Windows bootable USBs directly for some reason. I wanna know the technical reason why. By the way, this has got nothing to do with Secure Boot as it can be turned on or off, it doesn't matter.

Upon further tinkering, with efibootmgr I was able to ascertain that whenever a non-Windows bootable USB gets inserted, there appears a new efi boot entry named 'Linpus Lite', but when a Windows bootable USB gets inserted, no new boot entry appears; instead the always-present 'EFI USB drive' boot entry is the Win bootable USB entry. Why is that?

This is a request for enhancements to the debug output included in x86 CPU exception handler debug prints.

Two enhancements are requested:

1. For MachineCheck exceptions, add prints for the architectural Machine Check MSRs (MCi_STATUS, MCi_ADDR, etc.)
2. Add a dump of the pre-exception stack for exceptions where the stack pointer is valid.

Files here need BSD license and copyright added.

https://github.com/Microsoft/mu_pip_python_library/tree/master/MuPythonLibrary/Uefi/Capsule

I committed pull request #60 because we've always had this issue (i.e. load() was always unsafe). We should revisit to determine if we care and how we might fix this if we do.

The Platform Build --UPDATE --SETUP commands try to checkout and update the submodules in the repository. If it encounters an error (eg. you haven't pushed a commit to the submodule, the server is down, etc.) the script continues and returns a successful exit code.

This causes issues with automated build systems as the build will continue and try to build the project, and fail much later because the submodule was never actually checked out.

repo:mu_pip_environment

Add meta tag so that the edit link doesn't show up. Edit link takes you to a 404.

If IS_OWNER_IDENTITY_ENROLLED(IdMask) returns FALSE in CheckForAuthenticationProtocol(), UEFI variable "_SPP" will be updated every POST because Var->SavedOn is different.

Side effect: Every POST, it makes available size in Flash Part variable region less. It will trigger variable reclaim process at someone POST and makes POST time increase. Basically, if system state/configuration is not changed, available size in Flash Part variable region should be the same.

Suggestion: In CheckForAuthenticationProtocol(), it should not modify "_SPP" if OWNER_IDENTITY_ENROLLED state is not changed.

Fails to build with error:

MdeModulePkg\Logo\Logo.c(34): error C2065: 'IMG_LOGO': undeclared identifier
INFO - MdeModulePkg\Logo\Logo.c(33): error C2099: initializer is not a constant
INFO - NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\cl.exe"' : return code '0x2'

While building the Mu_plus, I noticed that the Conf folder gets generated for all the tools settings (like VS2019 or GCC5). I think since this is a folder which gets generated on build, we should include this in the .gitignore file.

Please feel free to add any other opinions over this.

Standardize a telemetry path on ASSERTs that will enable a telemetry event (with some sort of useful identifier) for any ASSERT that happens on a production system (where ASSERTs don't halt the machine).

The CI DSC lacks ARM and AARCH64 in SUPPORTED_ARCHITECTURES. Lets add these architectures where possible to get build and host unit test coverage.

Example:
OemPkg\OemPkg.dsc:15: SUPPORTED_ARCHITECTURES = IA32|X64

Hi, I am trying to build mu_plus/MsGraphicsPkg into OvmfPkg and see how it goes in QEMU. But I run into an issue that in UiDisplayMenu, the PCD CurrentPointerState is always zero and it looks like the pointer should be pointing to something in the memory and should not be zero. Is there any missing library/Dxe driver missing in MsGraphicsPkg?

EFI_STATUS
UiDisplayMenu (IN FORM_DISPLAY_ENGINE_FORM *FormData) {
EFI_STATUS Status = EFI_SUCCESS;
DISPLAY_ENGINE_SHARED_STATE *MasterFrameSharedState = (DISPLAY_ENGINE_SHARED_STATE *)(UINTN)PcdGet64(PcdCurrentPointerState);

Peter

Need documentation of how it should work and the user configurable variables
Need to resolve the filesystem writing issue and/or memory corruption that is happening

How we modify or specify a UEFI logo, and the steps are friendly.

https://microsoft.github.io/mu/CodeDevelopment/prerequisites/#windows-subsystem-for-linux-wsl says "Coming soon". Should be completed. @mknutsen ?

This logic doesn't work on linux
https://github.com/microsoft/mu_basecore/blob/release/202008/BaseTools/Plugin/OverrideValidation/OverrideValidation.py#L525

    # Needs to strip os.sep is to take care of the root path case
    # For a folder, this will do nothing on a formatted abspath
    # For a drive root, this will rip off the os.sep
    if not os.path.normcase(Paths.ModulePath).startswith(os.path.normcase(Paths.WorkSpace.strip(os.sep)) + os.sep):
        raise RuntimeError("Module is not within specified Workspace.")

A better solution would be to use python os.path.commonpath.

if len(os.path.commonpath([Paths.ModulePath, Paths.WorkSpace])) != len(Paths.WorkSpace):

probably needs more testing before making the change.

in twitter a Microsoft Engineer have build the UEFIPayload with secure boot for coreboot with TPM Work
Sorry for this dummie issue but how to compile?

Currently, all PR's to microsoft/mu will fail as the azure pipeline used to verify PR's to the mu docs repo is using an out of date node version (Required 12.13.x, using 10.x)

I've developed some UEFI firmware with Tianocore/EDK2. I found that mu is another platform for developing UEFI firmware. Is there any tutorial on how I should start developing UEFI firmware with mu?

Placeholder, more details to follow...

Over the past couple days I have seen a lot of questions and misunderstandings that Project Mu should try to clarify.

• Why UEFI?
• Can I replace the firmware on my product with this? (Surface device, etc)
• What can i build with this?
• Who is this project useful for (target audience)?

There is unnecessary GUID value gEfiEventPreReadyToBootGuid included in DfciMenu.inf and DfciSARecovery.inf.
It can remove it without impact original behavior.

There are 2 copies of UefiVariablesSupportLib.py in MU_PLUS.

1. UefiTestingPkg copy
2. DfciPkg copy

Consider consolidation or move to a PyTools Library?

If DSC has something like:

!include $(PATH_FROM_NUGET_EXTDEP)/foo.inc

then the BMP plugin will fail with:

ERROR - Invalid file path C:\src\devices$(PATH_FROM_NUGET_EXTDEP)/foo.inc

PcAtChipsetPkg\IsaAcpiDxe\IsaAcpi.inf and PcAtChipsetPkg/8254TimerDxe/8254Timer.inf both require the IntelFramework*Pkg. In an effort to reduce code deprecated code these have been removed from Project Mu. Need to resolve.

For now theses two modules have been removed from DSC and added to the ignore for dsccheck

This PR adds pipeline files that are a little verbose:
microsoft/mu_basecore#39

Optimize these.