Tianocore/edk2.git/EmulatorPkg/Win, branch dependabot/github_actions/github/codeql-action-4

EmulatorPkg/Win/Host: Fix loaded DLL page protections

2025-10-30T19:23:44+00:00

The current algorithm evaluates page protection in sections of a PE/COFF image at DWORD granularity and it skips the evaluation of the first DWORD of the PE/COFF image. If a PE/COFF section has a VirtualSize that is ends in first 4 bytes of a 4KB page, then the PE/COFF section protection attributes for that section are not applied to that page due to the DWORD stride. For example, a .text section with a VirtualSize of 0x1001, 0x1002, 0x1003, or 0x1004 followed by non .text section will not apply the PAGE_EXECUTE_READ attribute to the second page of the .text section and execution of code at the end of that .text section generates an access violation exception. The fix is to change the stride for evaluating page protection attributes from DWORD to BYTE. The loop is also updated to include evaluation of the first DWORD of the PE/COFF image. Signed-off-by: Michael D Kinney

EmulatorPkg/Win/Host: Remove set but not used variables

2025-09-22T07:12:48+00:00

Signed-off-by: Michael D Kinney

EmulatorPkg: Remove UGA support

2025-07-08T15:42:03+00:00

The Universal Graphics Adapter (UGA) is a graphic abstraction. The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was introduced. Cf. the UEFI spec v2.9: "Appendix L - EFI 1.10 Protocol Changes and Deprecation List" section L.2 "Deprecated Protocols" Remove the UGA support. Signed-off-by: GuoMinJ Signed-off-by: Pierre Gondois

EmulatorPkg: Fix enum type mismatch warning treated as error

2025-06-12T22:38:39+00:00

Issue: While building edk2, the compiler threw a warning that was treated as an eror which halted the build process. Root Cause: The error was due to a comparison between two different enum types. Code Fix: WinGopScreen.c: In function WinNtWndBlt, changed the comparison between an enum type "EFI_UGA_BLT_OPERATION" and "EFI_GRAPHICS_OUTPUT_BLT_OPERATION" to "EFI_UGA_BLT_OPERATION". Test: The compiled image runs successfully on QEMU. Signed-off-by: Rithvik Rama

MdePkg: Move StackCheckLibStaticInit to StackCheckLib

2025-02-07T02:23:11+00:00

This commit oves StackCheckLib from a NULL lib to an instance of StackCheckLib. This requires every entry point to add a library dependency on StackCheckLib. It also requires every SEC module to have a dependency on StackCheckLib because there is no standard SEC entry point. It allows for greater flexibility for a platform to apply stack cookies and simplifies DSC logic. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

EmulatorPkg: Move magic page to first allocation

2025-01-23T04:20:47+00:00

The magic page is allocated from a fixed address specified by PcdPeiServicesTablePage. This allocation has been observed to sometimes fail. Move the allocation of this buffer to the very beginning of main() to minimize the change that another allocation is allocated from the PcdPeiServicesTablePage address. Signed-off-by: Michael D Kinney

EmulatorPkg: Fix IA32 MSVC Linker Warnings

2025-01-22T19:47:20+00:00

IA32 EmulatorPkg had many linker warnings because with the current set of linker flags, the MSVC linker was expecting the __stdcall calling convention on all entry points. This was an effect of having /SUBSYSTEM:CONSOLE on all binaries built in EmulatorPkg; this is only needed on WinHost, as that is what Windows launches. The linker options are adjusted to only set /SUBSYSTEM:CONSOLE on WinHost. Signed-off-by: Oliver Smith-Denny

EmulatorPkg: Fix Source Level Debug on Windows

2025-01-22T00:27:46+00:00

The Visual Studio Windows debugger will only load symbols for PE/COFF images that Windows is aware of. Therefore, to enable source level debugging, all PEI/DXE modules must be loaded via LoadLibrary() or LoadLibraryEx() and the the instance in memory created by LoadLibrary() must be the one that is actually executed. The current source level debug implementation in EmulatorPkg for Windows is inherited from the old Nt32Pkg. This implementation makes the assumption that all PEI/DXE modules have a DLL export tables with a symbol named InitializeDriver. Therefore, this source level debug implementation requires all modules to be linked in a non-PI spec defined manner. Support for adding the InitializeDriver symbol was removed in EmulatorPkg, which broke source level debugging. To fix this, the source level debugging implementation has been modified to use the PE/COFF entry point directly. This brings the implementation into compliance with the PI spec and should work with any PEIM/DXE driver. Implementing this requires parsing the in-memory instance of the PE/COFF image created by Windows to find the entrypoint and since PEIMs/DXE drivers are not garunteed to have 4KB aligned sections, it also requires explicit configuration of the page table using VirtualProtect(). With this fix, the debugging experience is now so good it is unprecedented! In Visual Studio Code, add the following to launch.json: { "version": "0.2.0", "configurations": [ { "name": "EmulatorPkg Launch", "type": "cppvsdbg", "request": "launch", "program": "${workspaceFolder}//Build/EmulatorX64/DEBUG_/X64/WinHost", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}//Build/EmulatorX64/DEBUG_/X64/", "environment": [], "console": false, } ] } Make modifications to the above template as nessesary and build EmulatorPkg. Now, just add breakpoints directly in Visual Studio Code the way you would with any other software project. When you start the debugger, it will halt at the breakpoint automatically without any extra configuration required. Reviewed-by: Michael D Kinney Cc: Andrew Fish Cc: Ray Ni Cc: Chasel Chiu Signed-off-by: Nate DeSimone

EmulatorPkg/Win/Host: Use safe function _vsnprintf_s()

2025-01-13T05:36:40+00:00

Update SecPrint() to use _vsnprintf_s() instead of _vsnprintf() that is a safe function and allows the defines _CRT_SECURE_NO_WARNINGS and _CRT_SECURE_NO_DEPRECATE to be removed from WinHost builds. Signed-off-by: Michael D Kinney

EmulatorPkg: spurious failure in WriteBlocks on X64

2024-12-17T19:01:48+00:00

WinNtBlockIoWriteBlocks can spuriously fail on X64. This occurs because &BytesWritten is a `UINTN*` (i.e. `UINT64*`) but is cast to `LPDWORD` (i.e. `UINT32*`). Only the low 32 bits are initialized by WriteFile, so the high 32 bits are uninitialized. This means we will spuriously fail the `BytesWritten != BufferSize` test. This doesn't occur on X86-32 since UINTN is the same as DWORD in that case. Fix is to declare BytesWritten as DWORD to match the type expected by WriteFile. This also makes the cast unnecessary. Signed-off-by: Doug Cook