Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
On 08/04/15 05:16, Ni, Ruiyu wrote: No. I forgot to emphasize that I only tested the QEMU boot timeout feature after changing the QemuBootOrderLib. I don't know how to test the boot order feature. This series, on the surface, seems intrusive and to have potential to cause many regressions. So, as the first step, please push the series to a public repo, so I can fetch it -- I tried to apply it manually and it failed -- and review it locally. In particular I'd like to review the series with rename and copy detection enabled in git. (So that the pure code movement is filtered out of the patches.) The boot order stuff is very hairy and also very important to us, so I'll have to review that carefully. A different question -- can you please tell me more about the new BDS and UiApp? What the motivation for it was, what it does? Do the GenericBdsLib functions continue to work? What we have in OvmfPkg at the moment is pretty fine-tuned to GenericBdsLib, so if the new library is just a rough match, it might not be feasible to quickly rebase OvmfPkg. Also, given that ArmVirtPkg is not being modified, it appears that GenericBdsLib is not planned (in the short/mid term at least) to be phased out. Is that correct? Because if it is, then I wonder if it would be more prudent to implement these changes in OVMF with a new build time flag. Namely, I don't want to block the testing / development of the new BDS infrastructure -- OVMF is a nice testbed for firmware development, so it should support such use cases. (Also, in the long term we should probably move to the new BDS permanently, as there must have been good reasons for implementing the new BDS in the first place.) However, this should not regress current users. No matter how carefully we review and test the new code, something will inevitably break, and users should not be exposed to that at once (and we shouldn't have to scramble for fixes retroactively, in a mortal hurry). Optimally, edk2 should support stable and development branches releases (not just for UDK but for everything else, OvmfPkg included). Since we don't have that, I think it's prudent to implement intrusive changes in two phases, with a new build time flag. And at some point we can flip the default, if we want to. (For example, in ArmVirtPkg we still have -D INTEL_BDS separately.) For the SeaBIOS CSM, can you tell me how to test or test it for me if it's very quick? It's pretty messy. I think David used to have the best set of legacy guests for testing CSM, so I'd ask him to help with testing it this time too (sorry David! :)) However, that will also require this series to be available in a public branch somewhere. Thanks! Laszlo Thanks, Ray -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David Woodhouse Sent: Monday, August 3, 2015 6:31 PM To: Ni, Ruiyu ruiyu...@intel.com; edk2-de...@ml01.01.org Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg On Mon, 2015-08-03 at 13:41 +0800, Ruiyu Ni wrote: A new BDS and UiApp was created in MdeModulePkg and are already used in Nt32Pkg. The patch changes the OvmfPkg to use the new BDS and UiApp as well. Hi Ruiyu, were these changes tested with the SeaBIOS CSM? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
On 08/04/15 12:53, Laszlo Ersek wrote: No matter how carefully we review and test the new code, something will inevitably break, This wasn't meant as lack of trust in your code; it's just that there are many cases and corner cases in the related OVMF code, and it's quite hard to test them all. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools features: multiple workspaces
On 08/03/15 19:35, Jordan Justen wrote:
On 2015-08-03 02:08:14, Gao, Liming wrote:
Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
I know you originally suggested to use WORKSPACE, but got some
feedback that it might be better to create a new variable to not break
some unspecified tools.
Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new
WORKSPACE_MULTIPLE environment variable.
I think that using the single separated WORKSPACE environment variable
is more intuitive/expected. From using env vars such as PATH, we all
know what it means.
For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
This was described in Liming's email, in point 4b.
Will this work for the integrated CryptoPkg + open-ssl? It seems like
we need a priority above EDK II for this. I guess WORKSPACE will not
be set to EDK II in this case?
Anyway, it just seems a little odd.
For me a colon-separated (well, separator-separated :)) single WORKSPACE
variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined
well enough too. For example:
- WORKSPACE must not contain separators
- if WORKSPACE_MULTIPLE is set, then the effect is as if
${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
well-known PATH semantics.
No clue about the CryptoPkg impact. Can you remind me please why
CryptoPkg / OpensslLib are special wrt. WORKSPACE?
Thanks
Laszlo
-Jordan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo
Bonzini
Sent: Monday, August 03, 2015 4:31 PM
To: Gao, Liming; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 03/08/2015 05:56, Gao, Liming wrote:
Hi, all
We will update BaseTools feature to allow more than one workspaces. The
detail design in the below. Please help review it. If you have any
comments, please let me know.
1. Keep $(WORKSPACE) environment as is
a. $(WORKSPACE) determines location of Build and Conf directory.
2. New optional $(WORKSPACE_MULTIPLE) environment is added to include
more directories with the separator ';', like $(PATH)
Why is $(WORKSPACE_MULTIPLE) necessary? On Linux it is okay to break
preexisting paths that contain a :; on Windows semicolons are allowed in
theory but in practice break in several ways.
Paolo
a. Produce the same behavior if $(WORKSPACE_MULTIPLE) is not set.
3. Update edksetup.bat/edksetup.sh to find BaseTools directory from
$(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
4. Update BaseTools to support multiple workspaces
a. For the relative file path (INF, DSC and FDF), BaseTools will
search them from $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
b. Search priority from high to low: $(WORKSPACE),
$(WORKSPACE_MULTIPLE).
This is a compatible feature. It has no impact on current EDKII project.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
On Tue, 2015-08-04 at 03:16 +, Ni, Ruiyu wrote: I forgot to emphasize that I only tested the QEMU boot timeout feature after changing the QemuBootOrderLib. I don't know how to test the boot order feature. For the SeaBIOS CSM, can you tell me how to test or test it for me if it's very quick? It's been a quite since I've done it; Laszlo probably has more up-to -date instructions and a prepackaged SeaBIOS .config file (perhaps in the RPM packages). But basically you first build the SeaBIOS CSM image as described at http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29 and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with -DCSM_ENABLE. Then (if the BDS gets it right) you should be able to boot legacy targets as well as native UEFI targets. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
-Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 04, 2015 2:36 PM On 08/04/15 10:38, Sharma Bhupesh wrote: -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, August 04, 2015 2:01 PM On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux Loader being deprecated, are there any plans to provide means to pass FIT format images via EFI_STUB to the ARM64 Linux kernel? No. FIT images are a U-Boot construct. The recommended way under UEFI is to install the device tree as a FDT configuration table in the firmware. Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI stub, by passing the initrd= option. The recommended way of doing authentication of bootable images is to use UEFI Secure Boot. DTB authentication is implicit if it is part of the UEFI image itself. How to do initrd authentication is undefined. (I'd say unspecified rather than undefined, but that's a side point.) initrd (Rootfs) is probably the easiest place to introduce a malicious application in, which can easily overwrite the text area, thus causing the core to run a Trojan. How is this different from overwriting applications on a normal file system? As far as I understand, applications are not part of the chain being verified. Cryptographically verifying the entire Root filesystem being provided with a software development kit, allows a OEM/customer to ensure that the platform only boots a application-set which is authenticated using their Public-Private key pairs. So, if the system tries to launch a rootfs which is not authenticated via the OEM/customer's public key, the boot process stalls and a preventive tamper-proofing action like zero'ing the DDR contents and reseting the SoC can be taken. Regards, Bhupesh Kernel modules are (and they do reside in the initrd), but they should already be covered by module signing. http://mjg59.dreamwidth.org/12368.html https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect- signing-kernel-modules-for-secure-boot.html https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se cboot.html https://www.suse.com/documentation/sles- 12/book_sle_admin/data/sec_uefi_secboot.html Thanks Laszlo The normal secure chain of boot, requires that each component verifies the next component it launches. FIT format seems to plug this gap. Can you point me to some documentation on UEFI secure boot and how it works on the ARM64 platforms - does it internally use and program the ARM TrustZone components like the TZASC and TZPC to partition the System RAM, etc into appropriate secure and non-secure partitions and the images cryptographically verify the next stage image. A typical flow most OEMs use is: BootROM - Arm Trusted Firmware - UEFI - Linux - Initrd The current SEC stage code for ARM64 platforms supported in EDK2 seem to be programming the TZASC and TZPC entities, but I cannot see any secure chain-of-trust being established for the next stage images there. Regards, Bhupesh Regards, Ard. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 04, 2015 1:27 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com Cc: ryan.har...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes LinuxLoader has been split off from the ARM BDS into a separate EFI application. Because we never included this application into the ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever since that change was merged. Let's fix the situation by: - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels have UEFI stub support enabled by default, and the LinuxLoader code for booting arm64 Linux kernels is buggy. Note that this does not disable the ARM BDS text menu, it just removes the ability to boot bare Linux kernels. - Adding the LinuxLoader EFI application to the ARM builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 9 ++--- ArmVirtPkg/ArmVirtQemu.dsc | 5 + ArmVirtPkg/ArmVirtQemu.fdf | 3 +++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 2e2708d1c281..735f9edc58d6 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
On 4 August 2015 at 11:21, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 04, 2015 2:36 PM On 08/04/15 10:38, Sharma Bhupesh wrote: -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, August 04, 2015 2:01 PM On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux Loader being deprecated, are there any plans to provide means to pass FIT format images via EFI_STUB to the ARM64 Linux kernel? No. FIT images are a U-Boot construct. The recommended way under UEFI is to install the device tree as a FDT configuration table in the firmware. Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI stub, by passing the initrd= option. The recommended way of doing authentication of bootable images is to use UEFI Secure Boot. DTB authentication is implicit if it is part of the UEFI image itself. How to do initrd authentication is undefined. (I'd say unspecified rather than undefined, but that's a side point.) initrd (Rootfs) is probably the easiest place to introduce a malicious application in, which can easily overwrite the text area, thus causing the core to run a Trojan. How is this different from overwriting applications on a normal file system? As far as I understand, applications are not part of the chain being verified. Cryptographically verifying the entire Root filesystem being provided with a software development kit, allows a OEM/customer to ensure that the platform only boots a application-set which is authenticated using their Public-Private key pairs. Putting DTB, kernel and initrd in the same signed archive is a design driven by convenience, not by security. It is the firmware's responsibility to authenticate and boot the kernel image, and provide it with a description of the hardware. The kernel's trust of the firmware is implicit, that is why, under UEFI Secure Boot, the only way of obtaining a DTB is from the configuration table (the dtb= kernel command line parameter is disabled in this case) It is the kernel's responsibility to authenticate the file system, regardless of whether it is a initrd or a filesystem hosted on block storage. To the firmware, the initrd is just an opaque blob, whereas, from the kernel pov, the initrd is a readable archive with kernel modules and executables, each of which may have their own authentication requirements. So, if the system tries to launch a rootfs which is not authenticated via the OEM/customer's public key, the boot process stalls and a preventive tamper-proofing action like zero'ing the DDR contents and reseting the SoC can be taken. A chain of trust implies discrete links. Signing everything with the OEM/customer's public key and verifying all at the same time may be appropriate in some cases, but you should not present it as the common design. In general, it is much more convenient to allow the kernel to be in charge of the public keys that authenticate subsequent boot stages rather than mandating that DTB, kernel *and* initrd are all signed with a public key known to the firmware. -- Ard. Kernel modules are (and they do reside in the initrd), but they should already be covered by module signing. http://mjg59.dreamwidth.org/12368.html https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect- signing-kernel-modules-for-secure-boot.html https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se cboot.html https://www.suse.com/documentation/sles- 12/book_sle_admin/data/sec_uefi_secboot.html Thanks Laszlo The normal secure chain of boot, requires that each component verifies the next component it launches. FIT format seems to plug this gap. Can you point me to some documentation on UEFI secure boot and how it works on the ARM64 platforms - does it internally use and program the ARM TrustZone components like the TZASC and TZPC to partition the System RAM, etc into appropriate secure and non-secure partitions and the images cryptographically verify the next stage image. A typical flow most OEMs use is: BootROM - Arm Trusted Firmware - UEFI - Linux - Initrd The current SEC stage code for ARM64 platforms supported in EDK2 seem to be programming the TZASC and TZPC entities, but I cannot see any secure chain-of-trust being established for the next stage images there. Regards, Bhupesh Regards, Ard. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 04, 2015 1:27 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com Cc: ryan.har...@linaro.org; Ard Biesheuvel Subject: [edk2]
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
On 08/04/15 11:44, Zeng, Star wrote: -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Tuesday, August 4, 2015 5:25 PM To: Zeng, Star; Justen, Jordan L Cc: Paolo Bonzini; edk2-de...@ml01.01.org; Yao, Jiewen Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support On 08/04/15 10:59, Zeng, Star wrote: -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 4, 2015 4:34 PM To: Zeng, Star Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support Star, On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule] ## The number of bytes between registers in serial device. The default is 1 byte. # @Prompt Serial Port Register Stride in Bytes gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00 01 006d - + + ## Indicates if to set NX for stack.BRBR # For the DxeIpl + and the DxeCore are both X64, set NX for stack feature also + require PcdDxeIplBuildPageTables be TRUE.BR # For the DxeIpl + and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is + FALSE), set NX for stack feature also require # IA32 PAE is supported and Execute Disable Bit is available.BR + # TRUE - to set NX for stack.BR + # FALSE - Not to set NX for stack.BR + # @Prompt Set NX for stack. + + gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x 0001 + 006f + Are there any restrictions for setting this PCD statically in a platform DSC file? Could it regress anything? No. This feature require to build page table. More detailed explanation below. In OVMF we have three DSC files: - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. If we set PcdSetNxForStack in this DSC file, will the code dynamically determine if the hardware has the necessary features, and fall back gracefully if it doesn't? Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used to determine if the hardware has the necessary features. By default, 32BIT PEI+32BIT DXE do not need page table and PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both X64 as the comments in MdeModulePkg.dec. But this feature require page table, so (PcdGetBool (PcdSetNxForStack) IsIa32PaeSupport () IsExecuteDisableBitAvailable ()) is used to determine if building page table or not. Ah, I can see that in the patch. It gates the new Create4GPageTablesIa32Pae() function. - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is TRUE. This use case doesn't seem to be described in the .dec file above. Is this configuration compatible with PcdSetNxForStack=TRUE? Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special comments for it in MdeModulepkg.dec and just PcdGetBool (PcdSetNxForStack) is used to enable this feature or not in page table (Nx bit). Great. - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. We don't change PcdDxeIplBuildPageTables from the default, but the default in MdeModulePkg/MdeModulePkg.dec is TRUE, and we inherit that. Can we set PcdSetNxForStack to TRUE, statically? Of course YES. Thanks. The question emerges then: why doesn't PcdSetNxForStack default to true? I can see two possible reasons: - It is a new feature and causes changes in behavior. At worst, some firmware could even rely on executing code from the stack. That shouldn't be broken. - The code adds a new ASSERT(), and it could be triggered if the platform left PcdDxeIplBuildPageTables at FALSE. It's not nice to introduce code with potential to trigger an ASSERT() immediately, so this makes sense too. In OvmfPkg none of these should be an issue. I think (well, actually, Paolo suggested it) that we should therefore enable the feature in OVMF. Yes, you are right about the reasons. BTW, in fact I made some test(write test code to load and start some module(for example, helloworld) to stack, then page fault came out with this feature enabled) based on qemu by Ovmf(IA32+IA32, IA32+X64, X64+X64) before sending out the patch. Nice! It's great that QEMU and OvmfPkg help you test new features! Hum, I should have included the test I did to the commit log. No, you should have included the OvmfPkg patch that you had already written in the series as 2/2. :) But, it's still not too late for that! :) Anyway, if you don't
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
Star, On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule] ## The number of bytes between registers in serial device. The default is 1 byte. # @Prompt Serial Port Register Stride in Bytes gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x0001006d - + + ## Indicates if to set NX for stack.BRBR + # For the DxeIpl and the DxeCore are both X64, set NX for stack feature also require PcdDxeIplBuildPageTables be TRUE.BR + # For the DxeIpl and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is FALSE), set NX for stack feature also require + # IA32 PAE is supported and Execute Disable Bit is available.BR + # TRUE - to set NX for stack.BR + # FALSE - Not to set NX for stack.BR + # @Prompt Set NX for stack. + gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x0001006f + Are there any restrictions for setting this PCD statically in a platform DSC file? Could it regress anything? In OVMF we have three DSC files: - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. If we set PcdSetNxForStack in this DSC file, will the code dynamically determine if the hardware has the necessary features, and fall back gracefully if it doesn't? - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is TRUE. This use case doesn't seem to be described in the .dec file above. Is this configuration compatible with PcdSetNxForStack=TRUE? - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. We don't change PcdDxeIplBuildPageTables from the default, but the default in MdeModulePkg/MdeModulePkg.dec is TRUE, and we inherit that. Can we set PcdSetNxForStack to TRUE, statically? Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
On 08/04/15 10:59, Zeng, Star wrote: -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 4, 2015 4:34 PM To: Zeng, Star Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support Star, On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule] ## The number of bytes between registers in serial device. The default is 1 byte. # @Prompt Serial Port Register Stride in Bytes gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00 01 006d - + + ## Indicates if to set NX for stack.BRBR # For the DxeIpl and + the DxeCore are both X64, set NX for stack feature also require + PcdDxeIplBuildPageTables be TRUE.BR # For the DxeIpl and the + DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is FALSE), set NX for stack feature also require # IA32 PAE is supported and Execute Disable Bit is available.BR + # TRUE - to set NX for stack.BR + # FALSE - Not to set NX for stack.BR + # @Prompt Set NX for stack. + + gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x 0001 + 006f + Are there any restrictions for setting this PCD statically in a platform DSC file? Could it regress anything? No. This feature require to build page table. More detailed explanation below. In OVMF we have three DSC files: - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. If we set PcdSetNxForStack in this DSC file, will the code dynamically determine if the hardware has the necessary features, and fall back gracefully if it doesn't? Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used to determine if the hardware has the necessary features. By default, 32BIT PEI+32BIT DXE do not need page table and PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both X64 as the comments in MdeModulePkg.dec. But this feature require page table, so (PcdGetBool (PcdSetNxForStack) IsIa32PaeSupport () IsExecuteDisableBitAvailable ()) is used to determine if building page table or not. Ah, I can see that in the patch. It gates the new Create4GPageTablesIa32Pae() function. - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is TRUE. This use case doesn't seem to be described in the .dec file above. Is this configuration compatible with PcdSetNxForStack=TRUE? Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special comments for it in MdeModulepkg.dec and just PcdGetBool (PcdSetNxForStack) is used to enable this feature or not in page table (Nx bit). Great. - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. We don't change PcdDxeIplBuildPageTables from the default, but the default in MdeModulePkg/MdeModulePkg.dec is TRUE, and we inherit that. Can we set PcdSetNxForStack to TRUE, statically? Of course YES. Thanks. The question emerges then: why doesn't PcdSetNxForStack default to true? I can see two possible reasons: - It is a new feature and causes changes in behavior. At worst, some firmware could even rely on executing code from the stack. That shouldn't be broken. - The code adds a new ASSERT(), and it could be triggered if the platform left PcdDxeIplBuildPageTables at FALSE. It's not nice to introduce code with potential to trigger an ASSERT() immediately, so this makes sense too. In OvmfPkg none of these should be an issue. I think (well, actually, Paolo suggested it) that we should therefore enable the feature in OVMF. I'll mark this discussion thread for later, so I can remember it, and maybe submit a patch for it. Jordan (or anyone else), please feel free to take a stab at it, if you'd like to :) Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
On 4 August 2015 at 10:54, Laszlo Ersek ler...@redhat.com wrote: On 08/04/15 09:57, Ard Biesheuvel wrote: LinuxLoader has been split off from the ARM BDS into a separate EFI application. Because we never included this application into the ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever since that change was merged. Let's fix the situation by: - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels have UEFI stub support enabled by default, and the LinuxLoader code for booting arm64 Linux kernels is buggy. Note that this does not disable the ARM BDS text menu, it just removes the ability to boot bare Linux kernels. - Adding the LinuxLoader EFI application to the ARM builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 9 ++--- ArmVirtPkg/ArmVirtQemu.dsc | 5 + ArmVirtPkg/ArmVirtQemu.fdf | 3 +++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 2e2708d1c281..735f9edc58d6 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION] PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf [LibraryClasses.common.UEFI_DRIVER] ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE +[PcdsFeatureFlag.AARCH64] + gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE + [PcdsFixedAtBuild.common] gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform @@ -398,9 +404,6 @@ [Components.common] NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf - ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf - FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf - SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index a2a82a4dba8c..92d55c770f55 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -381,3 +381,8 @@ [Components.common] MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf + +[Components.ARM] +!if $(INTEL_BDS) == FALSE + ArmPkg/Application/LinuxLoader/LinuxLoader.inf +!endif diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index 3c0487cd95b6..47f9b095b3af 100644 --- a/ArmVirtPkg/ArmVirtQemu.fdf +++ b/ArmVirtPkg/ArmVirtQemu.fdf @@ -177,6 +177,9 @@ [FV.FvMain] INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf !else INF ArmPlatformPkg/Bds/Bds.inf +!if $(ARCH) == ARM + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf +!endif !endif One question -- do we have any trick in place in ArmVirtPkg that allows us to find UEFI_APPLICATION modules in firmware volumes? I vaguely recall patches from the list that expose FVs as filesystems, or some such. If we use that in ArmVirtPkg, then it makes sense to build a UEFI_APPLICATION into the firmware binary; otherwise it doesn't. (The UEFI shell is located differently by the Intel BDS; the FILE_GUID of the shell binary is specified in PcdShellFile, and GenericBdsLib looks for it specifically.) Hm... yes, I think I have MdeModulePkg/Universal/FvSimpleFileSystemDxe in mind. We don't use it in ArmVirtPkg (nor OvmfPkg, FWIW). So, please either drop the FDF hunk, or include FvSimpleFileSystemDxe too in the build. (Or explain why I'm wrong :)) I think you're right. I fixed the ARM BDS menu, but booting an image using the LinuxLoader does not actually work after applying the patch. (Should have tested this more thoroughly, obviously). I will respin and add the FvSimpleFileSystemDxe to the ARM+ARM_BDS build ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: I have a related question. The EFI stub documentation (see [1]), seems to suggest that we have the support to boot the kernel Image, DTB and Rootfs when supplied as separate images to the EFI stub. However, other Bootloaders like u-boot are supporting newer FIT image format (see [2]), where these 3 images can be bundled into one and passed to the bootloader for verification (both crc as well as cryptographic checks) and loading. This is supported on both x86 and ARM platforms. At Freescale, we have a internal re-worked version of the ARM Bds Linux Loader, where we can parse a FIT format Linux image and load Linux using the same on ARM64 platforms. OK, first of all, I should point out that the ARM BDS does not adhere to the UEFI spec regarding booting removable media. This means that, as long as you use the ARM BDS, you will not be able to run OS installers that have their GRUB or kernel image in /EFI/BOOT/BOOTAA64.EFI, which is a default path defined by the spec. With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux Loader being deprecated, are there any plans to provide means to pass FIT format images via EFI_STUB to the ARM64 Linux kernel? No. FIT images are a U-Boot construct. The recommended way under UEFI is to install the device tree as a FDT configuration table in the firmware. Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI stub, by passing the initrd= option. The recommended way of doing authentication of bootable images is to use UEFI Secure Boot. DTB authentication is implicit if it is part of the UEFI image itself. How to do initrd authentication is undefined. Regards, Ard. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 04, 2015 1:27 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com Cc: ryan.har...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes LinuxLoader has been split off from the ARM BDS into a separate EFI application. Because we never included this application into the ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever since that change was merged. Let's fix the situation by: - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels have UEFI stub support enabled by default, and the LinuxLoader code for booting arm64 Linux kernels is buggy. Note that this does not disable the ARM BDS text menu, it just removes the ability to boot bare Linux kernels. - Adding the LinuxLoader EFI application to the ARM builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 9 ++--- ArmVirtPkg/ArmVirtQemu.dsc | 5 + ArmVirtPkg/ArmVirtQemu.fdf | 3 +++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 2e2708d1c281..735f9edc58d6 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION] PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.in f MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAlloc ationLib.inf HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf [LibraryClasses.common.UEFI_DRIVER] ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLib Framework/DxeReportStatusCodeLib.inf @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE +[PcdsFeatureFlag.AARCH64] + gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE + [PcdsFixedAtBuild.common] gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform @@ -398,9 +404,6 @@ [Components.common] NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comman dsLib.inf NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comman dsLib.inf HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLi b.inf - ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf - FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf - SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgComma ndLib.inf diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index a2a82a4dba8c..92d55c770f55 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++
Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
On 08/04/15 14:40, Ard Biesheuvel wrote: ARM BDS support in ArmVirtQemu has been broken since SVN r17969 (ArmPkg/BdsLib: Remove Linux loader from BdsLib) dated July 14th. Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader altogether: they violate both the UEFI spec and the arm64 Linux boot protocol, and lack the level of integration with the QEMU command line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader changes' that I sent out earlier today. After having discussed the matter on IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all agree that the best course of action is to drop the ARM BDS entirely. ArmVirtPkg/ArmVirtQemu.dsc | 17 + ArmVirtPkg/ArmVirtQemu.fdf | 6 -- 2 files changed, 1 insertion(+), 22 deletions(-) diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index c199cac72cfd..528d13e6aece 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -57,13 +57,11 @@ [LibraryClasses.common] TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf -!if $(INTEL_BDS) == TRUE CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf -!endif [LibraryClasses.common.UEFI_DRIVER] UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf @@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common] gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400 # - # ARM OS Loader - # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on virtio31:hd0:part0 - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 console=ttyAMA0 earlycon uefi_debug - - # - # Settings for ARM BDS -- use the serial console (ConIn ConOut). + # Settings for BDS -- use the serial console (ConIn ConOut). # !if $(TTY_TERMINAL) == TRUE gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94) The patch is good, but incomplete. You should remove more PCDs. I built ArmVirtQemu.dsc with and without INTEL_BDS. I instructed the build utility to write a report file for both builds, and then diffed the report files (the section entitled Platform Configuration Database Report). Clearly the token space that we care about now is gArmPlatformTokenSpaceGuid and gArmTokenSpaceGuid. The build report classifies the PCD settings that are not just plainly inherited from whichever .dec file: *P - Platform scoped PCD override in DSC file *F - Platform scoped PCD override in FDF file *M - Module scoped PCD override So we are looking for differences where a *P, *F, or *M disappears, from under the above two token spaces. (Disappearances of PCDs that we just used to inherit need no action.) ... Except when the explicit setting we have under ArmVirtPkg matches the default value from the .dec, because then *P is not added. So we do have to look at *all* differences in these two token spaces, and cross-ref them individually against our files. For gArmPlatformTokenSpaceGuid, this means: - PcdBdsLinuxSupport - PcdFirmwareVendor - PcdDefaultBootDescription - PcdDefaultBootDevicePath - PcdDefaultBootArgument - PcdDefaultConInPaths - PcdDefaultConOutPaths For gArmTokenSpaceGuid: - PcdMaxTftpFileSize Matches: ArmVirtPkg/ArmVirt.dsc.inc:282: gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform ArmVirtPkg/ArmVirtQemu.dsc:102: gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|QEMU ArmVirtPkg/ArmVirtQemu.dsc:133: gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on virtio31:hd0:part0 ArmVirtPkg/ArmVirtQemu.dsc:134: gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image ArmVirtPkg/ArmVirtQemu.dsc:135: gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 console=ttyAMA0 earlycon uefi_debug ArmVirtPkg/ArmVirtQemu.dsc:141: gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94) ArmVirtPkg/ArmVirtQemu.dsc:142:
Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
On 4 August 2015 at 16:50, Laszlo Ersek ler...@redhat.com wrote: On 08/04/15 16:34, Ard Biesheuvel wrote: On 4 August 2015 at 15:35, Laszlo Ersek ler...@redhat.com wrote: [...] I propose the following: - The Xen hit should be removed as a separate patch, as it has never been useful. (The Xen build uses Intel BDS exclusively.) OK - The rest of the PCDs (in ArmVirtQemu.dsc and in ArmVirt.dsc.inc) should be removed as part of this patch. In practice, those are: - PcdFirmwareVendor (both files) - PcdDefaultConOutPaths (two instances) - PcdDefaultConInPaths (two instance) After you remove these, only gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType remains in this context, so please refresh both the leading comment, and the TTY_TERMINAL-dependent comments just below it. (They make references to ConOut/ConIn, and Intel BDS being optional.) I will remove the comment, since it suggests that ConIn/ConOut is unused under the Intel BDS, but that is clearly not the case. You refer to - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths as being used by ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf That is correct. However, ArmVirtQemu.dsc does not resolve PlatformBdsLib to that instance; it uses ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf instead. Since your patch modifies ArmVirtQemu (where the ArmPlatformPkg library instance is unused), the PCDs should be removed. (The report files can be trusted about PCD usage.) The ArmPlatformPkg library instance is indeed used by ArmVirtXen, but the patch doesn't touch that file. OK, good. I got confused by the fact that nothing under ArmPlatformPkg/ actually uses this instance, but indeed, ArmVirtQemu has its own. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
-Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, August 04, 2015 2:01 PM On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: I have a related question. The EFI stub documentation (see [1]), seems to suggest that we have the support to boot the kernel Image, DTB and Rootfs when supplied as separate images to the EFI stub. However, other Bootloaders like u-boot are supporting newer FIT image format (see [2]), where these 3 images can be bundled into one and passed to the bootloader for verification (both crc as well as cryptographic checks) and loading. This is supported on both x86 and ARM platforms. At Freescale, we have a internal re-worked version of the ARM Bds Linux Loader, where we can parse a FIT format Linux image and load Linux using the same on ARM64 platforms. OK, first of all, I should point out that the ARM BDS does not adhere to the UEFI spec regarding booting removable media. This means that, as long as you use the ARM BDS, you will not be able to run OS installers that have their GRUB or kernel image in /EFI/BOOT/BOOTAA64.EFI, which is a default path defined by the spec. Agreed. With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux Loader being deprecated, are there any plans to provide means to pass FIT format images via EFI_STUB to the ARM64 Linux kernel? No. FIT images are a U-Boot construct. The recommended way under UEFI is to install the device tree as a FDT configuration table in the firmware. Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI stub, by passing the initrd= option. The recommended way of doing authentication of bootable images is to use UEFI Secure Boot. DTB authentication is implicit if it is part of the UEFI image itself. How to do initrd authentication is undefined. initrd (Rootfs) is probably the easiest place to introduce a malicious application in, which can easily overwrite the text area, thus causing the core to run a Trojan. The normal secure chain of boot, requires that each component verifies the next component it launches. FIT format seems to plug this gap. Can you point me to some documentation on UEFI secure boot and how it works on the ARM64 platforms - does it internally use and program the ARM TrustZone components like the TZASC and TZPC to partition the System RAM, etc into appropriate secure and non-secure partitions and the images cryptographically verify the next stage image. A typical flow most OEMs use is: BootROM - Arm Trusted Firmware - UEFI - Linux - Initrd The current SEC stage code for ARM64 platforms supported in EDK2 seem to be programming the TZASC and TZPC entities, but I cannot see any secure chain-of-trust being established for the next stage images there. Regards, Bhupesh Regards, Ard. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 04, 2015 1:27 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com Cc: ryan.har...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes LinuxLoader has been split off from the ARM BDS into a separate EFI application. Because we never included this application into the ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever since that change was merged. Let's fix the situation by: - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels have UEFI stub support enabled by default, and the LinuxLoader code for booting arm64 Linux kernels is buggy. Note that this does not disable the ARM BDS text menu, it just removes the ability to boot bare Linux kernels. - Adding the LinuxLoader EFI application to the ARM builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 9 ++--- ArmVirtPkg/ArmVirtQemu.dsc | 5 + ArmVirtPkg/ArmVirtQemu.fdf | 3 +++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 2e2708d1c281..735f9edc58d6 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION] PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceL PerformanceLib|ib.in f MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemory MemoryAllocationLib|Alloc ationLib.inf HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.in + f SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
-Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 4, 2015 4:34 PM To: Zeng, Star Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support Star, On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule] ## The number of bytes between registers in serial device. The default is 1 byte. # @Prompt Serial Port Register Stride in Bytes gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00 01 006d - + + ## Indicates if to set NX for stack.BRBR # For the DxeIpl and + the DxeCore are both X64, set NX for stack feature also require + PcdDxeIplBuildPageTables be TRUE.BR # For the DxeIpl and the + DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is FALSE), set NX for stack feature also require # IA32 PAE is supported and Execute Disable Bit is available.BR + # TRUE - to set NX for stack.BR + # FALSE - Not to set NX for stack.BR + # @Prompt Set NX for stack. + + gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x 0001 + 006f + Are there any restrictions for setting this PCD statically in a platform DSC file? Could it regress anything? No. This feature require to build page table. More detailed explanation below. In OVMF we have three DSC files: - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. If we set PcdSetNxForStack in this DSC file, will the code dynamically determine if the hardware has the necessary features, and fall back gracefully if it doesn't? Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used to determine if the hardware has the necessary features. By default, 32BIT PEI+32BIT DXE do not need page table and PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both X64 as the comments in MdeModulePkg.dec. But this feature require page table, so (PcdGetBool (PcdSetNxForStack) IsIa32PaeSupport () IsExecuteDisableBitAvailable ()) is used to determine if building page table or not. - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is TRUE. This use case doesn't seem to be described in the .dec file above. Is this configuration compatible with PcdSetNxForStack=TRUE? Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special comments for it in MdeModulepkg.dec and just PcdGetBool (PcdSetNxForStack) is used to enable this feature or not in page table (Nx bit). - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is FALSE. We don't change PcdDxeIplBuildPageTables from the default, but the default in MdeModulePkg/MdeModulePkg.dec is TRUE, and we inherit that. Can we set PcdSetNxForStack to TRUE, statically? Of course YES. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes
On 08/04/15 11:21, Sharma Bhupesh wrote: -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 04, 2015 2:36 PM On 08/04/15 10:38, Sharma Bhupesh wrote: -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, August 04, 2015 2:01 PM On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux Loader being deprecated, are there any plans to provide means to pass FIT format images via EFI_STUB to the ARM64 Linux kernel? No. FIT images are a U-Boot construct. The recommended way under UEFI is to install the device tree as a FDT configuration table in the firmware. Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI stub, by passing the initrd= option. The recommended way of doing authentication of bootable images is to use UEFI Secure Boot. DTB authentication is implicit if it is part of the UEFI image itself. How to do initrd authentication is undefined. (I'd say unspecified rather than undefined, but that's a side point.) initrd (Rootfs) is probably the easiest place to introduce a malicious application in, which can easily overwrite the text area, thus causing the core to run a Trojan. How is this different from overwriting applications on a normal file system? As far as I understand, applications are not part of the chain being verified. Cryptographically verifying the entire Root filesystem being provided with a software development kit, allows a OEM/customer to ensure that the platform only boots a application-set which is authenticated using their Public-Private key pairs. So, if the system tries to launch a rootfs which is not authenticated via the OEM/customer's public key, the boot process stalls and a preventive tamper-proofing action like zero'ing the DDR contents and reseting the SoC can be taken. I agree that this could be a useful configuration. But, if I understand correctly, this appears to belong with stuff that comes after the platform firmware. In the chain, each link tends to verify the next link. So, if blob-like authentication is necessary for the initial ramdisk, then I wonder if it should be the boot loader's (grub's, the EFI stub's, etc) responsibility to perform that check at load time. Maybe even the kernel (already verified) could itself authenticate the ramdisk image before mounting it. [Tue Aug 4 11:35:10 2015] Secure boot enabled ... [Tue Aug 4 11:35:11 2015] Unpacking initramfs... Thanks Laszlo Regards, Bhupesh Kernel modules are (and they do reside in the initrd), but they should already be covered by module signing. http://mjg59.dreamwidth.org/12368.html https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect- signing-kernel-modules-for-secure-boot.html https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se cboot.html https://www.suse.com/documentation/sles- 12/book_sle_admin/data/sec_uefi_secboot.html Thanks Laszlo The normal secure chain of boot, requires that each component verifies the next component it launches. FIT format seems to plug this gap. Can you point me to some documentation on UEFI secure boot and how it works on the ARM64 platforms - does it internally use and program the ARM TrustZone components like the TZASC and TZPC to partition the System RAM, etc into appropriate secure and non-secure partitions and the images cryptographically verify the next stage image. A typical flow most OEMs use is: BootROM - Arm Trusted Firmware - UEFI - Linux - Initrd The current SEC stage code for ARM64 platforms supported in EDK2 seem to be programming the TZASC and TZPC entities, but I cannot see any secure chain-of-trust being established for the next stage images there. Regards, Bhupesh Regards, Ard. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 04, 2015 1:27 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com Cc: ryan.har...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes LinuxLoader has been split off from the ARM BDS into a separate EFI application. Because we never included this application into the ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever since that change was merged. Let's fix the situation by: - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels have UEFI stub support enabled by default, and the LinuxLoader code for booting arm64 Linux kernels is buggy. Note that this does not disable the ARM BDS text menu, it just removes the ability to boot bare Linux kernels. - Adding the LinuxLoader EFI application to the ARM builds.
[edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build
The ARM build still needs an intermediate loader to boot Linux, since ARM/Linux has no builtin UEFI boot stub (yet). So add the LinuxLoader UEFI application to the FV, and enable the FvSimpleFileSystemDxe driver so that we can invoke the Linux loader from the shell, e.g., Shell linuxloader fs2:zImage -c console=ttyAMA0 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Reviewed-by: Laszlo Ersek ler...@redhat.com --- ArmVirtPkg/ArmVirt.dsc.inc | 6 +++--- ArmVirtPkg/ArmVirtQemu.dsc | 9 + ArmVirtPkg/ArmVirtQemu.fdf | 5 + 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index ced45c8194bc..7bba6eba05a8 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION] PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf [LibraryClasses.common.UEFI_DRIVER] ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf @@ -396,9 +399,6 @@ [Components.common] NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf - ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf - FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf - SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 5a644090be7c..61e95517259c 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -354,3 +354,12 @@ [Components.common] MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf + +[Components.ARM] + # + # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need + # an intermediate OS loader. Add the LinuxLoader UEFI application so we can + # invoke it from the shell. + # + MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf + ArmPkg/Application/LinuxLoader/LinuxLoader.inf diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index a9ad9ca6fe2d..6faf3bc12172 100644 --- a/ArmVirtPkg/ArmVirtQemu.fdf +++ b/ArmVirtPkg/ArmVirtQemu.fdf @@ -237,6 +237,11 @@ [FV.FvMain] SECTION RAW = MdeModulePkg/Logo/Logo.bmp } +!if $(ARCH) == ARM + INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf +!endif + [FV.FVMAIN_COMPACT] FvAlignment= 16 ERASE_POLARITY = 1 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS
This series is a followup to the patches 'ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default' and 'ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build' that I sent out earlier today. (The former was itself a replacement for 'ArmVirtPkg: align ARM BDS build with LinuxLoader changes', part of which has been brought back in patch #3 of this series) The ARM BDS currently depends on the LinuxLoader UEFI application to be present in an FV, and it to be loadable and executable via the protocols installed by FvSimpleFileSystemDxe. The current ArmVirtQemu builds lack both the UEFI application and the filesystem driver, and so these builds have been broken ever since the LinuxLoader was split off into a separate application. The LinuxLoader for AARCH64 is buggy and violates the arm64 boot protocol, and the ARM BDS violates the UEFI spec. So instead of restoring the ARM BDS to working order, we drop it completely from the ArmVirtQemu platform. (patch #1) In patch #2, we remove a copy-pasted ARM BDS related PCD definition from the Xen build that has never been used, as the Xen build is Intel BDS only. Patch #3 adds support for the Linux loader to the ARM build of ArmVirtQemu when running the Intel BDS. The LinuxLoader for 32-bit ARM implements the boot protocol correctly (although some patches are pending to improve it in some areas), and is actually required to boot a Linux kernel at all since the ARM/Linux kernel has no UEFI stub support (yet). Ard Biesheuvel (3): ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build ArmVirtPkg/ArmVirt.dsc.inc | 11 ++ ArmVirtPkg/ArmVirtQemu.dsc | 41 ++-- ArmVirtPkg/ArmVirtQemu.fdf | 9 ++--- ArmVirtPkg/ArmVirtXen.dsc | 1 - 4 files changed, 19 insertions(+), 43 deletions(-) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD
The PcdFirmwareVendor PCD was never used on this platform, since it has never supported the ARM BDS. So remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirtXen.dsc | 1 - 1 file changed, 1 deletion(-) diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc index b4007ff3c6a4..06c0003ae893 100644 --- a/ArmVirtPkg/ArmVirtXen.dsc +++ b/ArmVirtPkg/ArmVirtXen.dsc @@ -79,7 +79,6 @@ [BuildOptions] [PcdsFixedAtBuild.common] - gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|XEN-UEFI gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L$(FIRMWARE_VER) gArmPlatformTokenSpaceGuid.PcdCoreCount|1 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 4/9] ArmVirtPkg: revert ArmVirtPkg: add QemuFwCfgToPcdDxe
On 31 July 2015 at 20:40, Laszlo Ersek ler...@redhat.com wrote:
This reverts git commit d2733aa9 (SVN r18042), because it is empty now.
The original problem:
Many universal DXE drivers in edk2 can be controlled by setting dynamic
PCDs. Such a PCD must be set before the consumer DXE driver is
dispatched.
should be hereafter solved similarly to how
OvmfPkg/Library/SmbiosVersionLib is plugged into
MdeModulePkg/Universal/SmbiosDxe now (originally suggested by Jordan
Justen jordan.l.jus...@intel.com).
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: Wei Huang w...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf | 42
ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c | 33 ---
ArmVirtPkg/ArmVirtQemu.dsc | 1 -
ArmVirtPkg/ArmVirtQemu.fdf | 2 -
4 files changed, 78 deletions(-)
diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
deleted file mode 100644
index a9983be..000
--- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
+++ /dev/null
@@ -1,42 +0,0 @@
-## @file
-# An early DXE driver that parses well-known fw-cfg files into dynamic
PCDs
-# that control other (universal) DXE drivers.
-#
-# Copyright (C) 2015, Red Hat, Inc.
-# Copyright (c) 2014, Linaro Ltd. All rights reserved.BR
-#
-# This program and the accompanying materials are licensed and made
available
-# under the terms and conditions of the BSD License which accompanies this
-# distribution. The full text of the license may be found at
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
-# IMPLIED.
-#
-##
-
-[Defines]
- INF_VERSION= 0x00010005
- BASE_NAME = QemuFwCfgToPcdDxe
- FILE_GUID = 5bb7cc92-1a36-4833-84cf-db7f8258e48d
- MODULE_TYPE= DXE_DRIVER
- VERSION_STRING = 1.0
- ENTRY_POINT= ParseQemuFwCfgToPcd
-
-[Sources]
- QemuFwCfgToPcd.c
-
-[Packages]
- MdePkg/MdePkg.dec
- OvmfPkg/OvmfPkg.dec
-
-[LibraryClasses]
- PcdLib
- QemuFwCfgLib
- UefiDriverEntryPoint
-
-[Pcd]
-
-[Depex]
- TRUE
diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
deleted file mode 100644
index 8f60e21..000
--- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/** @file
-* An early DXE driver that parses well-known fw-cfg files into dynamic
PCDs
-* that control other (universal) DXE drivers.
-*
-* Copyright (C) 2015, Red Hat, Inc.
-* Copyright (c) 2014, Linaro Ltd. All rights reserved.BR
-*
-* This program and the accompanying materials are licensed and made
available
-* under the terms and conditions of the BSD License which accompanies this
-* distribution. The full text of the license may be found at
-* http://opensource.org/licenses/bsd-license.php
-*
-* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
-* IMPLIED.
-*
-**/
-
-#include Uefi/UefiBaseType.h
-#include Uefi/UefiSpec.h
-
-#include Library/PcdLib.h
-#include Library/QemuFwCfgLib.h
-
-EFI_STATUS
-EFIAPI
-ParseQemuFwCfgToPcd (
- IN EFI_HANDLE ImageHandle,
- IN EFI_SYSTEM_TABLE *SystemTable
- )
-{
- return EFI_SUCCESS;
-}
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 00571d4..618a158 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -316,7 +316,6 @@ [Components.common]
# Platform Driver
#
ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
- ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/VirtioNetDxe/VirtioNet.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 3c0487c..f378da5 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -104,12 +104,10 @@ [FV.FvMain]
APRIORI DXE {
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
-INF ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
}
INF MdeModulePkg/Core/Dxe/DxeMain.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
- INF ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
#
# PI DXE Drivers producing Architectural Protocols (EFI Services)
--
1.8.3.1
___
edk2-devel mailing list
Re: [edk2] HID descriptor parsing
UsbKbDxe driver in MdeModulePkg/Bus/Usb handles usb key board devices. Note we don’t parse its HID descriptor in this driver, we only use SET_REPORT request to enable Keyboard’s LED. If you need to parse HID items, you can refer to the logic in usb mouse driver and write a new one. PS: UefiUsbLib in MdePkg/Library provides some library APIs to provide HID services. From: cruxpot [mailto:crux...@gmail.com] Sent: Wednesday, August 05, 2015 05:10 To: Tian, Feng Cc: Ulysses Mckibbens; edk2-de...@lists.sourceforge.net Subject: Re: [edk2] HID descriptor parsing Hi Tian, Which driver handles the keyboard devices? we did see that in the mouse driver. On Aug 3, 2015 6:08 PM, Tian, Feng feng.t...@intel.commailto:feng.t...@intel.com wrote: UsbBusDxe driver is a bus driver who is used to enumerate attached devices and start their corresponding device drivers. So you couldn’t see HID parser in UsbBus driver. You have to see it in usb device drivers. UsbMouseDxe/MouseHid.c is such sample for how parsing HID items. From: Ulysses Mckibbens [mailto:zergrusher2...@gmail.commailto:zergrusher2...@gmail.com] Sent: Tuesday, August 04, 2015 00:20 To: edk2-de...@lists.sourceforge.netmailto:edk2-de...@lists.sourceforge.net Subject: [edk2] HID descriptor parsing Hi, Where is the HID descriptor parsed in the UsbBusDxe driver? I am using a Minnowboard Max with 0.81 firmware and I am trying to debug the HID descriptor attributes for a device I'm writing a driver for. Any pointers? -- ___ edk2-devel mailing list edk2-de...@lists.sourceforge.netmailto:edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in AsciiStrCpyS()
The 2nd parameter in AsciiStrCpyS() should be the max available
memory of the destination.
Cc: Fu Siyuansiyuan...@intel.com
Cc: Ye Tingting...@intel.com
CC: Wu Jiaxin jiaxin...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo lubo.zh...@intel.com
---
NetworkPkg/Mtftp6Dxe/Mtftp6Support.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
index 20888e8..c31fc9d 100644
--- a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
+++ b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
@@ -600,11 +600,11 @@ Mtftp6SendError (
}
TftpError-OpCode = HTONS (EFI_MTFTP6_OPCODE_ERROR);
TftpError-Error.ErrorCode = HTONS (ErrCode);
- AsciiStrCpyS ((CHAR8 *) TftpError-Error.ErrorMessage, sizeof
(TftpError-Error.ErrorMessage) / sizeof (TftpError-Error.ErrorMessage[0]),
(CHAR8 *) ErrInfo);
+ AsciiStrCpyS ((CHAR8 *) TftpError-Error.ErrorMessage, AsciiStrLen ((CHAR8
*) ErrInfo) + 1 , (CHAR8 *) ErrInfo);
//
// Save the packet buf for retransmit
//
if (Instance-LastPacket != NULL) {
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How to update an App Lib dependency ?
Why do you need to do the copy operation? EDKII Build system could ensure this dependency. Please read EDKII module writer's guide at first (https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-User-Documentation) Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shubha Ramani Sent: Wednesday, August 05, 2015 00:50 To: edk2-devel@lists.01.org Subject: [edk2] How to update an App Lib dependency ? Hello there. I have built a lib under C:\edk2\MyWorkspace\MdeModulePkg\Library and an Application which consumes that library under C:\edk2\MyWorkspace\MdeModulePkg\Application. If I change code in the lib, how can I make sure that the rebuilt App gets the latest lib ? I usually manuallycopy the static lib file from C:\edk2\MyWorkspace\Build\DuetPkgX64\RELEASE_VS2012x86\X64\MdeModulePkg\Libraryinto the Application folder. I know there's got to be a better way. Do we add a post-build rule to automatically copy the lib file from directory1 to directory2 ? If so, can you tell me how this is done ? Thanks, Shubha Shubha D. Ramani ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Check arguments for PrintLib format format string
Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]Sent: Tuesday, August 04, 2015 09:01 AM ]To: Scott Duplichan sc...@notabs.org ]Cc: 'edk2-devel@lists.01.org' edk2-de...@ml01.01.org; 'Andrew Fish' af...@apple.com ]Subject: Re: [edk2] [PATCH] Check arguments for PrintLib format format string ] ]On 08/04/15 03:19, Scott Duplichan wrote: ] Andrew Fish [mailto:af...@apple.com] wrote: ] ] ]Sent: Monday, August 03, 2015 04:48 PM ] ]To: Scott Duplichan sc...@notabs.org ] ]Cc: edk2-devel@lists.01.org edk2-de...@ml01.01.org; Laszlo Ersek ler...@redhat.com ] ]Subject: Re: [edk2] [PATCH] Check arguments for PrintLib format format string ] ] ] ] ] ] On Aug 2, 2015, at 9:58 PM, Scott Duplichan sc...@notabs.org wrote: ] ] ] ] Add support for checking the argument list of functions that use ] ] a PrintLib style format string. This feature requires a patched ] ] gcc tool chain that is identified by the presence of compiler ] ] predefined macro __GCC_EDK2_FORMATS__. To enable format string ] ] checking, use a patched gcc tool chain and define the macro ] ] EDK2_FORMAT_CHECKING. ] ] ] ] ] ]Scott, ] ] ] ] +// ] ] +#if defined(EDK2_FORMAT_CHECKING) ] ] ] ]Is this an external flag? Why not just use __GCC_EDK2_FORMATS__, if that is what the compiler adds? ] ]This feature could get added to other compilers in the future... ] ] Good points. Yes, I am setting EDK2_FORMAT_CHECKING externally. Here is how I run a ] batch mode build test: ] ] D:\edk2build set GCC_EXTRA_CC_FLAGS=-DEDK2_FORMAT_CHECKING -Wno-error ] D:\edk2build buildall-gcc49.bat ] ] The first command sets an environment variable who's contents are appended ] to the GCC CC flags. This relies on a recently submitted (and rejected) ] patch: BaseTools: Add mechanism to override or add CC_FLAGS ] ] I actually modified that patch slightly because it assumed the presence ] of the recently submitted but not approved GCC Link Time Optimization ] patch. The revised patch is gcc_extra_cc_flags_08-02-2015.patch from: ] http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Tool%20Chain%]20Support/gcc/ ] ] To answer your question Why not just use __GCC_EDK2_FORMATS__. ] With format checking enabled, a batch EDK2 build I use to check for ] breakage produces 1,049 unique cases of -Wformat warnings. So we need ] a way to turn the new warnings off so that a build can complete without ] suppressing the 'warning as error' policy. The patch is using the ] compiler macro EDK2_FORMAT_CHECKING. But there is a way to ] enable/disable format checking that does use a flag: Use two separate ] GCC49 tool chains. One standard, and one with the EDK2 format checking ] patch applied. These libraryless gcc tool chains are quite small and ] keeping more of them is not unreasonable. ] ] ] ] + #if !defined(__GCC_EDK2_FORMATS__) ] ] +#error EDK2_FORMAT_CHECKING is not supported by this tool chain ] ] + #else ] ] +#define EFIFORMAT(FormatType, FormatPosition) \ ] ] +__attribute__((format (FormatType, FormatPosition, FormatPosition+1))) ] ] + #endif ] ] +#else ] ] + #define EFIFORMAT(FormatType, FormatPosition) ] ] +#endif ] ] ] ]I don’t have an issue with adding the more generic EFIFORMAT() macro, but it would be more general ]to ]hide the 1st argument to __attribtue__ ((format, …)) as that is implementation specific. ] ]So maybe: ] ]#define EFI_PRINT_FORMAT(FormatPossition) EFIFORMAT(edk2_printf, FormatPossition) ] ] That is actually what I wanted to do. But then I encountered the %N, %H, %E, ] %B, %V extensions of function ShellPrintEx. My first idea for accommodating ] the Shell Extensions was to use an optional macro argument for this single case. ] But that requires complex macro logic. The next solution I considered was a pair ] of macros: one for EDK2 standard formats and one for EDK2 formats with Shell Print ] Extensions. Though that is probably the best answer, I couldn't think of a good ] pair of macro names. Maybe EFIFORMAT/EFIFORMAT_SHELL would be OK. If you can ] suggest a pair of names, I could resubmit the patch using them. ] ] ]So if this every gets added to clang, or VC++ (via SAL Annotations?) it does not blow up if the ]edk2_printf name is not used. ] ] Yes. So all we need is a way to handle the special case of function ShellPrintEx ] and then the only macro argument needed is a single one that identifies which ] function argument passes the format string. ] ] The one remaining issue is how to temporarily suppress the 'warning as error' ] policy. With 1,049 unique cases to fix, the need for suppressing 'warning as ] error' is apparent. Without doing so, you can see only one error at a time and ] that error must be fixed before the next can be seen. I fear that if there is ] no simple way to make a format checking enabled build run to completion, then ] no one will actually try or use this patch. ] ]I agree. Last time you posted the OvmfPkg format warnings, I relied on ]them having been provided in a batch format. ]
[edk2] How to update an App Lib dependency ?
Hello there. I have built a lib under C:\edk2\MyWorkspace\MdeModulePkg\Library and an Application which consumes that library under C:\edk2\MyWorkspace\MdeModulePkg\Application. If I change code in the lib, how can I make sure that the rebuilt App gets the latest lib ? I usually manuallycopy the static lib file from C:\edk2\MyWorkspace\Build\DuetPkgX64\RELEASE_VS2012x86\X64\MdeModulePkg\Libraryinto the Application folder. I know there's got to be a better way. Do we add a post-build rule to automatically copy the lib file from directory1 to directory2 ? If so, can you tell me how this is done ? Thanks, Shubha Shubha D. Ramani ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build
On 4 August 2015 at 17:21, Ard Biesheuvel ard.biesheu...@linaro.org wrote: The ARM build still needs an intermediate loader to boot Linux, since ARM/Linux has no builtin UEFI boot stub (yet). So add the LinuxLoader UEFI application to the FV, and enable the FvSimpleFileSystemDxe driver so that we can invoke the Linux loader from the shell, e.g., Shell linuxloader fs2:zImage -c console=ttyAMA0 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Reviewed-by: Laszlo Ersek ler...@redhat.com --- ArmVirtPkg/ArmVirt.dsc.inc | 6 +++--- ArmVirtPkg/ArmVirtQemu.dsc | 9 + ArmVirtPkg/ArmVirtQemu.fdf | 5 + 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index ced45c8194bc..7bba6eba05a8 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION] PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf [LibraryClasses.common.UEFI_DRIVER] ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf @@ -396,9 +399,6 @@ [Components.common] NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf - ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf - FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf - SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 5a644090be7c..61e95517259c 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -354,3 +354,12 @@ [Components.common] MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf + +[Components.ARM] + # + # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need + # an intermediate OS loader. Add the LinuxLoader UEFI application so we can + # invoke it from the shell. + # + MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf + ArmPkg/Application/LinuxLoader/LinuxLoader.inf This needs +LibraryClasses + BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf since I removed the common BdsLib resolution from ArmVirt.dsc.inc in patch #1. I will just add that when committing, unless anyone feels I need to repost. -- Ard. diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index a9ad9ca6fe2d..6faf3bc12172 100644 --- a/ArmVirtPkg/ArmVirtQemu.fdf +++ b/ArmVirtPkg/ArmVirtQemu.fdf @@ -237,6 +237,11 @@ [FV.FvMain] SECTION RAW = MdeModulePkg/Logo/Logo.bmp } +!if $(ARCH) == ARM + INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf +!endif + [FV.FVMAIN_COMPACT] FvAlignment= 16 ERASE_POLARITY = 1 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS
On 4 August 2015 at 17:21, Ard Biesheuvel ard.biesheu...@linaro.org wrote: This series is a followup to the patches 'ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default' and 'ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build' that I sent out earlier today. (The former was itself a replacement for 'ArmVirtPkg: align ARM BDS build with LinuxLoader changes', part of which has been brought back in patch #3 of this series) The ARM BDS currently depends on the LinuxLoader UEFI application to be present in an FV, and it to be loadable and executable via the protocols installed by FvSimpleFileSystemDxe. The current ArmVirtQemu builds lack both the UEFI application and the filesystem driver, and so these builds have been broken ever since the LinuxLoader was split off into a separate application. The LinuxLoader for AARCH64 is buggy and violates the arm64 boot protocol, and the ARM BDS violates the UEFI spec. So instead of restoring the ARM BDS to working order, we drop it completely from the ArmVirtQemu platform. (patch #1) In patch #2, we remove a copy-pasted ARM BDS related PCD definition from the Xen build that has never been used, as the Xen build is Intel BDS only. Patch #3 adds support for the Linux loader to the ARM build of ArmVirtQemu when running the Intel BDS. The LinuxLoader for 32-bit ARM implements the boot protocol correctly (although some patches are pending to improve it in some areas), and is actually required to boot a Linux kernel at all since the ARM/Linux kernel has no UEFI stub support (yet). Ard Biesheuvel (3): ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build Committed as SVN r18153 .. r18155 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] ArmVirtPkg/ArmVirtXen: add missing BdsLib instance
Now that the ARM BDS has been removed, there is a remaining BdsLib dependency in ArmVirtXen that has now become unresolved. So re-add the BdsLib resolution that we removed from ArmVirt.dsc.inc to ArmVirtXen.dsc Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- Committing as a build fix after my SVN r18153 has broken the build ArmVirtPkg/ArmVirtXen.dsc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc index 06c0003ae893..5c19afca30b9 100644 --- a/ArmVirtPkg/ArmVirtXen.dsc +++ b/ArmVirtPkg/ArmVirtXen.dsc @@ -58,6 +58,8 @@ [LibraryClasses.common] PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf + BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf + [LibraryClasses.common.UEFI_DRIVER] UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/3] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
On 08/04/15 17:21, Ard Biesheuvel wrote: ARM BDS support in ArmVirtQemu has been broken since SVN r17969 (ArmPkg/BdsLib: Remove Linux loader from BdsLib) dated July 14th. Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader altogether: they violate both the UEFI spec and the arm64 Linux boot protocol, and lack the level of integration with the QEMU command line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 5 +-- ArmVirtPkg/ArmVirtQemu.dsc | 32 ++-- ArmVirtPkg/ArmVirtQemu.fdf | 6 3 files changed, 3 insertions(+), 40 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 8c54242b597b..ced45c8194bc 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -106,8 +106,7 @@ [LibraryClasses.common] DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf - # BDS Libraries - BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf + # Flattened Device Tree (FDT) access library FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf # PCI Libraries @@ -279,8 +278,6 @@ [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE [PcdsFixedAtBuild.common] - gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform - gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100 gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100 gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index c199cac72cfd..5a644090be7c 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -57,13 +57,11 @@ [LibraryClasses.common] TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf -!if $(INTEL_BDS) == TRUE CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf -!endif [LibraryClasses.common.UEFI_DRIVER] UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf @@ -99,8 +97,6 @@ [PcdsFeatureFlag.common] gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE [PcdsFixedAtBuild.common] - gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|QEMU - gArmPlatformTokenSpaceGuid.PcdCoreCount|1 !if $(ARCH) == AARCH64 gArmTokenSpaceGuid.PcdVFPEnabled|1 @@ -127,29 +123,11 @@ [PcdsFixedAtBuild.common] ## PL011 - Serial Terminal gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400 - # - # ARM OS Loader - # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on virtio31:hd0:part0 - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 console=ttyAMA0 earlycon uefi_debug - - # - # Settings for ARM BDS -- use the serial console (ConIn ConOut). - # -!if $(TTY_TERMINAL) == TRUE - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94) - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94) - ## Terminal Type - TTYTERM, consistent with ConOut/ConIn Device Path. + ## Default Terminal Type ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM +!if $(TTY_TERMINAL) == TRUE gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4 !else - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100() - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100() - ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path. - ## When Intel BDS is enabled, the above ConOut/ConIn device path is useless, - ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE. - ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1 !endif gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 @@ -175,10 +153,8 @@ [PcdsFixedAtBuild.common] # initial location of the device tree blob passed by QEMU -- base of DRAM
Re: [edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD
On 08/04/15 17:21, Ard Biesheuvel wrote: The PcdFirmwareVendor PCD was never used on this platform, since it has never supported the ARM BDS. So remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirtXen.dsc | 1 - 1 file changed, 1 deletion(-) diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc index b4007ff3c6a4..06c0003ae893 100644 --- a/ArmVirtPkg/ArmVirtXen.dsc +++ b/ArmVirtPkg/ArmVirtXen.dsc @@ -79,7 +79,6 @@ [BuildOptions] [PcdsFixedAtBuild.common] - gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|XEN-UEFI gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L$(FIRMWARE_VER) gArmPlatformTokenSpaceGuid.PcdCoreCount|1 Reviewed-by: Laszlo Ersek ler...@redhat.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in AsciiStrCpyS()
Reviewed-by: Jiaxin Wu jiaxin...@intel.com
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang
Lubo
Sent: Wednesday, August 5, 2015 10:04 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in
AsciiStrCpyS()
The 2nd parameter in AsciiStrCpyS() should be the max available memory of the
destination.
Cc: Fu Siyuansiyuan...@intel.com
Cc: Ye Tingting...@intel.com
CC: Wu Jiaxin jiaxin...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo lubo.zh...@intel.com
---
NetworkPkg/Mtftp6Dxe/Mtftp6Support.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
index 20888e8..c31fc9d 100644
--- a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
+++ b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
@@ -600,11 +600,11 @@ Mtftp6SendError (
}
TftpError-OpCode = HTONS (EFI_MTFTP6_OPCODE_ERROR);
TftpError-Error.ErrorCode = HTONS (ErrCode);
- AsciiStrCpyS ((CHAR8 *) TftpError-Error.ErrorMessage, sizeof
(TftpError-Error.ErrorMessage) / sizeof (TftpError-Error.ErrorMessage[0]),
(CHAR8 *) ErrInfo);
+ AsciiStrCpyS ((CHAR8 *) TftpError-Error.ErrorMessage, AsciiStrLen
+ ((CHAR8 *) ErrInfo) + 1 , (CHAR8 *) ErrInfo);
//
// Save the packet buf for retransmit
//
if (Instance-LastPacket != NULL) {
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
