Date   

Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

mick21@...
 

Sure, currently I add the adjusted libraries like this:

MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.sanitizer.inf
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.sanitizer.inf
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.sanitizer.inf
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.sanitizer.inf
...

Then I copy all the original library.inf to library.sanitizer.inf and then append my [BuildOptions] section, depending on the instrumentation. You can then check the static_library_files.lst in the build directory for your driver to see if all libraries are replaced with the sanitized ones. This is only "one layer" though, I'm not sure whether this matters for my implementation, but libraries can use other libraries, which should also be instrumented, that is not the case with this.


Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

Andrew Fish
 

Feel free to post examples if it would help others.

On Apr 13, 2021, at 12:34 PM, mick21@live.nl wrote:

Hi Andrew,

Apologies for the late reply!

ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.sanitize.inf
}
I think I have it working now, I'm overwriting all of the used libraries with the *.sanitizer.inf alternative, like you said, and add the BuildOptions there. I'm not sure whether this is the best option, but it is cleaner than what I had in mind and most importantly: it works :).

Thank you for your help, I really appreciate it.

Kind regards,

Mick





Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

mick21@...
 

Hi Andrew,

Apologies for the late reply!

ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.sanitize.inf
}
I think I have it working now, I'm overwriting all of the used libraries with the *.sanitizer.inf alternative, like you said, and add the BuildOptions there. I'm not sure whether this is the best option, but it is cleaner than what I had in mind and most importantly: it works :).

Thank you for your help, I really appreciate it.

Kind regards,

Mick


GSoC (Google Summer of Code) Application Deadline Approaching

Nate DeSimone
 

Hi Everyone,

Quick heads up, the GSoC application deadline is 17 hours from now. I still see 5 applications in draft status. Google is very strict about their deadlines, even if you are 1 minute late they won't accept it. Please make sure that all applications are submitted and marked as final before 11am Pacific Time tomorrow.

Thank you everyone for all the work you have done on your GSoC applications thus far! All of you had a lot of great questions and I'm looking forward to this upcoming summer!

With Best Regards,
Nate


GSoC proposal for MinPlatform Qemu Support

KAAIRA GUPTA
 

Hello all,

I have submitted a draft proposal, a google doc with commenting access,
through GSoC website. Please suggest any changes or improvements so that I
can improve on the proposal.
Though I have added a rough timeline, I wanted to be more precise and add a
week-wise timeline to make it more accountable, but I found it a bit
difficult to break this into small tasks as I haven't played around with
the code of OVMF or any OpenBoardPkg yet. I have read about their
architecture.
Can you please help me with some pointers, or guide me to any skeletal
code/ simple application/guide which can help me to break down the tasks a
bit more?

Thanks,
Kaaira Gupta


Doubt in MinPlatform QemuOpenBoardPkg task

Kaaira Gupta <kaaira7319@...>
 

The second part of this task talks about fsp sdk and its use for testing FSP integration. I wanted to confirm if I understood this part correctly.
From what I understand, we will have to work on this FSPSDK such that it can generate FSP binaries with the OpenBoardPkg we create which can be used for silicon initialisation. Is this correct?

Another question,
Has there been any similar adaptation work to MinPlatform Architecture earlier for any other Processor/SoC so that I can get some pointers from those patches about the workflow? This would help me define a timeline for the proposal and also make the work a lot clearer.

Thanks,
Kaaira


Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

Andrew Fish
 

On Apr 10, 2021, at 1:31 PM, mick21@live.nl wrote:

Hi Andrew,

I'm trying to enable MemorySanitizer/AddressSanitizer for SMM drivers in TianoCore, so I will use it for dynamic analysis. To do this, I want to use LLVM to instrument the SMM drivers when they are built. but since the libraries are built separately and later linked with the compiled source files of the corresponding .inf file, these library files will not be instrumented.

I can now instrument the source files, for instance with "-fsanitize=memory", but the library code (LibraryClasses) for VariableSmm.efi will not be instrumented, as the library code is not recompiled for VariableSmm.efi, but only compiled once at the start and then linked repeatedly with the various drivers (this is what I assume). So, ideally, I would like to recompile the library code for VariableSmm.efi with "-fsanitize=memory", but only do this for VariableSmm.efi, not for other UEFI drivers.

There is the concept of override of things per single INF file entry in the DSC [1]. This syntax include <BuildOptions> and pointing at alternate libraries for just those drivers. If you have common libs that you need 2
flavors of you could fork a copy and point to those from the per driver entries in the DSC, for the drivers that you care about
I think this is what I need, but from your example, it seems that a library is not replaced, it is only appended (UefiShellNetwork2CommandsLib.inf is either included or not) or does the code you provide overwrite the whole LibraryClasses section for a specific driver? I think I'm misunderstanding something, but what you say seems to be what I'm looking for.

NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
!endif
To be more specific, here either UefiShellNetwork2CommandsLib.inf is included or not, UefiShellNetwork2CommandsLib.inf does not overwrite a certain library, or does the overwriting of libraries (to use either library A or library B for the same functionality) happen somewhere else?

I hope I explained my problem clearly, if not, please say so! I also appreciate the brainstorming, it allows me to learn more about the project :).
Mick,

Thanks that is a clear explanation.

Sorry I picked a bad example as a NULL library class means force link the library even if it is not listed in the drivers INF file. Examples of NULL would be a compiler intrinsic lib, or a library (that calls another EFI or lib API) to register services.

You should be able to do something like

ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.sanitize.inf
}

So basically in every library instance you car about you clone the INF file to the *.sanitize.inf version and flip the compiler flags. Then you can point sanitized drivers at the sanitized lib. You can also use the NULL library if you need to inject some intrinsics for the sanitizer runtime (unless you just had it compile traps).

If you look in the Build output you will notice there are 2 levels that often have the same, or similar, name [1], I think you will find the 2nd name is the INF file name so it should be possible

[1] Build//OvmfX64/DEBUG_XCODE5/X64/OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib/


Thanks,

Andrew Fish

Kind regards,

Mick





Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

mick21@...
 

Hi Andrew,

I'm trying to enable MemorySanitizer/AddressSanitizer for SMM drivers in TianoCore, so I will use it for dynamic analysis. To do this, I want to use LLVM to instrument the SMM drivers when they are built. but since the libraries are built separately and later linked with the compiled source files of the corresponding .inf file, these library files will not be instrumented.

I can now instrument the source files, for instance with "-fsanitize=memory", but the library code (LibraryClasses) for VariableSmm.efi will not be instrumented, as the library code is not recompiled for VariableSmm.efi, but only compiled once at the start and then linked repeatedly with the various drivers (this is what I assume). So, ideally, I would like to recompile the library code for VariableSmm.efi with "-fsanitize=memory", but only do this for VariableSmm.efi, not for other UEFI drivers.

There is the concept of override of things per single INF file entry in the DSC [1]. This syntax include <BuildOptions> and pointing at alternate libraries for just those drivers. If you have common libs that you need 2
flavors of you could fork a copy and point to those from the per driver entries in the DSC, for the drivers that you care about
I think this is what I need, but from your example, it seems that a library is not replaced, it is only appended (UefiShellNetwork2CommandsLib.inf is either included or not) or does the code you provide overwrite the whole LibraryClasses section for a specific driver? I think I'm misunderstanding something, but what you say seems to be what I'm looking for.

NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
!endif
To be more specific, here either UefiShellNetwork2CommandsLib.inf is included or not, UefiShellNetwork2CommandsLib.inf does not overwrite a certain library, or does the overwriting of libraries (to use either library A or library B for the same functionality) happen somewhere else?

I hope I explained my problem clearly, if not, please say so! I also appreciate the brainstorming, it allows me to learn more about the project :).

Kind regards,

Mick


Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

Andrew Fish
 

Mick,

Are you trying to do runtime or static analysis? That would help guide my answers.

What your are are doing in the INF file you can generally do in the DSC file too per driver. There is the concept of override of things per single INF file entry in the DSC [1]. This syntax include <BuildOptions> and pointing at alternate libraries for just those drivers. If you have common libs that you need 2 flavors of you could fork a copy and point to those from the per driver entries in the DSC, for the drivers that you care about. Conceptually you could fork a DSC file, or !if def your DSC file to support multiple modes (normal and analysis) of build.

We added the overrides to the DSC file so your platform could override things without having to override the driver source (or INF) that you might have gotten from a vendor. Thinking act would be easier to maintain over the long run, and easier to merge changes from updates to the vendor code.


[1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L937

ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
!endif
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf

<PcdsFixedAtBuild>
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}

Anyway always happy to help folks brainstorm on the easiest way to do things. Sometimes with the edk2 it is not always obvious….

Thanks,

Andrew Fish

On Apr 10, 2021, at 5:19 AM, mick21@live.nl wrote:

Hi Andrew,

Thank you for your reply, I didn't know this report option existed!

If you add the --report-file=REPORTFILE to the build command when you compile it will generate a report about your build. I think the info in this report can help you out.
I have looked at the output of the report file, though, it did provide some clarity on what libraries are included, it seemed to match with the "OUTPUT/static_library_files.lst" library listing that is created when a driver is built.

I found that I can change the file paths in the GNUmakefile of a UEFI driver (for example Build/OvmfX64/DEBUG_CLANGPDB/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm/GNUmakefile). By changing the STATIC_LIBRARY_FILES or CC_FLAGS variables for a specific UEFI driver or library, I am maybe able to compile certain drivers with other library code than others, as the build script doesn't seem to overwrite the GNUmakefile file when I change it. I hope this will work, despite it being not so elegant.

Thank you,

Mick


Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

mick21@...
 

Hi Andrew,

Thank you for your reply, I didn't know this report option existed!

If you add the --report-file=REPORTFILE to the build command when you compile it will generate a report about your build. I think the info in this report can help you out.
I have looked at the output of the report file, though, it did provide some clarity on what libraries are included, it seemed to match with the "OUTPUT/static_library_files.lst" library listing that is created when a driver is built.

I found that I can change the file paths in the GNUmakefile of a UEFI driver (for example Build/OvmfX64/DEBUG_CLANGPDB/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm/GNUmakefile). By changing the STATIC_LIBRARY_FILES or CC_FLAGS variables for a specific UEFI driver or library, I am maybe able to compile certain drivers with other library code than others, as the build script doesn't seem to overwrite the GNUmakefile file when I change it. I hope this will work, despite it being not so elegant.

Thank you,

Mick


Re: Doubt in MinPlatform QemuOpenBoardPkg task

Nate DeSimone
 

Hi Kaaira,

Great questions! So I’ll start out describing what the FSP is and why we built it. The FSP (Firmware Support Package) is a mechanism Intel developed to distribute chipset initialization code that must be run during bootup in a binary format. Historically there were multiple different BIOS implementations from different IBVs (Independent BIOS Vendor, companies like AMI, Phoenix, Insyde, etc.) and they had some fundamental incompatibilities that made it impossible to run C code provided as a binary. For example, different methods for initialization of the stack. Due to this, historically we only provided chipset initialization in source code format under NDA. However, this strategy limited the companies that were capable of building BIOS implementations to those that could obtain NDAs, which eventually became too limiting.

So, we needed a binary executable format that would work with many different BIOS implementations while still allowing the chipset initialization code to be written in a higher level language than assembly. The first attempt at this was UEFI actually, which created a very generic binary format that would work not only for chipset initialization, but other multi-vendor compatibility concerns like expansion cards and operating systems. UEFI has become very successful in the general purpose computing (aka PC) industry, and it is widely used today to make PCIe add-in cards (graphics cards for example) work in PC systems from different vendors. It is also very successful at making PCs capable of booting an operating system from any software vendor.

But UEFI turned out to be overkill for embedded/Internet of Things designs. Most embedded designs generally only boot one OS (VxWorks, QNX, heavily customized Linux, etc.) and don’t support expansion cards. Moreover, they are usually designed by companies with small engineering departments that had difficulty working with UEFI due to its large and rich feature set. So we went back and built another mechanism for distributing chipset initialization code in a binary executable format, and kept it focused to just that use case this time. The result of that was FSP. Initially, FSP was only used by embedded customers, but its usage has grown over the years and now a lot of PCs use it for chipset initialization as well. The earlier versions of the FSP specifications (v1.0-v2.0) were designed primarily for use with non-UEFI firmware implementations. For example https://slimbootloader.github.io/, which is a sister project to TianoCore developed by Intel’s Internet of Things department. Due to the increasing interest in using the FSP on PCs, in the FSP v2.1 specification we made the FSP operate in two different “modes”: API Mode and Dispatch Mode. API mode is backwards compatible with the FSP v2.0 specification and is intended for use on non-UEFI firmware implementations. Dispatch mode is conversely designed to for use with UEFI firmware implementations and works very differently.

So, the basic idea is that now that the FSP is widely used on PCs, it makes sense to include an FSP in the new QemuOpenBoardPkg so that it closely mirrors what a real UEFI firmware/BIOS implementation looks like. The Internet of Things department at Intel (the same guys who wrote Slim Bootloader) has created a dummy FSP for QEmu and posted it here: https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 Since it is just a dummy FSP, they released it open source instead of binary only like most FSPs. However, since Slim Bootloader does not support dispatch mode they only implemented API mode. Hence that QEmu FSP only goes up to the FSP v2.0 specification. That is where “upgrade QEmu FSP to v2.2” come in. Basically the proposal is to implement dispatch mode in the QEmu FSP and then integrate it into QemuOpenBoardPkg, so that way we have an open source emulated example that is much closer to what the real UEFI implementation on modern PCs actually looks like.

Yes there are been several MinPlatform Architecture platform implementations available right now:

CometlakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/CometlakeOpenBoardPkg
KabylakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg
TigerlakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/TigerlakeOpenBoardPkg
WhiskeylakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/WhiskeylakeOpenBoardPkg

Out of all of them, I'd say that KabylakeOpenBoardPkg is the best example.

Hope that helps. Let me know if you have more questions!

Best Regards,
Nate

From: Kaaira Gupta <kaaira7319@gmail.com>
Sent: Friday, April 9, 2021 3:14 PM
To: discuss@edk2.groups.io; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Subject: Doubt in MinPlatform QemuOpenBoardPkg task

The second part of this task talks about fsp sdk and its use for testing FSP integration. I wanted to confirm if I understood this part correctly.
From what I understand, we will have to work on this FSPSDK such that it can generate FSP binaries with the OpenBoardPkg we create which can be used for silicon initialisation. Is this correct?

Another question,
Has there been any similar adaptation work to MinPlatform Architecture earlier for any other Processor/SoC so that I can get some pointers from those patches about the workflow? This would help me define a timeline for the proposal and also make the work a lot clearer.

Thanks,
Kaaira


Re: Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

Andrew Fish
 

On Apr 9, 2021, at 7:55 AM, mick21@live.nl wrote:

Hello everyone,

I hope this is the right place to ask this, I haven't been able to find answers online or in the edk2 wiki.

I'm trying to apply sanitizers to system management mode (SMM) drivers (VariableSmm.efi, for instance) in edk2, but I'm running into the problem that at the moment I am unable to instrument the library code that later gets linked with (the library code referenced in the .inf file). At the moment, when instrumenting a driver, for example VariableSmm.inf, I'm providing compilation flags via the [BuildOptions] section and then append the flags to the *_*_*_CC_FLAGS variable. This allows me to instrument the source files present under the [Sources] section. However, the library code under the [LibraryClasses] section that later gets linked to create the eventual .efi file is not instrumented, as it is already compiled separately before.

So the problem I have is that for certain UEFI drivers I want to instrument the library code, but for others not. So to clarify, for UEFI driver A, I want the library code compiled with "-fsanitize=memory", while for other UEFI drivers, I want to use the default compiled library code. I haven't found a clean way to do this in the building process. Is there anyone who has tips regarding this problem? I hope the problem is clear, if not, please indicate so.
Mick,

If you add the --report-file=REPORTFILE to the build command when you compile it will generate a report about your build. I think the info in this report can help you out.
1) It ill show all the library instances that map to the [LibraryClassess] list in the driver INF file for every driver.
a) This shows you the mapping of the [LibraryClassess] to specific library instances.
b) This includes the list of [LibraryClasses] from the dependent library instances [LibraryClasses] section that got indirectly linked to resolve dependencies for the libraries, so the full set.
c) This list also shows you the library constructors and the order they are called.
2) The report file also will show you the per compiler CC_FLAGS and given what you are doing this may be helpful.

The makefiles are generated and live with the drivers build output under the Build dir so somethings looking at the generated makefiles is helpful. I generally find the log file is a lot easier than looking into the makefiles.

[1] $ . edksetup.sh
Loading previous configuration from /Volumes/Case/edk2-github/Conf/BuildEnv.sh
WORKSPACE: /Volumes/Case/edk2-github
EDK_TOOLS_PATH: /Volumes/Case/edk2-github/BaseTools
CONF_PATH: /Volumes/Case/edk2-github/Conf
$ build --help
Usage: build.exe [options] [all|fds|genc|genmake|clean|cleanall|cleanlib|modules|libraries|run]

Copyright (c) 2007 - 2018, Intel Corporation All rights reserved.

Options:
--version show program's version number and exit
-h, --help show this help message and exit
-a TARGETARCH, --arch=TARGETARCH
ARCHS is one of list: IA32, X64, ARM, AARCH64, RISCV64
or EBC, which overrides target.txt's TARGET_ARCH
definition. To specify more archs, please repeat this
option.
-p PLATFORMFILE, --platform=PLATFORMFILE
Build the platform specified by the DSC file name
argument, overriding target.txt's ACTIVE_PLATFORM
definition.
-m MODULEFILE, --module=MODULEFILE
Build the module specified by the INF file name
argument.
-b BUILDTARGET, --buildtarget=BUILDTARGET
Using the TARGET to build the platform, overriding
target.txt's TARGET definition.
-t TOOLCHAIN, --tagname=TOOLCHAIN
Using the Tool Chain Tagname to build the platform,
overriding target.txt's TOOL_CHAIN_TAG definition.
-x SKUID, --sku-id=SKUID
Using this name of SKU ID to build the platform,
overriding SKUID_IDENTIFIER in DSC file.
-n THREADNUMBER Build the platform using multi-threaded compiler. The
value overrides target.txt's
MAX_CONCURRENT_THREAD_NUMBER. When value is set to 0,
tool automatically detect number of processor threads,
set value to 1 means disable multi-thread build, and
set value to more than 1 means user specify the
threads number to build.
-f FDFFILE, --fdf=FDFFILE
The name of the FDF file to use, which overrides the
setting in the DSC file.
-r ROMIMAGE, --rom-image=ROMIMAGE
The name of FD to be generated. The name must be from
[FD] section in FDF file.
-i FVIMAGE, --fv-image=FVIMAGE
The name of FV to be generated. The name must be from
[FV] section in FDF file.
-C CAPNAME, --capsule-image=CAPNAME
The name of Capsule to be generated. The name must be
from [Capsule] section in FDF file.
-u, --skip-autogen Skip AutoGen step.
-e, --re-parse Re-parse all meta-data files.
-c, --case-insensitive
Don't check case of file name.
-w, --warning-as-error
Treat warning in tools as error.
-j LOGFILE, --log=LOGFILE
Put log in specified file as well as on console.
-s, --silent Make use of silent mode of (n)make.
-q, --quiet Disable all messages except FATAL ERRORS.
-v, --verbose Turn on verbose output with informational messages
printed, including library instances selected, final
dependency expression, and warning messages, etc.
-d DEBUG, --debug=DEBUG
Enable debug messages at specified level.
-D MACROS, --define=MACROS
Macro: "Name [= Value]".
-y REPORTFILE, --report-file=REPORTFILE
Create/overwrite the report to the specified filename.
-Y REPORTTYPE, --report-type=REPORTTYPE
Flags that control the type of build report to
generate. Must be one of: [PCD, LIBRARY, FLASH,
DEPEX, BUILD_FLAGS, FIXED_ADDRESS, HASH,
EXECUTION_ORDER]. To specify more than one flag,
repeat this option on the command line and the default
flag set is [PCD, LIBRARY, FLASH, DEPEX, HASH,
BUILD_FLAGS, FIXED_ADDRESS]
-F FLAG, --flag=FLAG Specify the specific option to parse EDK UNI file.
Must be one of: [-c, -s]. -c is for EDK framework UNI
file, and -s is for EDK UEFI UNI file. This option can
also be specified by setting *_*_*_BUILD_FLAGS in
[BuildOptions] section of platform DSC. If they are
both specified, this value will override the setting
in [BuildOptions] section of platform DSC.
-N, --no-cache Disable build cache mechanism
--conf=CONFDIRECTORY Specify the customized Conf directory.
--check-usage Check usage content of entries listed in INF file.
--ignore-sources Focus to a binary build and ignore all source files
--pcd=OPTIONPCD Set PCD value by command line. Format: "PcdName=Value"
-l COMMANDLENGTH, --cmd-len=COMMANDLENGTH
Specify the maximum line length of build command.
Default is 4096.
--hash Enable hash-based caching during build process.
--binary-destination=BINCACHEDEST
Generate a cache of binary files in the specified
directory.
--binary-source=BINCACHESOURCE
Consume a cache of binary files from the specified
directory.
--genfds-multi-thread
Enable GenFds multi thread to generate ffs file.
--no-genfds-multi-thread
Disable GenFds multi thread to generate ffs file.
--disable-include-path-check
Disable the include path check for outside of package.


Thanks,

Andrew Fish

Kind regards,
Mick





Having problems when trying to instrument all code of a specific UEFI driver (including the library code)

mick21@...
 

Hello everyone,

I hope this is the right place to ask this, I haven't been able to find answers online or in the edk2 wiki.

I'm trying to apply sanitizers to system management mode (SMM) drivers (VariableSmm.efi, for instance) in edk2, but I'm running into the problem that at the moment I am unable to instrument the library code that later gets linked with (the library code referenced in the .inf file). At the moment, when instrumenting a driver, for example VariableSmm.inf, I'm providing compilation flags via the [BuildOptions] section and then append the flags to the *_*_*_CC_FLAGS variable. This allows me to instrument the source files present under the [Sources] section. However, the library code under the [LibraryClasses] section that later gets linked to create the eventual .efi file is not instrumented, as it is already compiled separately before.

So the problem I have is that for certain UEFI drivers I want to instrument the library code, but for others not. So to clarify, for UEFI driver A, I want the library code compiled with "-fsanitize=memory", while for other UEFI drivers, I want to use the default compiled library code. I haven't found a clean way to do this in the building process. Is there anyone who has tips regarding this problem? I hope the problem is clear, if not, please indicate so.

Kind regards,
Mick


Re: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Yao, Jiewen
 

We generate the FD image with an empty var storage FV.

Then use a tool to enroll the PK, KEK, DB - https://github.com/tianocore/edk2-staging/blob/TDVF/TdvfPkg/scripts/VarEnroll.py

Thank you
Yao Jiewen

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Vu Dinh
Sent: Thursday, April 8, 2021 5:03 PM
To: Yao; Yao, Jiewen <jiewen.yao@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] [EXTERNAL] [edk2-discuss] Customize Secure Boot
Configuration

Hi Yao,

The "read only FV" that you mentioned is generated by a tool? I had PK, KEK, DB,
DBX .cer and don't know how to merge them to a FV file to include it to FDF file
in edk2.

Thank you!
Vu




Re: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Vu Dinh
 

Hi Yao,

The "read only FV" that you mentioned is generated by a tool? I had PK, KEK, DB, DBX .cer and don't know how to merge them to a FV file to include it to FDF file in edk2.

Thank you!
Vu


Re: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Yao, Jiewen
 

Good point Bret. I could think some ways

1) you can construct a read only fv for variable storage and provision the pk kek db there. Just use a read only FVB.

2) you can embed pk kek db to FFS. Then use a special provision driver to create these variable during boot. You just need an emulator variable driver.

You can make decision based upon current fvb driver or variable driver.

thank you!
Yao, Jiewen

在 2021年4月7日,上午12:07,Bret Barkelew via groups.io <bret.barkelew=microsoft.com@groups.io> 写道:

There’s a few ways you could accomplish this, but I’m not aware of any “built-in” mechanism.

To get you started, I’d take a look at the implementation of these:
SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf

The built-in version refers to database variables, but you could easily write your own that just referred to PCDs for PK and KEK (in the AuthVariableLib) and db,dbx (aka, EFI_IMAGE_SECURITY_DATABASE and EFI_IMAGE_SECURITY_DATABASE2 in DxeImageVerificationLib).

- Bret

From: Vu Dinh via groups.io<mailto:vu.dinh=xelex.vn@groups.io>
Sent: Tuesday, April 6, 2021 7:58 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Dear all,

I'm currently developing UEFI payload with Secure Boot enabled. I want
to customize Secure Boot configuration (PK, KEK, DB, DBX) at build time
of Edk2 instead of changing Secure Boot in BIOS Setup.

Please tell me what should I do to customize Secure Boot configurations.

Thanks,

Vu











Re: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Bret Barkelew
 

There’s a few ways you could accomplish this, but I’m not aware of any “built-in” mechanism.

To get you started, I’d take a look at the implementation of these:
SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf

The built-in version refers to database variables, but you could easily write your own that just referred to PCDs for PK and KEK (in the AuthVariableLib) and db,dbx (aka, EFI_IMAGE_SECURITY_DATABASE and EFI_IMAGE_SECURITY_DATABASE2 in DxeImageVerificationLib).

- Bret

From: Vu Dinh via groups.io<mailto:vu.dinh=xelex.vn@groups.io>
Sent: Tuesday, April 6, 2021 7:58 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Customize Secure Boot Configuration

Dear all,

I'm currently developing UEFI payload with Secure Boot enabled. I want
to customize Secure Boot configuration (PK, KEK, DB, DBX) at build time
of Edk2 instead of changing Secure Boot in BIOS Setup.

Please tell me what should I do to customize Secure Boot configurations.

Thanks,

Vu


Customize Secure Boot Configuration

Vu Dinh
 

Dear all,

I'm currently developing UEFI payload with Secure Boot enabled. I want to customize Secure Boot configuration (PK, KEK, DB, DBX) at build time of Edk2 instead of changing Secure Boot in BIOS Setup.

Please tell me what should I do to customize Secure Boot configurations.

Thanks,

Vu


Re: UEFI Shell 2.7

Laszlo Ersek
 

On 03/27/21 00:30, Alex via groups.io wrote:
Hello there after installing Windows 10 and uninstalling it I'm unable
to see UEFI Shell 2.7 on my BIOS boot menu. I'm using ACER Aspire 7
A715-75G which had come with UEFI Shell 2.7 preinstalled. How can I
bring back that mini preinstalled UEFI Shell 2.7 back to the boot menu
on the UEFI Bios?
No clue, but you should be able to download a UEFI shell binary from:

https://github.com/tianocore/edk2/releases/tag/edk2-stable202002

(See "ShellBinPkg.zip".)

A more recent shell build has been requested here:

https://bugzilla.tianocore.org/show_bug.cgi?id=3178

Thanks
Laszlo


Re: Use of DebugLib in StandaloneMmCoreEntryPoint for AArch64 platforms

Laszlo Ersek
 

On 03/29/21 09:37, Thomas Abraham wrote:
Hi All,

The StandaloneMmCoreEntryPoint library for AArch64 platforms uses DebugLib APIs in the code path starting from '_ModuleEntryPoint' to the point at which 'ProcessModuleEntryPointList' is called. In this code path, the DebugLib APIs are invoked even before the DebugLib's constructor has executed. The DebugLib's constructor executes only after the execution reaches 'StandaloneMmMain' and 'ProcessLibraryConstructorList' is executed.

Due to this, on AArch64 platforms, the calls to DebugLib APIs in the above mentioned code path is incorrect because the constructor of the DebugLib has not executed. As an example, on AArch64 platforms that use 'BaseDebugLibSerialPort' as the DebugLib implementation, the serial port is not initialized prior to the call to DebugLib APIs causing serial port writes to fail and stall the execution.

Some solutions for this issue but not preferred ones are -


* Remove the DebugLib calls in the above mentioned code path (no DebugLib calls to be used until its constructor is called).
* Ensure that a previous boot stage has configured required hardware (serial port in case of BaseDebugLibSerialPort).

Are there better solutions for this particular problem?
Not necessarily "better", just different:

(1) Use (write) a DebugLib instance that has no constructor, and calls
SerialPortInitialize() the first time an actual DebugLib API needs to
produce output.

(2) Or, stick with BaseDebugLibSerialPort, but use (write) such a
SerialPortLib instance whose SerialPortInitialize() function does
nothing, but the output-producing SerialPortLib functions initialize the
hardware (and associated global variables) upon first use. Something
similar can be seen in
"ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c".

Laszlo


Thanks,
Thomas.




181 - 200 of 888