Date   

EmulatorPkg: Authenticated UEFI Variables not working

Eugene Khoruzhenko
 

For some reason after Variable initialization, mVariableModuleGlobal->VariableGlobal.AuthFormat = FALSE and VariableServiceQueryVariableInfo() returns EFI_UNSUPPORTED for authenticated variables. Nt32Pkg used to work well with Authenticated variables - are there special settings to configure EmulatorPkg properly?


Re: Trouble building EmulatorPkg

Sean
 

Eugene,

I actually haven't played with EmulatorPkg until 3 days ago when trying to stand up Platform Ci. I too used the old NT32 environment from time to time but am not well versed in the features of the EmulatorPkg. I found the readme lacking and was able to understand more from looking at the build.sh, buildVs.bat scripts, and DSC/FDF file.
Hopefully someone on the mailing list can help.

Thanks


Re: SMBIOS: are there any fields which hold be negative values?

Laszlo Ersek
 

On 04/01/20 20:50, Rebecca Cran wrote:
Before I send a patch, I wanted to check if anyone knew whether there
are any fields in the SMBIOS specification which can be negative? I
haven't across any, and the current code for smbiosview prints struct
fields with "%d", which can cause large values (such as DIMM sizes) to
be printed incorrectly.
I agree only %u / %x, and %lu / %lx should be used, for printing DWORD
and QWORD fields from SMBIOS tables (respectively). WORD and BYTE are
fine to print with %d, if the output should be decimal.

Thanks
Laszlo


Re: Trouble building EmulatorPkg

Eugene Khoruzhenko
 

Hi Sean, does EmulatorPkg support Authenticated UEFI variables? For some reason after initialization mVariableModuleGlobal->VariableGlobal.AuthFormat = FALSE and VariableServiceQueryVariableInfo() returns EFI_UNSUPPORTED. Nt32Pkg used to work well with Authenticated variables, maybe I do not configure EmulatorPkg properly? Thanks!


Re: Trouble building EmulatorPkg

Eugene Khoruzhenko
 

To build under VS2013 I had to add these two lines in \EmulatorPkg\Win\Host\WinHost.inf, for IA32 and X64 respectfully:

MSFT:*_VS2013_IA32_DLINK_FLAGS = /LIBPATH:"%VS2013_PREFIX%Lib" /LIBPATH:"%VS2013_PREFIX%VC\Lib" /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG /MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib

MSFT:*_VS2013_X64_DLINK_FLAGS = /LIBPATH:"%VS2013_PREFIX%VC\Lib\AMD64" /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib

With VS2013 and probably below, it turned out to be very important that an X64 build must start from either "VS2013 x64 Native Tools Command Prompt" or "VS2013 x64 Cross Tools Command Prompt"; an IA32 build would have to start in either "VS2013 x86 Native Tools Command Prompt" or "Developer Command Prompt for VS2013". My build was by default choosing "Developer Command Prompt" and I got build errors.


Re: Trouble building EmulatorPkg

Eugene Khoruzhenko
 

Thanks Sean, this was very helpful!


Re: Trouble building EmulatorPkg

Sean
 

Master of github.com/spbrogan/edk2 should have everything needed.
It is based on master of edk2 from 2 days ago plus changes i have been making to enable platform ci.

I can't help with VS2013. We have focused PyTool efforts on N, and N-1 of VS. So that VS2019 and 2017. Also these two versions are in the new model of having multiple instances of VS so our scheme takes advantage of VSWhere and a more dynamic VS configuration.

See here: https://github.com/spbrogan/edk2/commit/c6d4cda2561a0ec688ac3047611af48f137ec9df or https://github.com/spbrogan/edk2/blob/master/EmulatorPkg/Win/Host/WinHost.inf#L90 to see the addition for VS2019

Thanks
Sean


Re: Trouble building EmulatorPkg

Eugene Khoruzhenko
 

Sean, thanks for the quick reply. Which branch/tag are you referring to? I am trying to build from "master" and building with VS2019 is not working. Looking at WinHost.inf, it only mentions VS2015 and VS2017, so VS2019 cannot be supported as checked-in in the master branch.

Also, I really need to use VS2013 as the rest of my environment, including debugger, work in VS2013...


Re: Trouble building EmulatorPkg

Sean
 

I have been building this recently for a POC showing how we (tianocore) can do Platform CI. As part of that I have enabled the emulatorpkg to use PyTools platform building. This works for VS2017 and VS2019 IA32 and X64. PyTools does all the environment and path management to setup the correct libs, includes, etc.

Help here. https://github.com/spbrogan/edk2/blob/master/EmulatorPkg/README-pytools.md
Server build and execution of emulator shown here. https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=5200&view=results

If that is helpful or you have feedback let me know.

Thanks
Sean


Re: Trouble building EmulatorPkg

Eugene Khoruzhenko
 

Found the problem - the build seems to be hardcoded for VS2017. The Winhost makefile in VS2013 build has DLINK_FLAGS that's missing all the necessary libraries. The EmulatorPkg documentation, such as Readme.md, should specify that only specific Visual Studio is supported.


SMBIOS: are there any fields which hold be negative values?

Rebecca Cran
 

Before I send a patch, I wanted to check if anyone knew whether there are any fields in the SMBIOS specification which can be negative? I haven't across any, and the current code for smbiosview prints struct fields with "%d", which can cause large values (such as DIMM sizes) to be printed incorrectly.


--
Rebecca Cran


Trouble building EmulatorPkg

Eugene Khoruzhenko
 

As described in Readme.md, building 64bit emulator in Windows:
build -p EmulatorPkg\EmulatorPkg.dsc -t VS2013 -a X64

But getting an error linking WinHost:
d:/src/edk2/Build/EmulatorX64/DEBUG_VS2013/X64/EmulatorPkg/Library/SecPeiServicesLib/SecPeiServicesLib/OUTPUT/SecPeiServicesLib.lib
d:/src/edk2/Build/EmulatorX64/DEBUG_VS2013/X64/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib/OUTPUT/FrameBufferBltLib.lib
LINK : warning LNK4108: /ALIGN specified without /DRIVER; image may not run
LINK : warning LNK4001: no object files specified; libraries used
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
LINK : error LNK2001: unresolved external symbol _ModuleEntryPoint
d:\src\edk2\Build\EmulatorX64\DEBUG_VS2013\X64\WinHost.lib : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\x86_amd64\link.exe"' : return code '0x460'
Stop.

Tried building IA32 - getting the following errors (also linking WinHost):
WinHost.lib(WinHost.obj) : error LNK2001: unresolved external symbol __imp__OpenProcessToken@12
WinHost.lib(WinHost.obj) : error LNK2001: unresolved external symbol __imp__AdjustTokenPrivileges@24
WinHost.lib(WinHost.obj) : error LNK2001: unresolved external symbol __imp__LookupPrivilegeValueW@12
WinHost.lib(WinThunk.obj) : error LNK2001: unresolved external symbol __imp__timeSetEvent@20
WinHost.lib(WinThunk.obj) : error LNK2001: unresolved external symbol __imp__timeKillEvent@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__SetDIBitsToDevice@48
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__GetMessageW@16
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__TranslateMessage@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__DispatchMessageW@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__SendMessageW@16
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__DefWindowProcW@16
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__PostQuitMessage@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__UnregisterClassW@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__RegisterClassExW@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__CreateWindowExW@48
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__DestroyWindow@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__ShowWindow@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__MoveWindow@24
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__UpdateWindow@4
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__BeginPaint@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__EndPaint@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__InvalidateRect@12
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__GetWindowRect@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__AdjustWindowRect@12
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__LoadCursorW@8
WinHost.lib(WinGopScreen.obj) : error LNK2001: unresolved external symbol __imp__LoadIconW@8
d:\src\edk2\Build\EmulatorIA32\DEBUG_VS2013\IA32\WinHost.exe : fatal error LNK1120: 26 unresolved externals
Building ... d:\src\edk2\MdeModulePkg\Universal\PCD\Dxe\Pcd.inf [IA32]
Building ... d:\src\edk2\MdeModulePkg\Universal\Console\TerminalDxe\TerminalDxe.inf [IA32]
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\link.exe"' : return code '0x460'

I tried to checkout different stable edk2 tags like tags/edk2-stable202002 - same issues. I tried building on 3 different machines with different Visual Studios - same problems. Is there any trick building EmulatorPkg?


Re: Resolution and graphical issues with OVMF firmware and MacOS?

Laszlo Ersek
 

On 03/26/20 22:43, n.sherlock@gmail.com wrote:
The issue has been somewhat lost in translation here. The screen
resolution is remembered just fine by OVMF.

The symptom is that OVMF doesn't yet apply the chosen resolution
(1920x1080) on the boot logo screen, it stays in the low resolution
default (800x600?). You can see this by the large size of the Proxmox
boot logo on the screen (where the Tianocore logo would normally be):

https://i.imgur.com/NL9QlKv.png

Then when macOS boots, it looks like it thinks the framebuffer is only
800x600, but it has actually been resized to 1920x1080 by the Clover
bootloader. This causes the Apple logo to appear at the top left
corner of the framebuffer, and macOS fails to boot:

https://i.imgur.com/kuq9KqI.png

However, if you hit F2 during boot to enter OVMF, and simply hit
"Reset", the 1920x1080 chosen resolution gets correctly applied to the
boot logo screen:

https://i.imgur.com/CnL6df2.png

And now the size that macOS thinks the framebuffer is matches with the
actual resolution, the Apple logo is correctly centred, and boot
proceeds normally:

https://i.imgur.com/HvdoDml.png

Can you reproduce this quirk with the resolution of the boot logo
screen?
If I understand correctly, the complaint is that the resolution chosen
in the Setup TUI is not applied *at once*, without a reboot.

If I do understand correctly, then this is intended / by-design
behavior. Please read the "OVMF Settings" form carefully:

Preferred Resolution at 640x480 You can specify a new
Next Boot preference for the
Change Preferred <640x480> Graphics Console
Resolution for Next Boot here. The list is
Commit Changes and Exit filtered against the
Discard Changes and Exit video RAM size.

Cue the expression "Next Boot" in both of:

- "Preferred Resolution at *Next Boot*"

- "Change Preferred Resolution for *Next Boot*"

This is because, by the time the setup browser is entered, and the user
is given the opportunity for modifying the setting, the setting has
already been consumed by more foundational parts of the firmware.

If you want the changed resolution to take effect, before you boot the
OS, you *must* reboot at this point.

The dialog itself does not reboot automatically because (a) you might
want to change other configuration options in the setup TUI, (b) you
might even want to boot to e.g. the UEFI Shell with the presently active
resolution, perform some changes at the shell prompt, and reboot *then*.

So, after hitting Enter on "Commit Changes and Exit" (which returns you
to "Device Manager"), press ESC one (which will take you back to the
outermost menu), and there, select "Reset".

Thanks
Laszlo


Re: Resolution and graphical issues with OVMF firmware and MacOS?

n.sherlock@...
 

The issue has been somewhat lost in translation here. The screen resolution is remembered just fine by OVMF.

The symptom is that OVMF doesn't yet apply the chosen resolution (1920x1080) on the boot logo screen, it stays in the low resolution default (800x600?). You can see this by the large size of the Proxmox boot logo on the screen (where the Tianocore logo would normally be):

https://i.imgur.com/NL9QlKv.png

Then when macOS boots, it looks like it thinks the framebuffer is only 800x600, but it has actually been resized to 1920x1080 by the Clover bootloader. This causes the Apple logo to appear at the top left corner of the framebuffer, and macOS fails to boot:

https://i.imgur.com/kuq9KqI.png

However, if you hit F2 during boot to enter OVMF, and simply hit "Reset", the 1920x1080 chosen resolution gets correctly applied to the boot logo screen:

https://i.imgur.com/CnL6df2.png

And now the size that macOS thinks the framebuffer is matches with the actual resolution, the Apple logo is correctly centred, and boot proceeds normally:

https://i.imgur.com/HvdoDml.png

Can you reproduce this quirk with the resolution of the boot logo screen?

Cheers,
Nicholas Sherlock


Re: Resolution and graphical issues with OVMF firmware and MacOS?

Laszlo Ersek
 

On 03/24/20 14:49, victorhooi via Groups.Io wrote:
Hi,

I'm following this guide:

https://www.nicksherlock.com/2019/10/installing-macos-catalina-10-15-on-proxmox-6/

in order to install MacOS on a Proxmox system.

However, there appears to be a bug in the OVMF firmware - where you need to go into the OVMF Platform configuration, and set the resolution again on *every* boot in order to get it to boot.

Follow the steps above to set the screen resolution to 1920×1080, press F10 to save your changes, and “reset” to apply the new settings (not “continue”). This step is required to avoid scrambled graphics on boot and a hang (Clover resolution must match OVMF resolution, or else the Apple logo will be off-centre and the progress bar will be smeared across the screen, resulting in a lockup).
Note that in future you’ll find that when initially started, your VM doesn’t properly apply the the 1920×1080 screen resolution until you hit “Restart Computer” in Clover when the Clover menu appears (or “Reset” on the VM). You’ll notice this happening when the “Proxmox” logo fills a large area of the screen on boot due to the low resolution.
If you don't - you will get scrambled graphics when you boot up.

Is there some way of fixing this in the OVMF firmware itself?
Please talk to the Proxmox developers and/or the author of the guide you
linked above. There is no bug in OVMF in the area you mention -- it
works just fine on QEMU, using pflash for backing the UEFI variable
store. I don't know why the 1920x1080 screen resolution doesn't "stick"
for you, using proxmox; the resolution certainly sticks when
non-volatile UEFI variables are actually non-volatile.

Thanks
Laszlo


Resolution and graphical issues with OVMF firmware and MacOS?

victorhooi@...
 

Hi,

I'm following this guide:

https://www.nicksherlock.com/2019/10/installing-macos-catalina-10-15-on-proxmox-6/

in order to install MacOS on a Proxmox system.

However, there appears to be a bug in the OVMF firmware - where you need to go into the OVMF Platform configuration, and set the resolution again on *every* boot in order to get it to boot.

Follow the steps above to set the screen resolution to 1920×1080, press F10 to save your changes, and “reset” to apply the new settings (not “continue”). This step is required to avoid scrambled graphics on boot and a hang (Clover resolution must match OVMF resolution, or else the Apple logo will be off-centre and the progress bar will be smeared across the screen, resulting in a lockup).
Note that in future you’ll find that when initially started, your VM doesn’t properly apply the the 1920×1080 screen resolution until you hit “Restart Computer” in Clover when the Clover menu appears (or “Reset” on the VM). You’ll notice this happening when the “Proxmox” logo fills a large area of the screen on boot due to the low resolution.
If you don't - you will get scrambled graphics when you boot up.

Is there some way of fixing this in the OVMF firmware itself?

Thanks,
Victor


Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Tiger Liu(BJ-RD)
 

Hi, Bret:
Thanks for your reply!
You are right.

Best wishes,

-----邮件原件-----
发件人: discuss@edk2.groups.io <discuss@edk2.groups.io> 代表 Bret Barkelew via Groups.Io
发送时间: 2020年3月20日 3:23
收件人: discuss@edk2.groups.io; Tiger Liu(BJ-RD) <TigerLiu@zhaoxin.com>
主题: Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Wait… I take that back. I was mistaken about which PCD we were talking about (answering email too fast).

This is an older version of the MAT enablement that was found to be incompatible in a number of scenarios. The correct MAT table should be produced automatically by DXE as long as your images are EFI_PAGE_SIZE aligned…

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c

- Bret

From: Bret Barkelew via Groups.Io<mailto:bret.barkelew=microsoft.com@groups.io>
Sent: Thursday, March 19, 2020 12:07 PM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; tigerliu@zhaoxin.com<mailto:tigerliu@zhaoxin.com>
Subject: Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

I think our (MS Core UEFI) opinion would be that the default should change to TRUE.

- Bret

________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Tiger Liu(BJ-RD) via Groups.Io <tigerliu=zhaoxin.com@groups.io>
Sent: Tuesday, March 17, 2020 9:00:17 PM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Hi, Experts:
I have a question about UEFI MAT / PcdPropertiesTableEnable.
Device protection in Windows Security, standard hardware security requirement is described as below:
TPM 2.0
Secure Boot Enabled
DEP
UEFI MAT

And UEFI MAT feature is related with PcdPropertiesTableEnable.

But I found the newest UDK kernel, this PCD is still set with FALSE.

So, is there any concerns if setting its default value as TRUE.

Thanks











保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Bret Barkelew
 

Wait… I take that back. I was mistaken about which PCD we were talking about (answering email too fast).

This is an older version of the MAT enablement that was found to be incompatible in a number of scenarios. The correct MAT table should be produced automatically by DXE as long as your images are EFI_PAGE_SIZE aligned…

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c

- Bret

From: Bret Barkelew via Groups.Io<mailto:bret.barkelew=microsoft.com@groups.io>
Sent: Thursday, March 19, 2020 12:07 PM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>; tigerliu@zhaoxin.com<mailto:tigerliu@zhaoxin.com>
Subject: Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

I think our (MS Core UEFI) opinion would be that the default should change to TRUE.

- Bret

________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Tiger Liu(BJ-RD) via Groups.Io <tigerliu=zhaoxin.com@groups.io>
Sent: Tuesday, March 17, 2020 9:00:17 PM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Hi, Experts:
I have a question about UEFI MAT / PcdPropertiesTableEnable.
Device protection in Windows Security, standard hardware security requirement is described as below:
TPM 2.0
Secure Boot Enabled
DEP
UEFI MAT

And UEFI MAT feature is related with PcdPropertiesTableEnable.

But I found the newest UDK kernel, this PCD is still set with FALSE.

So, is there any concerns if setting its default value as TRUE.

Thanks


Re: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Bret Barkelew
 

I think our (MS Core UEFI) opinion would be that the default should change to TRUE.

- Bret

________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Tiger Liu(BJ-RD) via Groups.Io <tigerliu=zhaoxin.com@groups.io>
Sent: Tuesday, March 17, 2020 9:00:17 PM
To: discuss@edk2.groups.io <discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Questions about UEFI MAT / PcdPropertiesTableEnable

Hi, Experts:
I have a question about UEFI MAT / PcdPropertiesTableEnable.
Device protection in Windows Security, standard hardware security requirement is described as below:
TPM 2.0
Secure Boot Enabled
DEP
UEFI MAT

And UEFI MAT feature is related with PcdPropertiesTableEnable.

But I found the newest UDK kernel, this PCD is still set with FALSE.

So, is there any concerns if setting its default value as TRUE.

Thanks


Questions about UEFI MAT / PcdPropertiesTableEnable

Tiger Liu(BJ-RD)
 

Hi, Experts:
I have a question about UEFI MAT / PcdPropertiesTableEnable.
Device protection in Windows Security, standard hardware security requirement is described as below:
TPM 2.0
Secure Boot Enabled
DEP
UEFI MAT

And UEFI MAT feature is related with PcdPropertiesTableEnable.

But I found the newest UDK kernel, this PCD is still set with FALSE.

So, is there any concerns if setting its default value as TRUE.

Thanks

681 - 700 of 859