Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread David Woodhouse
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 0/3] Use new BDS and UiApp for OvmfPkg

2015-08-04 Thread Laszlo Ersek
On 08/04/15 12:42, David Woodhouse wrote:
 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.

Okay, if you don't have your guests any longer, I guess I can add this
to the end of my queue too.

Thanks
Laszlo

 
 
 
 ___
 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

2015-08-04 Thread David Woodhouse
On Tue, 2015-08-04 at 13:07 +0200, Laszlo Ersek wrote:
 On 08/04/15 12:42, David Woodhouse wrote:
  Then (if the BDS gets it right) you should be able to boot legacy
  targets as well as native UEFI targets.
 
 Okay, if you don't have your guests any longer, I guess I can add 
 this to the end of my queue too.

I do still have an OS zoo which I can use for CSM testing. That was
more useful for the actual CSM functionality though — catching ACPI
compatibility issues and timer breakage and other things.

It's less useful for the simple case of BDS testing, where if it
*starts* trying to boot the correct OS you probably haven't broken it
(and hell, if it offers you the *option* of a Legacy boot from a given
target you're most of the way there).

I certainly can do some more testing though.

-- 
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


[edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

2015-08-04 Thread Ard Biesheuvel
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)
@@ -175,10 +166,8 @@ [PcdsFixedAtBuild.common]
   # initial location of the device tree blob passed by QEMU -- base of DRAM
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-!endif
 
   #
   # The maximum physical I/O addressability of the processor, set with
@@ -332,13 +321,9 @@ [Components.common]
   # Bds
   #
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # SCSI Bus and Disk Driver
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 3c0487cd95b6..a9ad9ca6fe2d 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -171,13 +171,9 @@ [FV.FvMain]
   # Bds
   #
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  INF ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # Networking stack
@@ -234,14 +230,12 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 
-!if $(INTEL_BDS) == TRUE
   #
   # TianoCore logo (splash screen)
   #
   FILE FREEFORM = PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
-!endif
 
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
-- 
1.9.1

___
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

2015-08-04 Thread Sharma Bhupesh
 -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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Laszlo Ersek
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] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

2015-08-04 Thread Laszlo Ersek
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.

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_secboot.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]

 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

  [LibraryClasses.common.UEFI_DRIVER]

 ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCo
 ReportStatusCodeLib|deLib
 Framework/DxeReportStatusCodeLib.inf
 @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]

gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE

 +[PcdsFeatureFlag.AARCH64]
 +  

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Sharma Bhupesh
 -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

2015-08-04 Thread Zeng, Star
 -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] MdeModulePkg DxeIpl: Add stack NX support

2015-08-04 Thread Zeng, Star
 -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.
Hum, I should have included the test I did to the commit log.

 
 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 

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Ard Biesheuvel
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 1/3] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

2015-08-04 Thread Ard Biesheuvel
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
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE
   

[edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Ard Biesheuvel
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] [PATCH 6/9] ArmVirtPkg/ArmVirtQemu.dsc: set default for PcdQemuSmbiosValidated

2015-08-04 Thread Ard Biesheuvel
On 31 July 2015 at 20:40, Laszlo Ersek ler...@redhat.com wrote:
 The upcoming OvmfPkg patches will implicitly affect the ArmVirtQemu.dsc
 build, necessitating a default value for the new dynamic
 PcdQemuSmbiosValidated. Add it.

 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/ArmVirtQemu.dsc | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 618a158..8c842c7 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -237,6 +237,7 @@ [PcdsDynamicDefault.common]
# SMBIOS entry point version
#
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
 +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE

  
 
  #
 --
 1.8.3.1


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] HID descriptor parsing

2015-08-04 Thread Tian, Feng
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()

2015-08-04 Thread Zhang Lubo
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 ?

2015-08-04 Thread Tian, Feng
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

2015-08-04 Thread Scott Duplichan
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 ?

2015-08-04 Thread Shubha Ramani
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Ard Biesheuvel
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

2015-08-04 Thread Ard Biesheuvel
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


[edk2] ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

2015-08-04 Thread Shah, Tapan
Jaben / Shumin,
   Can you review this one-line fix?

Thanks,
Tapan


ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off by: Tapan Shah tapands...@hp.commailto:tapands...@hp.com
Reviewed-by: Chris Phillips chr...@hp.commailto:chr...@hp.com

___
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

2015-08-04 Thread Laszlo Ersek
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

2015-08-04 Thread Laszlo Ersek
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()

2015-08-04 Thread Wu, Jiaxin
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