date:20140709

Re: [edk2] how to set default boot path to hard disk?

2014-07-09 Thread Ganapatrao Kulkarni

thanks Andrew.

If i use as you said
HD(1,GPT,E3AE6975-BACE-464E-
91E1-BB4FE9954047,0x800,0x31801)/\EFI\BOOT\BOOTAA64.EFI”

grub enter rescue mode.
it is happening since grub is getting loaded, however the prefix and root
are not set properly.
if i set manually, then normal command works.

log:

The default boot selection will start in   1 seconds
Welcome to GRUB!

error: disk `,gpt2' not found.
Entering rescue mode...
grub rescue> insmod normal
error: disk `,gpt2' not found.
grub rescue> set
prefix=(,gpt2)/boot/grub
root=,gpt2
grub rescue> set root=hd0,gpt2
grub rescue> set prefix=(hd0,gpt2)/boot/grub
grub rescue> insmod normal
grub rescue> set
color_highlight=black/light-gray
color_normal=light-gray/black
feature_200_final=y
feature_all_video_module=y
feature_chainloader_bpb=y
feature_default_font_path=y
feature_menuentry_id=y
feature_menuentry_options=y
feature_nativedisk_cmd=y
feature_ntldr=y
feature_platform_search_hint=y
feature_timeout_style=y
grub_cpu=arm64
grub_platform=efi
lang=
locale_dir=
pager=
prefix=(hd0,gpt2)/boot/grub
root=hd0,gpt2
secondary_locale_dir=
grub rescue>


thanks
ganapat




On Thu, Jun 19, 2014 at 11:13 AM, Andrew Fish  wrote:

>
> On Jun 18, 2014, at 10:06 PM, Ganapatrao Kulkarni 
> wrote:
>
> > Hi All,
> >
> > I am trying to boot GRUB present at HARD-DISK connected over PCI and in
> AHCI mode.
> > I am able to boot by setting default boot path as below.
> >
> >
> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,E3AE6975-BACE-464E-91E1-BB4FE9954047,0x800,0x31801)/\EFI\BOOT\BOOTAA64.EFI"
> >
> > however, i see the Partition GUID(Partition unique GUID:
> E3AE6975-BACE-464E-91E1-BB4FE9954047) which is part of path changes when
> ever hard disk is repartitioned or created with partition.
> >
> > are there any other way to set the default boot path which is consistent
> and not depends on GUID.
> >
>
> No but you can form the device path like:
> HD(1,GPT,E3AE6975-BACE-464E-91E1-BB4FE9954047,0x800,0x31801)/\EFI\BOOT\BOOTAA64.EFI”
> so that if the hard disk is moved around in the system you can still boot
> from it.
>
> There is no concept of C: or a magic sector in GPT. The 3rd party MBR boot
> managers where causing chaos back in the day as the all tried to grab the
> same hidden sectors on the disk. Also moving a disks location caused the
> system to fail to boot. So GPT was design to solve those problems. There is
> nothing on the disk that that indicates what is bootable, that info is
> stored in EFI NVRAM as it is platform policy.
>
> So when you install a new OS on your system you need to run some kind of
> install program to set the EFI NVRAM boot variable.
>
> The BDS processes the EFI boot variables, and it looks like that PCD is
> used to set a default value. What happens if no bootable variables resolve
> is platform policy. So you could implement a custom boot manager that does
> some magic. For example you could define a PartitionTypeGUID that
> represents an EFI Application (OS Loader) that helps the user select which
> partition on the disk should be bootable. Or you could set the platform
> policy to network boot if the hard drive boot fails, and have the system
> run an EFI Application that helps you setup (or provision) the boot options.
>
> Thanks,
>
> Andrew Fish
>
> > thanks
> > Ganapat
> >
> >
> >
> --
> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> > Find What Matters Most in Your Big Data with HPCC Systems
> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> >
> http://p.sf.net/sfu/hpccsystems___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis

Re: [edk2] Entry Point for SEC -> PEI Transition

2014-07-09 Thread Olivier Martin

Hi Varad,
Why do you want to you want to use SEC? Why x-loader do not directly jump to
PrePeiCore?
I was told you have a JTAG. Check you have a 'BL 0x.' at the base
address of your FV file 0x80048000.
This jump address should be the entrypoint of your PrePeiCore module.
Thanks,
Olivier

> -Original Message-
> From: Varad Gautam [mailto:varadgau...@gmail.com]
> Sent: 08 July 2014 18:02
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Entry Point for SEC -> PEI Transition
> 
> Hi Olivier,
> 
> Yes, this is for the UEFI port for BeagleBoneBlack.
> 
> I am building a single FD that consists of both SEC and PEI. SEC is
> loaded from
> the x-loader, and I am trying to figure out how to pass over to PEI.
> 
> The source is at [1] -- I call return_from_exception() on
> PcdFvBaseAddress after I am
> done with SEC.
> 
> I tried passing the offset addresses mentioned in my build report [2]
> for
> ArmPlatformPrePeiCore but with no luck.
> 
> I see that GenFvInternalLib.c:UpdateArmResetVectorIfNeeded() places the
> PEI Core
> address into the FvImage. Do I want to jump to this address?
> 
> Thanks,
> Varad
> 
> [1]
> https://github.com/varadgautam/TexasInstrumentsPkg/tree/PEI/BeagleBoneB
> lackPkg
> [2] http://fpaste.org/116323/48225071/
> 
> On Tue, Jul 8, 2014 at 4:03 PM, Olivier Martin 
> wrote:
> > Hi Varad,
> >
> > Can you give a bit more details on your boot flow.
> > Where do you start the SEC from (Flash?)? Is SEC and PEI in the same
> FD
> > file?
> > I guess it is the related to the UEFI support for the
> BeagleBoneBlack?
> >
> > Looking at the code in
> >
> https://github.com/varadgautam/TexasInstrumentsPkg/blob/master/BeagleBo
> neBla
> > ckPkg/ArmPlatformPkg.fdf I do not see anything obvious.
> >
> > Does the BeagleBone black use x-loader? Are you using it? Or you are
> trying
> > to bypass x-loader with your Sec_ArmPlatform_EFI.FD ?
> >
> > Thanks,
> > Olivier
> >
> >> -Original Message-
> >> From: Varad Gautam [mailto:varadgau...@gmail.com]
> >> Sent: 07 July 2014 10:47
> >> To: edk2-devel@lists.sourceforge.net
> >> Subject: [edk2] Entry Point for SEC -> PEI Transition
> >>
> >> Hi,
> >>
> >> How is the entry point address needed to transition from SEC -> PEI
> >> found out for an ARM platform package?
> >>
> >> Although the PcdFvBaseAddress is set to 0x80048000 according to the
> >> build report,  `PcdGet32(PcdFvBaseAddress)` returns 0, and
> >> `NonTrustedWorldTransition()` hangs. Passing this address manually
> too
> >> doesn't work.
> >>
> >> The report shows the entry point address as `*EF 0x00800481c4
> >> _ModuleEntryPoint` for
> ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
> >> module, but this address doesn't work either.
> >>
> >> Thanks.
> >> Varad
> >>
> >> 
> ---
> >> ---
> >> Open source business process management suite built on Java and
> Eclipse
> >> Turn processes into business applications with Bonita BPM Community
> >> Edition
> >> Quickly connect people, data, and systems into organized workflows
> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >> http://p.sf.net/sfu/Bonitasoft
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >
> >
> >
> >
> >
> > -
> -
> > Open source business process management suite built on Java and
> Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> ---
> ---
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
> Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel





--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
ht

[edk2] [PATCH] Whitespace fixup for ARM Directories

2014-07-09 Thread Leif Lindholm

The result of running:
find ArmP* -not -name "*.sh" -not -name "*.patch" -not -name "*.py" -exec 
unix2dos {} \;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 ArmPkg/Drivers/ArmGic/ArmGicLib.c  |2 +-
 ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c|2 +-
 ArmPkg/Library/BdsLib/BdsFilePath.c|   98 ++--
 .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc  |2 +-
 .../ArmVExpressPkg/ArmVExpress-CTA9x4.fdf  |8 +-
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc|   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf|   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf |   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc   |   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf   |   14 +--
 .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc   |   12 +--
 .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf   |   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc   |   12 +--
 .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf   |   14 +--
 ArmPlatformPkg/Bds/BdsHelper.c |6 +-
 16 files changed, 121 insertions(+), 121 deletions(-)

diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
index 41e970b..717b18b 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
@@ -157,7 +157,7 @@ ArmGicDisableDistributor (
   // Disable Gic Distributor
   MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x0);
 }
-
+
 VOID
 EFIAPI
 ArmGicEnableInterruptInterface (
diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c 
b/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
index 8000626..22c56a3 100644
--- a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
+++ b/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
@@ -208,7 +208,7 @@ InitializeExceptions (
 //Note: On ARM processor with the Security Extension, the Vector Table can 
be located anywhere in the memory.
 //  The Vector Base Address Register defines the location
 ArmWriteVBar (PcdGet32(PcdCpuVectorBaseAddress));
-  } else {
+  } else {
 // The Vector table must be 32-byte aligned
 if (((UINT32)ExceptionHandlersStart & ARM_VECTOR_TABLE_ALIGNMENT) != 0) {
   ASSERT (0);
diff --git a/ArmPkg/Library/BdsLib/BdsFilePath.c 
b/ArmPkg/Library/BdsLib/BdsFilePath.c
index 411fcc1..f754b88 100644
--- a/ArmPkg/Library/BdsLib/BdsFilePath.c
+++ b/ArmPkg/Library/BdsLib/BdsFilePath.c
@@ -300,24 +300,24 @@ TryRemovableDevice (
   return Status;
 }
 
-STATIC
+STATIC
 EFI_STATUS
-BdsConnectAndUpdateDevicePath (
-  IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath,
-  OUTEFI_HANDLE*Handle,
-  OUTEFI_DEVICE_PATH_PROTOCOL  **RemainingDevicePath
+BdsConnectAndUpdateDevicePath (
+  IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath,
+  OUTEFI_HANDLE*Handle,
+  OUTEFI_DEVICE_PATH_PROTOCOL  **RemainingDevicePath
   )
 {
   EFI_DEVICE_PATH*Remaining;
   EFI_DEVICE_PATH*NewDevicePath;
   EFI_STATUS  Status;
 
-  if ((DevicePath == NULL) || (*DevicePath == NULL) || (Handle == NULL)) {
+  if ((DevicePath == NULL) || (*DevicePath == NULL) || (Handle == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
   do {
-Remaining = *DevicePath;
+Remaining = *DevicePath;
 // The LocateDevicePath() function locates all devices on DevicePath that 
support Protocol and returns
 // the handle to the device that is closest to DevicePath. On output, the 
device path pointer is modified
 // to point to the remaining part of the device path
@@ -337,7 +337,7 @@ BdsConnectAndUpdateDevicePath (
   if (!EFI_ERROR (Status)) {
 // Now, we have got the whole Device Path connected, call again 
ConnectController to ensure all the supported Driver
 // Binding Protocol are connected (such as DiskIo and SimpleFileSystem)
-Remaining = *DevicePath;
+Remaining = *DevicePath;
 Status = gBS->LocateDevicePath (&gEfiDevicePathProtocolGuid, &Remaining, 
Handle);
 if (!EFI_ERROR (Status)) {
   Status = gBS->ConnectController (*Handle, NULL, Remaining, FALSE);
@@ -360,11 +360,11 @@ BdsConnectAndUpdateDevicePath (
 //TODO: Should we just return success and leave the caller decide if it is 
the expected RemainingPath
 Status = EFI_SUCCESS;
   } else {
-Status = TryRemovableDevice (*DevicePath, Handle, &NewDevicePath);
+Status = TryRemovableDevice (*DevicePath, Handle, &NewDevicePath);
 if (!EFI_ERROR (Status)) {
-  Status = BdsConnectAndUpdateDevicePath (&NewDevicePath, Handle, 
RemainingDevicePath);
-  *DevicePath = NewDevicePath;
-  return Status;
+  Status = BdsConnectAndUpdateDevicePath (&NewDevicePath, Handle, 
RemainingDevicePath);
+  *DevicePath = NewDevicePath;
+  return Status;
 }
   }
 
@@ -375,28 +375,28 @@ BdsConnectAndUpdateDevicePath (
   return Status;
 }
 
-/**
-  Co

Re: [edk2] [PATCH] Whitespace fixup for ARM Directories

2014-07-09 Thread Olivier Martin

Thanks Leif,
As I told you before I need to extend the test in our CI (the test already
covers *.c/*.h/*.S/*.asm files) before fixing any new whitespace change to
prevent to fix it again.
And as we can see in this patch our current test are not good enough because
I can see some *.c files in your patch.
Thanks,
Olivier

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 09 July 2014 15:44
> To: edk2-devel@lists.sourceforge.net
> Cc: Olivier Martin
> Subject: [PATCH] Whitespace fixup for ARM Directories
> 
> The result of running:
> find ArmP* -not -name "*.sh" -not -name "*.patch" -not -name "*.py" -
> exec unix2dos {} \;
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 
> ---
>  ArmPkg/Drivers/ArmGic/ArmGicLib.c  |2 +-
>  ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c|2 +-
>  ArmPkg/Library/BdsLib/BdsFilePath.c|   98 ++--
> 
>  .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc  |2 +-
>  .../ArmVExpressPkg/ArmVExpress-CTA9x4.fdf  |8 +-
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc|   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf|   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf |   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc   |   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf   |   14 +--
>  .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc   |   12 +--
>  .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf   |   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc   |   12 +--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf   |   14 +--
>  ArmPlatformPkg/Bds/BdsHelper.c |6 +-
>  16 files changed, 121 insertions(+), 121 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> index 41e970b..717b18b 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> @@ -157,7 +157,7 @@ ArmGicDisableDistributor (
>// Disable Gic Distributor
>MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x0);
>  }
> -
> +
>  VOID
>  EFIAPI
>  ArmGicEnableInterruptInterface (
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
> b/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
> index 8000626..22c56a3 100644
> --- a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
> +++ b/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
> @@ -208,7 +208,7 @@ InitializeExceptions (
>  //Note: On ARM processor with the Security Extension, the Vector
> Table can be located anywhere in the memory.
>  //  The Vector Base Address Register defines the location
>  ArmWriteVBar (PcdGet32(PcdCpuVectorBaseAddress));
> -  } else {
> +  } else {
>  // The Vector table must be 32-byte aligned
>  if (((UINT32)ExceptionHandlersStart & ARM_VECTOR_TABLE_ALIGNMENT)
> != 0) {
>ASSERT (0);
> diff --git a/ArmPkg/Library/BdsLib/BdsFilePath.c
> b/ArmPkg/Library/BdsLib/BdsFilePath.c
> index 411fcc1..f754b88 100644
> --- a/ArmPkg/Library/BdsLib/BdsFilePath.c
> +++ b/ArmPkg/Library/BdsLib/BdsFilePath.c
> @@ -300,24 +300,24 @@ TryRemovableDevice (
>return Status;
>  }
> 
> -STATIC
> +STATIC
>  EFI_STATUS
> -BdsConnectAndUpdateDevicePath (
> -  IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath,
> -  OUTEFI_HANDLE*Handle,
> -  OUTEFI_DEVICE_PATH_PROTOCOL  **RemainingDevicePath
> +BdsConnectAndUpdateDevicePath (
> +  IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath,
> +  OUTEFI_HANDLE*Handle,
> +  OUTEFI_DEVICE_PATH_PROTOCOL  **RemainingDevicePath
>)
>  {
>EFI_DEVICE_PATH*Remaining;
>EFI_DEVICE_PATH*NewDevicePath;
>EFI_STATUS  Status;
> 
> -  if ((DevicePath == NULL) || (*DevicePath == NULL) || (Handle ==
> NULL)) {
> +  if ((DevicePath == NULL) || (*DevicePath == NULL) || (Handle ==
> NULL)) {
>  return EFI_INVALID_PARAMETER;
>}
> 
>do {
> -Remaining = *DevicePath;
> +Remaining = *DevicePath;
>  // The LocateDevicePath() function locates all devices on
> DevicePath that support Protocol and returns
>  // the handle to the device that is closest to DevicePath. On
> output, the device path pointer is modified
>  // to point to the remaining part of the device path
> @@ -337,7 +337,7 @@ BdsConnectAndUpdateDevicePath (
>if (!EFI_ERROR (Status)) {
>  // Now, we have got the whole Device Path connected, call again
> ConnectController to ensure all the supported Driver
>  // Binding Protocol are connected (such as DiskIo and
> SimpleFileSystem)
> -Remaining = *DevicePath;
> +Remaining = *DevicePath;
>  Status = gBS->LocateDevicePath (&gEfiDevicePathProtocolGuid,
> &Remaining, Handle);
>  if (!EFI_ERROR (Status)) {
>Status = gBS->ConnectController (*Handle, NULL, Remaining,
> FALSE);
> @@ -360,11 +360,1

Re: [edk2] Signing binaries and timestamping

2014-07-09 Thread Jeff Bobzin

Dear Bruce,

In general the system firmware does not have protected time source so the
expiration date of the certificate is ignored for Secure Boot verification.
(A bad actor could just change the system date to re-enable a certificate.)
In a particular system design that did have a time source with protection
(from unauthorized alteration) this check could be added if desired.
But it is not required by UEFI.

A related area is Time Stamp Checking related to dbt variable added in 2.4.

Simplified Understanding of How UEFI Timestamp Authentication Feature Works
- 
1)  The dbt variable is (factory or OS) provisioned with one or more
timestamp service public certificates.
2)  UEFI executables signed by the CA are also immediately
counter-signed by the time stamp authority
3)  So, if the signature of an executable is signed by a trusted
timestamp certificate, them firmware can trust the indicated time of signing
by CA
4)  When time of signing is trusted, the processing of certificates
added to dbx is altered, and executables signed prior to the certificates
time of revocation can be allowed to run while still blocking executables
signed later (or lacking trusted timestamp) 

---Jeff Bobzin
Insyde Software

-Original Message-
From: Bruce Cran [mailto:bruce.c...@gmail.com] 
Sent: Tuesday, July 8, 2014 10:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Signing binaries and timestamping

Having used Authenticode on Windows, I know that without a timestamp the
signature will be considered invalid once the certificate has expired. 
Is the same true with UEFI?

I don't see anything about timestamping in the documentation
(SigningUefiImages etc.) but on Windows 8.1 Microsoft's EFI files in
C:\Windows\boot\EFI _are_ timestamped.

Is the current date considered when determining whether a signature is valid
under UEFI?

--
Bruce



--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Signing binaries and timestamping

2014-07-09 Thread Jeff Bobzin

Dear Bruce,

 

In general the system firmware does not have protected time source so the
expiration date of the certificate is ignored for Secure Boot verification.

(A bad actor could just change the system date to re-enable a certificate.)
In a particular system design that did have a time source with protection
(from unauthorized alteration) this check could be added if desired.

But it is not required by UEFI.

 

A related area is Time Stamp Checking related to dbt variable added in 2.4.

 

Simplified Understanding of How UEFI Timestamp Authentication Feature Works

- 

1)The dbt variable is (factory or OS) provisioned with one or
more

timestamp service public certificates.

2)UEFI executables signed by the CA are also immediately

counter-signed by the time stamp authority

3)So, if the signature of an executable is signed by a trusted

timestamp certificate, them firmware can trust the indicated time of signing
by CA

4)When time of signing is trusted, the processing of
certificates

added to dbx is altered, and executables signed prior to the certificates
time of revocation can be allowed to run while still blocking executables
signed later (or lacking trusted timestamp) 

 

---Jeff Bobzin

Insyde Software

 

-Original Message-

From: Bruce Cran [ 
mailto:bruce.c...@gmail.com]

Sent: Tuesday, July 8, 2014 10:59 AM

To:  
edk2-devel@lists.sourceforge.net

Subject: [edk2] Signing binaries and timestamping

 

Having used Authenticode on Windows, I know that without a timestamp the
signature will be considered invalid once the certificate has expired. 

Is the same true with UEFI?

 

I don't see anything about timestamping in the documentation
(SigningUefiImages etc.) but on Windows 8.1 Microsoft's EFI files in
C:\Windows\boot\EFI _are_ timestamped.

 

Is the current date considered when determining whether a signature is valid
under UEFI?

 

--

Bruce

 

 



--

Open source business process management suite built on Java and Eclipse Turn
processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows Winner of
BOSSIE, CODIE, OW2 and Gartner awards  
http://p.sf.net/sfu/Bonitasoft
___

edk2-devel mailing list

  edk2-devel@lists.sourceforge.net

 
https://lists.sourceforge.net/lists/listinfo/edk2-devel

 

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Using EFI_PROTOCOL_DEFINITION, EFI_PROTOCOL_CONSUMER and EFI_PROTOCOL_PRODUCER

2014-07-09 Thread Jeff Bobzin

Volodymyr,

 

EDK-II build system is capable of also building drivers written to the EDK-I 
standard.

This ability is called ECP. (http://tianocore.sourceforge.net/wiki/ECP )

 

The Macros you mention in your email would be used in an EDK-I driver.

EDK-II uses different methods including the .dec and new format .inf files to 
declare protocols.

 

--Jeff Bobzin

Insyde Software

 

From: Volodymyr Sharovar [mailto:volodymyrsharo...@gmail.com] 
Sent: Wednesday, July 2, 2014 1:35 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Using EFI_PROTOCOL_DEFINITION, EFI_PROTOCOL_CONSUMER and 
EFI_PROTOCOL_PRODUCER

 

Hello,

I have stumbled upon EFI_PROTOCOL_DEFINITION when I was going through UDK 
protocols. I have always just included the protocols I was using in the header 
file as 

#include 

and then if my driver would produce it or consume it I would do the same thing 
they do in "EDKII Module Writer's Guide" Section 8.4.1. My question is where 
and when would I use these macros? Also what would be the benefit of using them 
over the method stated in Module Writer's Guide?

Thank you,

Volodymyr Sharovar

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] inconsistent #langdef usage in *.uni files

2014-07-09 Thread Blibbet

Hi,

The "#langdef" value used in various EDK-II *.uni files define
the language name in various ways, seemingly inconsistent.

Most use either:
#langdef   en-US "english"
or:
#langdef   en-US "English"

A few use:
#langdef   en-US "en-US"

UefiShellInstall1CommandsLib.uni uses:
#langdef   en-US "en-english"

UefiShellLevel1CommandsLib.uni uses:
#langdef   en-US "en-USlish"

At least these last 2 usages should probably be fixed, perhaps others. 

Also, perhaps related, but it seems confusing that the code uses one (or
multiple formats) and the end user is asked to use another convention.
Besides the "English"/"en-US" formats that #langdef uses, however, the
end user docs (the shell commands that support the -L XXX switch)
presumes "Eng" format. FYI, there is a Eng/us-EN style lang code patch
on github.

Thanks,
Lee

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Multiple DP commands included in EDK2

2014-07-09 Thread Blibbet

Hi,

For the DP command, there are two different codebases, one in
ShellPkg and one in PerformancePkg, which differ significantly at the
source level. One is copyrighted one year later. One is English-only,
one also has a French translation (unlike any other EDK2 commands,
which are all English-only).

Why include two versions, older and newer, in current EDK2?  Why not
just remove the old version, and have copy of code, which is the two
different shell profiles could share the same strings (and code) for? 

Thanks,
Lee

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Debug1's BCFG manpage has some truncated strings

2014-07-09 Thread Blibbet

Hi,

ShellPkg's UefiShellDebug1CommandsLib.uni's STR_GET_HELP_BCFG string
has 2 truncated strings, see excerpt:

1: "To add a driver option #5\r\n"
2: "  %EShell>%N bcfg driver add 5 mydriver.efi "My Driver
3: "To add a boot option #3\r\n"
4: "  %EShell>%N bcfg boot add 3 osloader.efi "My OS

Lines 2 and 4 need "\r\n" (including the quotes) appended to each line.
Here's an example of what it should look like, from the Install1's
version of the BCFG strings in UefiShellInstall1CommandsLib.uni. The
above and below excerpts should be identical.

1: "To add a driver option #5\r\n"
2: "  %EShell>%N bcfg driver add 5 mydriver.efi "My Driver"\r\n"
3: "To add a boot option #3\r\n"
4: "  %EShell>%N bcfg boot add 3 osloader.efi "My OS"\r\n"

Manpage text aside, why are there 2 copies of the BCFG command?  If you
diff bcfg.c there are code differences, beyond all the "Debug1" -vs-
"Install1" naming noise.  So why keep two versions in the EDK2, why not
just keep one, the latest one? BCFG is strangely the only command that
is in multiple profiles, Install1 and Debug1.  If it were only in a
single profile, I suspect we'd only be seeing the freshest code, not
the fresh one and an older one. :-)

Thanks,
Lee

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] how to set default boot path to hard disk?

Re: [edk2] Entry Point for SEC -> PEI Transition

[edk2] [PATCH] Whitespace fixup for ARM Directories

Re: [edk2] [PATCH] Whitespace fixup for ARM Directories

Re: [edk2] Signing binaries and timestamping

Re: [edk2] Signing binaries and timestamping

Re: [edk2] Using EFI_PROTOCOL_DEFINITION, EFI_PROTOCOL_CONSUMER and EFI_PROTOCOL_PRODUCER

[edk2] inconsistent #langdef usage in *.uni files

[edk2] Multiple DP commands included in EDK2

[edk2] Debug1's BCFG manpage has some truncated strings

10 matches

Site Navigation

Mail list logo

Footer information