date:20191107

With that, Reviewed-by: Ray Ni 

> -Original Message-
> From: Yao, Jiewen 
> Sent: Friday, November 8, 2019 3:01 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Lou, Yun 
> 
> Subject: RE: [PATCH V3 2/6] IntelSiliconPkg/Include: Add Platform Device 
> Security Policy protocol
> 
> Good catch.
> No special meaning.
> 
> I will use _VERSION.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Friday, November 8, 2019 3:00 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V ; Lou, Yun
> > 
> > Subject: RE: [PATCH V3 2/6] IntelSiliconPkg/Include: Add Platform Device
> > Security Policy protocol
> >
> > Jiewen,
> > The structure field is named "Version" while the macro is ended with
> > "_REVISION".
> > Is there a special reason for such inconsistency?
> >
> > Thanks,
> > Ray
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Thursday, November 7, 2019 9:38 PM
> > > To: devel@edk2.groups.io
> > > Cc: Ni, Ray ; Chaganty, Rangasai V
> > > ; Lou, Yun 
> > > Subject: [PATCH V3 2/6] IntelSiliconPkg/Include: Add Platform Device
> > > Security Policy protocol
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> > >
> > > Cc: Ray Ni 
> > > Cc: Rangasai V Chaganty 
> > > Cc: Yun Lou 
> > > Signed-off-by: Jiewen Yao 
> > > ---
> > >  .../Protocol/PlatformDeviceSecurityPolicy.h   | 128 ++
> > >  1 file changed, 128 insertions(+)
> > >  create mode 100644
> > > Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolicy.h
> > >
> > > diff --git
> > > a/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolic
> > > y.h
> > > b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolic
> > > y.h
> > > new file mode 100644
> > > index 00..b151781de2
> > > --- /dev/null
> > > +++ b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecur
> > > +++ ityPolicy.h
> > > @@ -0,0 +1,128 @@
> > > +/** @file
> > > +  Platform Device Security Policy Protocol definition
> > > +
> > > +  Copyright (c) 2019, Intel Corporation. All rights reserved.
> > > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +
> > > +**/
> > > +
> > > +
> > > +#ifndef __EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_H__
> > > +#define __EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_H__
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +typedef struct _EDKII_DEVICE_SECURITY_POLICY_PROTOCOL
> > > +EDKII_DEVICE_SECURITY_POLICY_PROTOCOL;
> > > +
> > > +//
> > > +// Revision The revision to which the DEVICE_SECURITY_POLICY protocol
> > > interface adheres.
> > > +//  All future revisions must be backwards compatible.
> > > +//  If a future version is not back wards compatible it is not 
> > > the same
> > > GUID.
> > > +//
> > > +#define EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_REVISION
> > > 0x0001
> > > +
> > > +//
> > > +// Revision The revision to which the DEVICE_SECURITY_POLICY structure
> > > adheres.
> > > +//  All future revisions must be backwards compatible.
> > > +//
> > > +#define EDKII_DEVICE_SECURITY_POLICY_REVISION 0x0001
> > > +
> > > +///
> > > +/// The macro for the policy defined in EDKII_DEVICE_SECURITY_POLICY
> > > +///
> > > +#define EDKII_DEVICE_MEASUREMENT_REQUIRED BIT0
> > > +#define EDKII_DEVICE_AUTHENTICATION_REQUIRED  BIT0
> > > +
> > > +///
> > > +/// The device security policy data structure /// typedef struct {
> > > +  UINT32 Version;
> > > +  UINT32 MeasurementPolicy;
> > > +  UINT32 AuthenticationPolicy;
> > > +} EDKII_DEVICE_SECURITY_POLICY;
> > > +
> > > +//
> > > +// Revision The revision to which the DEVICE_SECURITY_STATE structure
> > > adheres.
> > > +//  All future revisions must be backwards compatible.
> > > +//
> > > +#define EDKII_DEVICE_SECURITY_STATE_REVISION 0x0001
> > > +
> > > +///
> > > +/// The macro for the state defined in EDKII_DEVICE_SECURITY_STATE ///
> > > +#define EDKII_DEVICE_SECURITY_STATE_SUCCESS  0
> > > +#define EDKII_DEVICE_SECURITY_STATE_ERROR
> > > BIT31
> > > +#define EDKII_DEVICE_SECURITY_STATE_ERROR_UEFI_UNSUPPORTED
> > > (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x0)
> > > +#define
> > > EDKII_DEVICE_SECURITY_STATE_ERROR_UEFI_GET_POLICY_PROTOCOL
> > > (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x1)
> > > +#define EDKII_DEVICE_SECURITY_STATE_ERROR_PCI_NO_CAPABILITIES
> > > (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x10)
> > > +#define EDKII_DEVICE_SECURITY_STATE_ERROR_TCG_EXTEND_TPM_PCR
> > > (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x20)
> > > +
> > > +///
> > > +/// The device security state data structure /// typedef struct {
> > > +  UINT32 Version;
> > > +  UINT32 MeasurementState;
> > > +  UINT32 AuthenticationState;
> > > +} EDKII_DEVICE_SECURITY_STATE;
> > > +
> > > +/**
> > > +  This function returns the device security policy associated with the 
> > >

Re: [edk2-devel] [PATCH V3 3/6] IntelSiliconPkg/dec: Add ProtocolGuid definition.

Reviewed-by: Ray Ni 

> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, November 7, 2019 9:38 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
> ; Lou, Yun 
> Subject: [PATCH V3 3/6] IntelSiliconPkg/dec: Add ProtocolGuid definition.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Yun Lou 
> Signed-off-by: Jiewen Yao 
> ---
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> index 3079fc2869..22ebf19c4e 100644
> --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> @@ -54,6 +54,10 @@
>  [Protocols]
>gEdkiiPlatformVTdPolicyProtocolGuid = { 0x3d17e448, 0x466, 0x4e20, { 0x99,
> 0x9f, 0xb2, 0xe1, 0x34, 0x88, 0xee, 0x22 }}
> 
> +  ## Protocol for device security policy.
> +  # Include/Protocol/PlatformDeviceSecurityPolicy.h
> +  gEdkiiDeviceSecurityPolicyProtocolGuid = {0x7ea41a99, 0x5e32, 0x4c97,
> {0x88, 0xc4, 0xd6, 0xe7, 0x46, 0x84, 0x9, 0xd4}}
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
>## Error code for VTd error.
>#  EDKII_ERROR_CODE_VTD_ERROR = (EFI_IO_BUS_UNSPECIFIED |
> (EFI_OEM_SPECIFIC | 0x)) = 0x02008000
> --
> 2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50291): https://edk2.groups.io/g/devel/message/50291
Mute This Topic: https://groups.io/mt/46027948/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 2/6] IntelSiliconPkg/Include: Add Platform Device Security Policy protocol

Jiewen,
The structure field is named "Version" while the macro is ended with 
"_REVISION".
Is there a special reason for such inconsistency?

Thanks,
Ray

> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, November 7, 2019 9:38 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
> ; Lou, Yun 
> Subject: [PATCH V3 2/6] IntelSiliconPkg/Include: Add Platform Device
> Security Policy protocol
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Yun Lou 
> Signed-off-by: Jiewen Yao 
> ---
>  .../Protocol/PlatformDeviceSecurityPolicy.h   | 128 ++
>  1 file changed, 128 insertions(+)
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolicy.h
> 
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolic
> y.h
> b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolic
> y.h
> new file mode 100644
> index 00..b151781de2
> --- /dev/null
> +++ b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecur
> +++ ityPolicy.h
> @@ -0,0 +1,128 @@
> +/** @file
> +  Platform Device Security Policy Protocol definition
> +
> +  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +
> +#ifndef __EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_H__
> +#define __EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_H__
> +
> +#include 
> +#include 
> +
> +typedef struct _EDKII_DEVICE_SECURITY_POLICY_PROTOCOL
> +EDKII_DEVICE_SECURITY_POLICY_PROTOCOL;
> +
> +//
> +// Revision The revision to which the DEVICE_SECURITY_POLICY protocol
> interface adheres.
> +//  All future revisions must be backwards compatible.
> +//  If a future version is not back wards compatible it is not the 
> same
> GUID.
> +//
> +#define EDKII_DEVICE_SECURITY_POLICY_PROTOCOL_REVISION
> 0x0001
> +
> +//
> +// Revision The revision to which the DEVICE_SECURITY_POLICY structure
> adheres.
> +//  All future revisions must be backwards compatible.
> +//
> +#define EDKII_DEVICE_SECURITY_POLICY_REVISION 0x0001
> +
> +///
> +/// The macro for the policy defined in EDKII_DEVICE_SECURITY_POLICY
> +///
> +#define EDKII_DEVICE_MEASUREMENT_REQUIRED BIT0
> +#define EDKII_DEVICE_AUTHENTICATION_REQUIRED  BIT0
> +
> +///
> +/// The device security policy data structure /// typedef struct {
> +  UINT32 Version;
> +  UINT32 MeasurementPolicy;
> +  UINT32 AuthenticationPolicy;
> +} EDKII_DEVICE_SECURITY_POLICY;
> +
> +//
> +// Revision The revision to which the DEVICE_SECURITY_STATE structure
> adheres.
> +//  All future revisions must be backwards compatible.
> +//
> +#define EDKII_DEVICE_SECURITY_STATE_REVISION 0x0001
> +
> +///
> +/// The macro for the state defined in EDKII_DEVICE_SECURITY_STATE ///
> +#define EDKII_DEVICE_SECURITY_STATE_SUCCESS  0
> +#define EDKII_DEVICE_SECURITY_STATE_ERRORBIT31
> +#define EDKII_DEVICE_SECURITY_STATE_ERROR_UEFI_UNSUPPORTED
> (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x0)
> +#define
> EDKII_DEVICE_SECURITY_STATE_ERROR_UEFI_GET_POLICY_PROTOCOL
> (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x1)
> +#define EDKII_DEVICE_SECURITY_STATE_ERROR_PCI_NO_CAPABILITIES
> (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x10)
> +#define EDKII_DEVICE_SECURITY_STATE_ERROR_TCG_EXTEND_TPM_PCR
> (EDKII_DEVICE_SECURITY_STATE_ERROR + 0x20)
> +
> +///
> +/// The device security state data structure /// typedef struct {
> +  UINT32 Version;
> +  UINT32 MeasurementState;
> +  UINT32 AuthenticationState;
> +} EDKII_DEVICE_SECURITY_STATE;
> +
> +/**
> +  This function returns the device security policy associated with the 
> device.
> +
> +  The device security driver may call this interface to get the
> + platform policy  for the specific device and determine if the
> + measurement or authentication  is required.
> +
> +  @param[in]  This   The protocol instance pointer.
> +  @param[in]  DeviceId   The Identifier for the device.
> +  @param[out] DeviceSecurityPolicy   The Device Security Policy associated
> with the device.
> +
> +  @retval EFI_SUCCESSThe device security policy is returned
> +  @retval EFI_UNSUPPORTEDThe function is unsupported for the
> specific Device.
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_DEVICE_SECURITY_GET_DEVICE_POLICY) (
> +  IN  EDKII_DEVICE_SECURITY_POLICY_PROTOCOL  *This,
> +  IN  EDKII_DEVICE_IDENTIFIER*DeviceId,
> +  OUT EDKII_DEVICE_SECURITY_POLICY   *DeviceSecurityPolicy
> +  );
> +
> +/**
> +  This function sets the device state based upon the authentication result.
> +
> +  The device security driver may call this interface to give the
> + platform  a notify based upon the measurement or authentication result.
> +  If the authentication or measurement fails,

Re: [edk2-devel] [PATCH V3 1/6] IntelSiliconPkg/Include: Add Intel PciSecurity definition.

Reviewed-by: Ray Ni 

> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, November 7, 2019 9:38 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
> ; Lou, Yun 
> Subject: [PATCH V3 1/6] IntelSiliconPkg/Include: Add Intel PciSecurity
> definition.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Yun Lou 
> Signed-off-by: Jiewen Yao 
> ---
>  .../IndustryStandard/IntelPciSecurity.h   | 92 +++
>  1 file changed, 92 insertions(+)
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
> 
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
> b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
> new file mode 100644
> index 00..f2bdb7ee2d
> --- /dev/null
> +++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSec
> +++ urity.h
> @@ -0,0 +1,92 @@
> +/** @file
> +  Intel PCI security data structure definition from
> +  PCIe* Device Security Enhancements Specification.
> +
> +
> + https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> sec
> + urity-enhancements-spec.html
> +
> +  NOTE: The data structure is not fully match the current
> + specification,  because it is aligned with the real hardware
> + implementation with minor adjustment  on
> + INTEL_PCI_DIGEST_CAPABILITY_STRUCTURE,
> INTEL_PCI_DIGEST_DATA_MODIFIED and  INTEL_PCI_DIGEST_DATA_VALID.
> +
> +Copyright (c) 2019, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __INTEL_PCI_SECURITY_H__
> +#define __INTEL_PCI_SECURITY_H__
> +
> +#pragma pack(1)
> +
> +///
> +/// The PCIE capability structure header for Intel PCI DVSEC extension.
> +///
> +typedef struct {
> +  UINT16  CapId;   // 0x23: DVSEC
> +  UINT16  CapVersion:4;// 1
> +  UINT16  NextOffset:12;
> +  UINT16  DvSecVendorId;   // 0x8086
> +  UINT16  DvSecRevision:4; // 1
> +  UINT16  DvSecLength:12;
> +  UINT16  DvSecId; // 0x3E: Measure
> +} INTEL_PCI_DIGEST_CAPABILITY_HEADER;
> +
> +#define INTEL_PCI_CAPID_DVSEC0x23
> +#define INTEL_PCI_DVSEC_VENDORID_INTEL   0x8086
> +#define INTEL_PCI_DVSEC_DVSECID_MEASUREMENT  0x3E
> +
> +///
> +/// The Intel PCI digest modified macro.
> +///
> +#define INTEL_PCI_DIGEST_MODIFIEDBIT0
> +
> +///
> +/// The Intel PCI DVSEC digest data modified structure.
> +///
> +typedef union {
> +  struct {
> +UINT8   DigestModified:1; // RW1C
> +UINT8   Reserved0:7;
> +  } Bits;
> +  UINT8 Data;
> +} INTEL_PCI_DIGEST_DATA_MODIFIED;
> +
> +///
> +/// The Intel PCI digest valid macro.
> +///
> +#define INTEL_PCI_DIGEST_0_VALID BIT0
> +#define INTEL_PCI_DIGEST_0_LOCKEDBIT1
> +#define INTEL_PCI_DIGEST_1_VALID BIT2
> +#define INTEL_PCI_DIGEST_1_LOCKEDBIT3
> +
> +///
> +/// The Intel PCI DVSEC digest data valid structure.
> +///
> +typedef union {
> +  struct {
> +UINT8   Digest0Valid:1;  // RO
> +UINT8   Digest0Locked:1; // RO
> +UINT8   Digest1Valid:1;  // RO
> +UINT8   Digest1Locked:1; // RO
> +UINT8   Reserved1:4;
> +  } Bits;
> +  UINT8 Data;
> +} INTEL_PCI_DIGEST_DATA_VALID;
> +
> +///
> +/// The PCIE capability structure for Intel PCI DVSEC extension with digest.
> +///
> +typedef struct {
> +  INTEL_PCI_DIGEST_DATA_MODIFIED   Modified;   // RW1C
> +  INTEL_PCI_DIGEST_DATA_VALID  Valid;  // RO
> +  UINT16   TcgAlgId;   // RO
> +  UINT8FirmwareID; // RO
> +  UINT8Reserved;
> +//UINT8Digest[];
> +} INTEL_PCI_DIGEST_CAPABILITY_STRUCTURE;
> +
> +#pragma pack()
> +
> +#endif
> +
> --
> 2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50289): https://edk2.groups.io/g/devel/message/50289
Mute This Topic: https://groups.io/mt/46027867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 0/4] Add SPDM device security

For changes in edk2 repo, Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen
> Sent: Thursday, November 7, 2019 9:41 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Subject: Re: [edk2-devel] [PATCH V3 0/4] Add SPDM device security
> 
> Hi
> I forget to mention that this patch is also pushed to git.
> 
> The EDKII repo update is at
> https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV3
> The EDKII platform repo update is at https://github.com/jyao1/edk2-
> platforms/tree/DeviceSecurityMasterV3
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Yao,
> > Jiewen
> > Sent: Thursday, November 7, 2019 9:38 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [PATCH V3 0/4] Add SPDM device security
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> >
> > = v3 =
> >
> > The patch addresses the feedback below:
> > Liming Gao:
> > 1) specify the spec version in file header for SPDM.
> >
> > Ray Ni:
> > 1) create a standalone function like PciDeviceAuthenticate() and move
> > the new code to that function then call it from CreatePciIoDevice
> >
> > = v2 =
> > This patch series add support for device security based upon the DMTF
> > SPDM specification.
> >
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0
> > .95a
> > .zip
> >
> > We did design review at 18 Oct, 2019.
> > https://edk2.groups.io/g/devel/files/Designs/2019/1018
> > And the feedback from the meeting is addressed.
> > https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-
> > Device%20Firmware%20Security%20v2.pdf
> >
> > We add the Device security protocol in EDKII repo.
> > PCI bus driver consumes the interface.
> > If there is no producer, the PCI bus driver keeps current behavior.
> >
> > So far, we only provide the producer what follows Intel PCI security
> > spec.
> > https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> > security-enhancements-spec.html
> > The implementation is put to EDKII platform repo.
> >
> > The EDKII repo update is at
> > https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
> > The EDKII platform repo update is at https://github.com/jyao1/edk2-
> > platforms/tree/DeviceSecurityMasterV2
> >
> > The validation has been done on a Intel internal platform.
> > The device measurement can be shown in TCG event log.
> >
> > signed-off-by: Jiewen Yao 
> >
> > Jiewen Yao (4):
> >   MdePkg/Include: Add DMTF SPDM definition.
> >   MdeModulePkg/Include: Add DeviceSecurity.h
> >   MdeModulePkg/dec: Add EdkiiDeviceSecurityProtocolGuid.
> >   MdeModulePkg/Pci: Add DeviceSecurity support.
> >
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c   |  12 +-
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |   1 +
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |   4 +-
> >  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |  77 +
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |   4 +-
> >  .../Include/Protocol/DeviceSecurity.h | 162 +
> >  MdeModulePkg/MdeModulePkg.dec |   5 +
> >  MdePkg/Include/IndustryStandard/Spdm.h| 320
> ++
> >  8 files changed, 581 insertions(+), 4 deletions(-)  create mode
> > 100644 MdeModulePkg/Include/Protocol/DeviceSecurity.h
> >  create mode 100644 MdePkg/Include/IndustryStandard/Spdm.h
> >
> > --
> > 2.19.2.windows.1
> >
> >
> >
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50288): https://edk2.groups.io/g/devel/message/50288
Mute This Topic: https://groups.io/mt/46026514/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

2019-11-07 Thread Tiger Liu(BJ-RD)

Hi, Isaac:
I am curious about why providing these driver's' implementations (CPU 
Arch/PciHostBridge) by a binary FV and not use MdeModulePkg open source code.

Based on a OCP ppt, the baseline boot flow is:
ACM -> SEC -> UPI/DRAM MRC init/MP Init etc. -> DXE Phase -> ..

I think FSP binary just cover SEC/PEI platform related init, and DXE phase's 
drivers should adopt standard UDK open source code.

And it seems KabyLake/Whiskeylake use open source UDK Dxe phase's drivers.

Thanks
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tiger Liu(BJ-RD)
Sent: Thursday, November 7, 2019 5:21 PM
To: Oram, Isaac W ; devel@edk2.groups.io; Kubacki, 
Michael A 
Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Hi, Isaac:
Got it!

Maybe, these three DXE/SMM drivers are all provided by FvPostMemorySilicon.Fv 
#UefiCpuPkg/CpuDxe/CpuDxe.inf #UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
#MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf

Thanks
-邮件原件-
发件人: Oram, Isaac W 
发送时间: 2019年11月8日 6:18
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) ; Kubacki, 
Michael A 
主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Tiger,

I believe that the solution used a silicon specific PciHostBridge driver 
provided by one of the binary FV providing silicon components (probably FILE = 
$(SILICON_BIN_PKG)/FvPostMemorySilicon/$(TARGET)/FvPostMemorySilicon.Fv).

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tiger Liu(BJ-RD)
Sent: Wednesday, November 6, 2019 9:45 PM
To: Kubacki, Michael A ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Hi, Michael:
I have a question about PCI host bridge driver in Olympus board.

I found PciHostBridge driver is deleted in CoreDxeInclude.dsc.
  #MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf

So, it seems BoardMtOlympus\PlatformPkg.dsc does not include any PciHostBridge 
driver implementation.

Thanks
-邮件原件-
发件人: Tiger Liu(BJ-RD)
发送时间: 2019年11月6日 15:48
收件人: 'Kubacki, Michael A' ; devel@edk2.groups.io
主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Got it.

Thank you very much.

Best wishes,
-邮件原件-
发件人: Kubacki, Michael A 
发送时间: 2019年11月6日 15:05
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Unfortunately not. That's why we're trying to add support for these other 
commercially available systems such as the System 76 laptop and the UP Xtreme 
board.

The next product family that will likely get an open source board package added 
will be Comet Lake (client) as tracked here: 
https://bugzilla.tianocore.org/show_bug.cgi?id=2280

We very much would like to add back open source server platform code including 
support for a commercially available board and we're evaluating a few options 
but there's nothing definitive enough at the moment to give a target system or 
ETA.

Thanks,
Michael

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tiger
> Liu(BJ-RD)
> Sent: Tuesday, November 5, 2019 10:47 PM
> To: devel@edk2.groups.io; Kubacki, Michael A
> 
> Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS
> code support
>
> Hi, Michael:
> Got it.
> Thanks
>
> For "Reference and Validation Platform" motherboard, could user buy it
> at open market?
> For example, buy it on Amazon.
>
> Thanks
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Kubacki, Michael A
> 发送时间: 2019年11月6日 10:12
> 收件人: Tiger Liu(BJ-RD) ; devel@edk2.groups.io
> 主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code
> support
>
> No other OCP support at the moment. Current board support is
> summarized in this Readme.md:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Readme.md#intel
>
> Newer Intel platform firmware is following the EDK II Minimum Platform
> specification and the boards supported are documented here:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Platform/Intel/Readme.md#supported-hardware
>
> KabylakeOpenBoardPkg supports two boards:
>  * KabylakeRvp3 (an Intel Kaby Lake Y Reference and Validation
> Platform)
>  * GalagoPro3 (a commercial laptop with Kaby Lake from System 76)
>
> WhiskeylakeOpenBoardPkg currently supports:
>  * WhiskeylakeURvp (an Intel Whiskey Lake U Reference and Validation
> Platform)
>
> There is a plan to add board support for the UP Xtreme board in
> WhiskeylakeOpenBoardPkg soon as noted here:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2191.
>
> Thanks,
> Michael
>
> > -Original Message-
> > From: Tiger Liu(BJ-RD) 
> > Sent: Tuesday, November 5, 2019 5:32 PM
> > To: Kubacki, Michael A ;
> > devel@edk2.groups.io
> > Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS
> > code support
> >
> > Hi, Michael:
> > Thanks for your reply!
> >
> > Is there any other project For Intel open source platform

Re: [edk2-devel] [PATCH] IntelSiliconPkg/Library:Add BaseConfigBlockLib Library

Ethan,
What if all of the debug message are removed?
Library especially very fundamental like ConfigBlock is better to be quite.
It's the ConfigBlock API designer's responsibility to ensure the error is 
returned
properly to caller, otherwise it's the API's bug.
When the API can return correct status out, it's caller's responsibility to 
check
the status and do proper handling of the errors.

With the debug message added in this fundamental library, it may give callers 
wrong
impression that the library itself can handle the error and callers don't need 
to check
the error status.

If we search code in MdePkg, quite few debug messages are printed out from 
library code.

Thanks,
Ray

> -Original Message-
> From: Tsao, Ethan 
> Sent: Thursday, November 7, 2019 4:14 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> Subject: RE: [PATCH] IntelSiliconPkg/Library:Add BaseConfigBlockLib Library
> 
> Hi Ray,
> Thanks your good input. I just review all debug message and most print is for
> error report purpose, such as allocate memory failure,...etc.
> From my opinion, this kind debug message is useful for BIOS when
> unexpected error happen. In normal case, it will not be print.
> 
> Best Regards,
> Ethan
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Thursday, November 7, 2019 3:15 PM
> > To: Tsao, Ethan ; edk2-de...@lists.01.org
> > Cc: Chaganty, Rangasai V 
> > Subject: RE: [PATCH] IntelSiliconPkg/Library:Add BaseConfigBlockLib Library
> >
> > Given the patch only moves the code from one place to another, I am ok
> with
> > that.
> >
> > By the way, is it still valuable to have so many debug messages everywhere
> in
> > this library?
> > If no, can we remove them or at least some of them?
> >
> > Debug messages are valuable I agree. But we also need to think about
> producing
> > helpful debug messages, not treated by platform developers as noise : )
> >
> >
> > > -Original Message-
> > > From: Tsao, Ethan 
> > > Sent: Thursday, November 7, 2019 11:31 AM
> > > To: edk2-de...@lists.01.org
> > > Cc: Chaganty, Rangasai V ; Ni, Ray
> > > 
> > > Subject: [PATCH] IntelSiliconPkg/Library:Add BaseConfigBlockLib
> > > Library
> > >
> > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2318
> > >
> > > Establish one copy of Config blocks library class and instance in
> > > IntelSiliconPkg and remove copies from other silicon packages , like
> > > KabyLakeSiliconPkg, CoffelakeSiliconPkg.
> > >
> > > Signed-off-by: Ethan Tsao 
> > > Cc: Sai Chaganty 
> > > Cc: Ray Ni 
> > > ---
> > >
> > >
> Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlo
> > > ckLib.c  | 146 
> > > -
> 
> > -
> > > --
> > > --
> > >
> > >
> Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlo
> > > ckLib.inf|  29 -
> > >  Silicon/Intel/{KabylakeSiliconPkg =>
> > > IntelSiliconPkg}/Library/BaseConfigBlockLib/BaseConfigBlockLib.c   |   0
> > >  Silicon/Intel/{KabylakeSiliconPkg =>
> > > IntelSiliconPkg}/Library/BaseConfigBlockLib/BaseConfigBlockLib.inf |   0
> > >  4 files changed, 175 deletions(-)
> > >
> > > diff --git
> > > a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseCo
> > > nfigB
> > > lockLib.c
> > > b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseCo
> > > nfig
> > > BlockLib.c
> > > deleted file mode 100644
> > > index 369dab97ee..00
> > > ---
> > > a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseCo
> > > nfigB
> > > lockLib.c
> > > +++ /dev/null
> > > @@ -1,146 +0,0 @@
> > > -/** @file
> > > -  Library functions for Config Block management.
> > > -
> > > -  Copyright (c) 2019 Intel Corporation. All rights reserved. 
> > > -
> > > -  SPDX-License-Identifier: BSD-2-Clause-Patent -**/
> > > -
> > > -#include 
> > > -#include 
> > > -#include 
> > > -#include  -#include
> > > 
> > > -
> > > -/**
> > > -  Create config block table
> > > -
> > > -  @param[in] TotalSize- Max size to be allocated 
> > > for the
> Config
> > > Block Table
> > > -  @param[out]ConfigBlockTableAddress  - On return, points to a
> pointer
> > > to the beginning of Config Block Table Address
> > > -
> > > -  @retval EFI_INVALID_PARAMETER - Invalid Parameter
> > > -  @retval EFI_OUT_OF_RESOURCES  - Out of resources
> > > -  @retval EFI_SUCCESS   - Successfully created Config Block 
> > > Table at
> > > ConfigBlockTableAddress
> > > -**/
> > > -EFI_STATUS
> > > -EFIAPI
> > > -CreateConfigBlockTable (
> > > -  IN UINT16TotalSize,
> > > -  OUTVOID  **ConfigBlockTableAddress
> > > -  )
> > > -{
> > > -  CONFIG_BLOCK_TABLE_HEADER *ConfigBlkTblAddrPtr;
> > > -  UINT32ConfigBlkTblHdrSize;
> > > -
> > > -  ConfigBlkTblHdrSize =

Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2 00/12] New PCI features - MPS, MRRS, RO, NS, CTO

Ashraf,
For such a big change, can you please create a branch in github in your 
personal repo?
It helps a lot for code review.

Or can you please reply the mail with all patches attached? Groups.io supports 
attachments.

Thanks,
Ray

> -Original Message-
> From: Javeed, Ashraf 
> Sent: Friday, November 8, 2019 12:10 PM
> To: devel@edk2.groups.io; Javeed, Ashraf 
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray 
> Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2
> 00/12] New PCI features - MPS, MRRS, RO, NS, CTO
> 
> Hi Jian, Hao, and Ray;
> Kindly review my patch set from 1 to 12 to enhance the PCI Bus driver to
> support the new PCI features..
> 
> Thanks
> Ashraf
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> Javeed,
> > Ashraf
> > Sent: Saturday, November 2, 2019 11:30 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Wu, Hao A
> > ; Ni, Ray 
> > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2
> 00/12]
> > New PCI features - MPS, MRRS, RO, NS, CTO
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2194
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2313
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> >
> > The EDK2 Kernel PciBusDxe driver is enhanced to enable the
> > configuration of PCI features like
> > (1) Max_Payload_Size
> > (2) Max_Read_Req_Size
> > (3) Relax Ordering
> > (4) No-Snoop
> > (5) Completion Timeout
> >
> > Max_Payload_Size:- The PCI Device Control register provides this
> > feature register field which controls the maximum data packet (TLP)
> > size that a PCI device should maintain as a requester. The PCI Bus
> > driver is required to maintain a highest common value supported by all
> > the PCI devices in a PCIe hierarchy, especially in case of isochronous
> applications.
> >
> > Max_Read_Req_Size:- The PCI Device Control register provides this
> > feature register field which controls the maximum memory read request
> > size that a PCI device should maintain as a requester. The PCI Bus
> > driver is required to maintain a common value, same as
> > Max_Payload_Size, in case of isochronous applications only; or else,
> > it should maintain the user requested value uniformly in a PCIe hierarchy
> (PCI root port and its downstream devices).
> >
> > Relax Ordering:- The PCI Device Control register has the enabling of
> > Relax Ordering functionality register field (bit 4). If this bit is
> > Set, the PCI Function is permitted to set the Relaxed Ordering bit in
> > the Attributes field of transactions it initiates that do not require
> > strong write ordering (see PCI Base Specification 4, Section 2.2.6.4
> > and Sect- ion 2.4). Any supporting PCI function is expected have this
> > bit enabled as per its hardware default; the code enhancement is to
> > enable / disable as per the PCI device policy provided by the platform
> > firmware. If no device policy override is provided than it shall be ignored 
> > by
> the PCI Bus driver for that PCI function.
> >
> > No-Snoop:- The PCI Device Control register has the enabling of
> > No-Snoop functionality register field (bit 11). If this bit is Set,
> > the PCI Function is permitted to Set the No Snoop bit in the Requester
> > Attributes of transactions it initiates that do not require hardware
> > enforced cache coherency (see PCI Base Specification 4, Section
> > 2.2.6.5). Any supporting PCI function is expected have this bit
> > enabled as per its hardware default; the code enhancement is to enable
> > / disable as per the PCI device policy provided by the platform
> > firmware. If no device policy override is provided than it shall be ignored 
> > by
> the PCI Bus driver for that PCI function.
> >
> > Completion Timeout:- The PCI Device Control 2 register provides two
> > register fields based on its Device Capability 2 register; the CTO
> > Ranges (bits [3:0]) and the disabling of CTO detection mechanism (bit
> > 4). The software is permitted to change the CTO ranges and
> > enable/disable the CTO detection mechanism any time. The code
> > enhancement here is to override these register fields as per the
> > platform device policy. If no device policy override is provided than it 
> > shall
> be ignored by the PCI Bus driver for that PCI function.
> >
> > The PCI Base Specification 4 Revision 1 contains detailed information
> > about these features. The EDK2 PCI Bus driver needs to enable the
> > configuration of these features as per the PCI Base specification.
> >
> > The EDK2 PCI Bus driver also needs to take the PCI device-specific
> > platform policy into the consideration while programming these
> > features; thus the code changes to support these, is explicitly
> > dependent on the new PCI Platform Protocol interface definition
> > defined in the below
> > record:-
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> >
> >
> > Signed-off-by: Ashraf Javeed 
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > ---
>

Re: [edk2-devel] [PATCH V3 0/8] Update SMBIOS 3.3.0

Zhichao,
I took a  look at the patch 5/8.
Given the value is already defined in MdePkg header file, can you please
update the implementation to avoid using magic number?

I suggest you do the code change in two parts: one patch to modify existing
magic numbers to use macros/enums defined in MdePkg, the other patch
to add new mappings without using magic numbers.

I didn't check the other patches after 5/8. If there are magic numbers as well,
can you please update them as well?

Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gao,
> Zhichao
> Sent: Thursday, November 7, 2019 8:52 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray ; Chaganty, Rangasai V
> 
> Subject: [edk2-devel] [PATCH V3 0/8] Update SMBIOS 3.3.0
> 
> The following changes were made to version 3.2.0 of the document to
> produce this
> version:
>  System Slots (Type 9):
>  Add PCI Express Gen 4 values
>  Clarify bus number usage for PCI Express  Memory Device (Type 17):
>  Add new memory device type value (HBM) and new form factor value (Die)
>  Update the string for Intel persistent memory  Various:
>  Add support for RISC-V processors, add structure type 44 (processor-
> additional information)  add support for CXL Flexbus
> 
> V2:
> Add the new definition to MdePkg/Smbios.h.
> 
> V3:
> Avoid change the enum name to casue the incompatible issue.
> Add the comment instead change the enum define name.
> 
> Notes:
> Clarify bus number usage for PCI Express - Update the spec no code change
> requirement Add support for RISC-V processors, add structure type 44
> (processor-additional information) - Already done at
> https://bugzilla.tianocore.org/show_bug.cgi?id=2202
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Sai Chaganty 
> Signed-off-by: Zhichao Gao 
> 
> Zhichao Gao (8):
>   MdePkg/Smbios.h: SMBIOS 3.3.0 add PCI gen4 values for type 9
>   MdePkg/Smbios.h: SMBIOS 3.3.0 add support for CXL Flexbus
>   MdePkg/Smbios.h: SMBIOS 3.3.0 Add value HBM and Die for type 17
>   MdePkg/Smbios.h: SMBIOS 3.3.0 Update Intel Persistent Memory string
>   ShellPkg/SmbiosView: SMBIOS 3.3.0 add PCI gen4 values for type 9
>   ShellPkg/SmbiosView: SMBIOS 3.3.0 add support for CXL Flexbus
>   ShellPkg/SmbiosView: SMBIOS 3.3.0 Add value HBM and Die for type 17
>   ShellPkg/SmbiosView: SMBIOS 3.3.0 Update "Intel persistent memory"
> 
>  MdePkg/Include/IndustryStandard/SmBios.h   | 25 ---
>  .../SmbiosView/QueryTable.c| 48 
> +-
>  2 files changed, 66 insertions(+), 7 deletions(-)
> 
> --
> 2.16.2.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50284): https://edk2.groups.io/g/devel/message/50284
Mute This Topic: https://groups.io/mt/44839633/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] MdeModulePkg/SmiHandlerProfileInfo: Update the ranges of array index

2019-11-07 Thread Zhang, Shenglei

Take the below code as example.
  if (Type >= 0 && Type <= ARRAY_SIZE(mSxTypeString)) {
return mSxTypeString[Type];

The variable 'Type' used as index should range from 0 ~ ARRAY_SIZE-1.
So the if statement should be :
  if (Type >= 0 && Type < ARRAY_SIZE(mSxTypeString)) {

And other cases should also follow this rule.

REF:
https://bugzilla.tianocore.org/show_bug.cgi?id=2272
https://bugzilla.tianocore.org/show_bug.cgi?id=2287
https://bugzilla.tianocore.org/show_bug.cgi?id=2288
https://bugzilla.tianocore.org/show_bug.cgi?id=2289
https://bugzilla.tianocore.org/show_bug.cgi?id=2290

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Shenglei Zhang 
---
 .../SmiHandlerProfileInfo/SmiHandlerProfileInfo.c  | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c 
b/MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c
index 0f7163160b4e..4f195b16ceb0 100644
--- a/MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c
+++ b/MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c
@@ -382,7 +382,7 @@ SxTypeToString (
   IN EFI_SLEEP_TYPE  Type
   )
 {
-  if (Type >= 0 && Type <= ARRAY_SIZE(mSxTypeString)) {
+  if (Type >= 0 && Type < ARRAY_SIZE(mSxTypeString)) {
 return mSxTypeString[Type];
   } else {
 AsciiSPrint (mNameString, sizeof(mNameString), "0x%x", Type);
@@ -407,7 +407,7 @@ SxPhaseToString (
   IN EFI_SLEEP_PHASE Phase
   )
 {
-  if (Phase >= 0 && Phase <= ARRAY_SIZE(mSxPhaseString)) {
+  if (Phase >= 0 && Phase < ARRAY_SIZE(mSxPhaseString)) {
 return mSxPhaseString[Phase];
   } else {
 AsciiSPrint (mNameString, sizeof(mNameString), "0x%x", Phase);
@@ -457,7 +457,7 @@ StandbyButtonPhaseToString (
   IN EFI_STANDBY_BUTTON_PHASE  Phase
   )
 {
-  if (Phase >= 0 && Phase <= ARRAY_SIZE(mStandbyButtonPhaseString)) {
+  if (Phase >= 0 && Phase < ARRAY_SIZE(mStandbyButtonPhaseString)) {
 return mStandbyButtonPhaseString[Phase];
   } else {
 AsciiSPrint (mNameString, sizeof(mNameString), "0x%x", Phase);
@@ -483,7 +483,7 @@ IoTrapTypeToString (
   IN EFI_SMM_IO_TRAP_DISPATCH_TYPE  Type
   )
 {
-  if (Type >= 0 && Type <= ARRAY_SIZE(mIoTrapTypeString)) {
+  if (Type >= 0 && Type < ARRAY_SIZE(mIoTrapTypeString)) {
 return mIoTrapTypeString[Type];
   } else {
 AsciiSPrint (mNameString, sizeof(mNameString), "0x%x", Type);
@@ -508,7 +508,7 @@ UsbTypeToString (
   IN EFI_USB_SMI_TYPE  Type
   )
 {
-  if (Type >= 0 && Type <= ARRAY_SIZE(mUsbTypeString)) {
+  if (Type >= 0 && Type < ARRAY_SIZE(mUsbTypeString)) {
 return mUsbTypeString[Type];
   } else {
 AsciiSPrint (mNameString, sizeof(mNameString), "0x%x", Type);
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50283): https://edk2.groups.io/g/devel/message/50283
Mute This Topic: https://groups.io/mt/47268969/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 0/6] Add Device Security driver

Right. I have put them to 
edk2-platforms\Silicon\Intel\IntelSiliconPkg\Feature\PcieSecurity. Similar to 
Capsule, SmmAccess, VTd.

Thank you
Yao Jiewen

> -Original Message-
> From: Javeed, Ashraf 
> Sent: Friday, November 8, 2019 12:23 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Subject: RE: [edk2-devel] [PATCH V3 0/6] Add Device Security driver
> 
> Jiewen,
> It could be better to organize your PcieSecurity driver stack under a common
> "Pci" folder; like under the following path:
> "Intel/IntelSiliconPkg/Feature/Pci"
> 
> Thanks
> Ashraf
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen
> > Sent: Thursday, November 7, 2019 7:08 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [PATCH V3 0/6] Add Device Security driver
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> >
> > === V3 ===
> >
> > The V3 version addresses the feedback below:
> >
> > Liming Gao:
> > 1. Add SPDM spec version and align to latest one 0.99a.
> >
> > Rangasai Chaganty:
> > 1. put a reference to the spec at the file header, for Intel PCI security 
> > spec.
> > 2. add some high level description above the structure definition that
> >describes the structure.
> > 3. on the services "GetDevicePolicy" and "SetDeviceState", Add more error
> >return states
> >
> > Ray Ni:
> > 1. add comments to each field of structures like
> > EDKII_DEVICE_SECURITY_POLICY
> >and EDKII_DEVICE_SECURITY_STATE.
> > 2. add comments to all the macros defined in this patch to explain the 
> > meaning
> >and more important how they are going to impact the logic.
> > 3. make the macro short
> > EDKII_DEVICE_MEASUREMENT_POLICY_REQUIRED ->
> > EDKII_DEVICE_MEASUREMENT_REQUIRED
> > EDKII_DEVICE_AUTHENTICATION_POLICY_REQUIRED ->
> > EDKII_DEVICE_AUTHENTICATION_REQUIRED
> > 4. rename the SetDeviceState to NotifyDeviceState.
> > 5. add comments to explain clearly what SetDeviceState() needs to do.
> > 6. change the prototype so that caller needs to pass in a policy structure 
> > and
> >GetDevicePolicy() fills the structure buffer using CopyMem.
> > 7. add the version macro for
> > EDKII_DEVICE_SECURITY_POLICY_PROTOCOL.Version,
> >securitypolicy.version and securitystate.version.
> > 8. add clear debug information for DvSec capability header.
> >
> > === V2 ===
> >
> > This patch series add support for device security based upon the DMTF SPDM
> > specification.
> >
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a
> > .zip
> >
> > We did design review at 18 Oct, 2019.
> > https://edk2.groups.io/g/devel/files/Designs/2019/1018
> > And the feedback from the meeting is addressed.
> > https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-
> > Device%20Firmware%20Security%20v2.pdf
> >
> > The Device security protocol is added in EDKII repo.
> > Here we add the producer what follows Intel PCI security spec to do the 
> > device
> > firmware measurement.
> > https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> > security-enhancements-spec.html
> >
> > The EDKII repo update is at
> > https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
> > The EDKII platform repo update is at https://github.com/jyao1/edk2-
> > platforms/tree/DeviceSecurityMasterV2
> >
> > The validation has been done on a Intel internal platform.
> > The device measurement can be shown in TCG event log.
> >
> > signed-off-by: Jiewen Yao 
> >
> > Jiewen Yao (6):
> >   IntelSiliconPkg/Include: Add Intel PciSecurity definition.
> >   IntelSiliconPkg/Include: Add Platform Device Security Policy protocol
> >   IntelSiliconPkg/dec: Add ProtocolGuid definition.
> >   IntelSiliconPkg/IntelPciDeviceSecurityDxe: Add PciSecurity.
> >   IntelSiliconPkg/SamplePlatformDevicePolicyDxe: Add sample policy.
> >   IntelSiliconPkg/dsc: Add Device Security component.
> >
> >  .../IntelPciDeviceSecurityDxe.c   | 697 ++
> >  .../IntelPciDeviceSecurityDxe.inf |  45 ++
> >  .../TcgDeviceEvent.h  | 178 +
> >  .../SamplePlatformDevicePolicyDxe.c   | 204 +
> >  .../SamplePlatformDevicePolicyDxe.inf |  40 +
> >  .../IndustryStandard/IntelPciSecurity.h   |  92 +++
> >  .../Protocol/PlatformDeviceSecurityPolicy.h   | 128 
> >  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dec |   4 +
> >  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dsc |   3 +
> >  9 files changed, 1391 insertions(+)
> >  create mode 100644
> >
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> > elPciDeviceSecurityDxe.c
> >  create mode 100644
> >
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> > elPciDeviceSecurityDxe.inf
> >  create mode 100644
> >
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Tcg
> > DeviceEvent.h
> >  create mode 100644
> >
>

Re: [edk2-devel] [PATCH V3 0/6] Add Device Security driver

2019-11-07 Thread Javeed, Ashraf

Jiewen,
It could be better to organize your PcieSecurity driver stack under a common 
"Pci" folder; like under the following path:
"Intel/IntelSiliconPkg/Feature/Pci"

Thanks
Ashraf

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Thursday, November 7, 2019 7:08 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH V3 0/6] Add Device Security driver
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> === V3 ===
> 
> The V3 version addresses the feedback below:
> 
> Liming Gao:
> 1. Add SPDM spec version and align to latest one 0.99a.
> 
> Rangasai Chaganty:
> 1. put a reference to the spec at the file header, for Intel PCI security 
> spec.
> 2. add some high level description above the structure definition that
>describes the structure.
> 3. on the services "GetDevicePolicy" and "SetDeviceState", Add more error
>return states
> 
> Ray Ni:
> 1. add comments to each field of structures like
> EDKII_DEVICE_SECURITY_POLICY
>and EDKII_DEVICE_SECURITY_STATE.
> 2. add comments to all the macros defined in this patch to explain the meaning
>and more important how they are going to impact the logic.
> 3. make the macro short
> EDKII_DEVICE_MEASUREMENT_POLICY_REQUIRED ->
> EDKII_DEVICE_MEASUREMENT_REQUIRED
> EDKII_DEVICE_AUTHENTICATION_POLICY_REQUIRED ->
> EDKII_DEVICE_AUTHENTICATION_REQUIRED
> 4. rename the SetDeviceState to NotifyDeviceState.
> 5. add comments to explain clearly what SetDeviceState() needs to do.
> 6. change the prototype so that caller needs to pass in a policy structure and
>GetDevicePolicy() fills the structure buffer using CopyMem.
> 7. add the version macro for
> EDKII_DEVICE_SECURITY_POLICY_PROTOCOL.Version,
>securitypolicy.version and securitystate.version.
> 8. add clear debug information for DvSec capability header.
> 
> === V2 ===
> 
> This patch series add support for device security based upon the DMTF SPDM
> specification.
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a
> .zip
> 
> We did design review at 18 Oct, 2019.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018
> And the feedback from the meeting is addressed.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-
> Device%20Firmware%20Security%20v2.pdf
> 
> The Device security protocol is added in EDKII repo.
> Here we add the producer what follows Intel PCI security spec to do the device
> firmware measurement.
> https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> security-enhancements-spec.html
> 
> The EDKII repo update is at
> https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
> The EDKII platform repo update is at https://github.com/jyao1/edk2-
> platforms/tree/DeviceSecurityMasterV2
> 
> The validation has been done on a Intel internal platform.
> The device measurement can be shown in TCG event log.
> 
> signed-off-by: Jiewen Yao 
> 
> Jiewen Yao (6):
>   IntelSiliconPkg/Include: Add Intel PciSecurity definition.
>   IntelSiliconPkg/Include: Add Platform Device Security Policy protocol
>   IntelSiliconPkg/dec: Add ProtocolGuid definition.
>   IntelSiliconPkg/IntelPciDeviceSecurityDxe: Add PciSecurity.
>   IntelSiliconPkg/SamplePlatformDevicePolicyDxe: Add sample policy.
>   IntelSiliconPkg/dsc: Add Device Security component.
> 
>  .../IntelPciDeviceSecurityDxe.c   | 697 ++
>  .../IntelPciDeviceSecurityDxe.inf |  45 ++
>  .../TcgDeviceEvent.h  | 178 +
>  .../SamplePlatformDevicePolicyDxe.c   | 204 +
>  .../SamplePlatformDevicePolicyDxe.inf |  40 +
>  .../IndustryStandard/IntelPciSecurity.h   |  92 +++
>  .../Protocol/PlatformDeviceSecurityPolicy.h   | 128 
>  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dec |   4 +
>  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dsc |   3 +
>  9 files changed, 1391 insertions(+)
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> elPciDeviceSecurityDxe.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> elPciDeviceSecurityDxe.inf
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Tcg
> DeviceEvent.h
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyD
> xe/SamplePlatformDevicePolicyDxe.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyD
> xe/SamplePlatformDevicePolicyDxe.inf
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolicy.h
> 
> --
> 2.19.2.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50281):

Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2 00/12] New PCI features - MPS, MRRS, RO, NS, CTO

2019-11-07 Thread Javeed, Ashraf

Hi Jian, Hao, and Ray;
Kindly review my patch set from 1 to 12 to enhance the PCI Bus driver to 
support the new PCI features..

Thanks
Ashraf

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Javeed,
> Ashraf
> Sent: Saturday, November 2, 2019 11:30 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray 
> Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2 00/12]
> New PCI features - MPS, MRRS, RO, NS, CTO
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2194
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2313
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> 
> The EDK2 Kernel PciBusDxe driver is enhanced to enable the configuration of 
> PCI
> features like
> (1) Max_Payload_Size
> (2) Max_Read_Req_Size
> (3) Relax Ordering
> (4) No-Snoop
> (5) Completion Timeout
> 
> Max_Payload_Size:- The PCI Device Control register provides this feature
> register field which controls the maximum data packet (TLP) size that a PCI
> device should maintain as a requester. The PCI Bus driver is required to 
> maintain
> a highest common value supported by all the PCI devices in a PCIe hierarchy,
> especially in case of isochronous applications.
> 
> Max_Read_Req_Size:- The PCI Device Control register provides this feature
> register field which controls the maximum memory read request size that a PCI
> device should maintain as a requester. The PCI Bus driver is required to 
> maintain
> a common value, same as Max_Payload_Size, in case of isochronous
> applications only; or else, it should maintain the user requested value 
> uniformly
> in a PCIe hierarchy (PCI root port and its downstream devices).
> 
> Relax Ordering:- The PCI Device Control register has the enabling of Relax
> Ordering functionality register field (bit 4). If this bit is Set, the PCI 
> Function is
> permitted to set the Relaxed Ordering bit in the Attributes field of 
> transactions it
> initiates that do not require strong write ordering (see PCI Base 
> Specification 4,
> Section 2.2.6.4 and Sect- ion 2.4). Any supporting PCI function is expected 
> have
> this bit enabled as per its hardware default; the code enhancement is to 
> enable /
> disable as per the PCI device policy provided by the platform firmware. If no
> device policy override is provided than it shall be ignored by the PCI Bus 
> driver
> for that PCI function.
> 
> No-Snoop:- The PCI Device Control register has the enabling of No-Snoop
> functionality register field (bit 11). If this bit is Set, the PCI Function 
> is permitted
> to Set the No Snoop bit in the Requester Attributes of transactions it 
> initiates
> that do not require hardware enforced cache coherency (see PCI Base
> Specification 4, Section 2.2.6.5). Any supporting PCI function is expected 
> have
> this bit enabled as per its hardware default; the code enhancement is to 
> enable /
> disable as per the PCI device policy provided by the platform firmware. If no
> device policy override is provided than it shall be ignored by the PCI Bus 
> driver
> for that PCI function.
> 
> Completion Timeout:- The PCI Device Control 2 register provides two register
> fields based on its Device Capability 2 register; the CTO Ranges (bits [3:0]) 
> and
> the disabling of CTO detection mechanism (bit 4). The software is permitted to
> change the CTO ranges and enable/disable the CTO detection mechanism any
> time. The code enhancement here is to override these register fields as per 
> the
> platform device policy. If no device policy override is provided than it 
> shall be
> ignored by the PCI Bus driver for that PCI function.
> 
> The PCI Base Specification 4 Revision 1 contains detailed information about
> these features. The EDK2 PCI Bus driver needs to enable the configuration of
> these features as per the PCI Base specification.
> 
> The EDK2 PCI Bus driver also needs to take the PCI device-specific platform
> policy into the consideration while programming these features; thus the code
> changes to support these, is explicitly dependent on the new PCI Platform
> Protocol interface definition defined in the below
> record:-
> https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> 
> 
> Signed-off-by: Ashraf Javeed 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> ---
> 
> V2: Fixed message format and added feature change reference links
> ---
> 
> Ashraf Javeed (12):
>   MdeModulePkg/PciBusDxe:New PCI features separation with PCD
>   PciBusDxe: Reorganize the PCI Platform Protocol usage code
>   PciBusDxe: Separation of the PCI device registration and start
>   PciBusDxe: Inclusion of new PCI Platform Protocol 2
>   PciBusDxe: Setup sub-phases for PCI feature enumeration
>   PciBusDxe: Integration of setup for PCI feature enumeration
>   PciBusDxe: Record the PCI-Express Capability Structure
>   PciBusDxe: New PCI feature Max_Payload_Size
>   PciBusDxe: New PCI feature Max_Read_Req_Size
>   PciBusDxe: New PCI feature Relax Ordering
>

Re: [edk2-devel] TianoCore Community Meeting - APAC/NAMO

2019-11-07 Thread Brian Richardson

Meeting Minutes 2019-11-07 TianoCore Community Meeting (APAC/NAMO)

Community Manager
* Stephano Cetola has moved to a position with the Linux Foundation. 
Thanks to Stephano for all of his work supporting and growing the TianoCore 
community.
* Brian Richardson (Intel) is temporarily serving as community manager, 
covering public facing items (community meetings, events). Thanks to other 
community members for help covering bug triage and design meetings.
* There is a plan to bring on a new community manager in a few months.
* Brian will update calendar invites for future meetings.

FOSDEM - Feb 1-2, 2020 in Brussels.
* Large open source firmware conference in Europe (~8,000 attendees).
* First year there is a dedicated 'open source firmware' track room. 
Covers topics like EDK II, coreboot, LinuxBoot, u-boot, and OpenBMC.
* Track room runs on Saturday (Feb 1). Should be a dozen 20 minute 
presentation slots available.
* CFP for firmware room closes December 1st.
* https://lists.fosdem.org/pipermail/fosdem/2019q4/002933.html

UEFI SCT - UTWG is looking for contributors. Plans to integrate UEFI SCT into 
CI system, but not as many resources working on the project at this time.

TianoCore CI Process
* v4 patch series is under review. Maintainers will need to review 
before it is active on edk2 master. Uses pull request instead of direct push to 
trigger CI.
* Please use labeling properly (don't set 'push' label for personal 
build). Push label causes changes to be pushed if all tests pass.
* Once CI is active and tested (1-2 weeks), write access on the CI 
repos will be restricted to admins.

Code First Process - under discussion in stewards meetings
* Goal is a process to develop proposals for future UEFI spec 
improvements in open source prior to submission to the UEFI Forum.
* Repo for development - edk2-staging is preferred. Need to 
identify/filter 'code first' branches. 
* Naming convention will be important to distinguish pre-spec 
implementations.
* Next Steps: RFC for code first process (under development).

Linux Line Endings - still in plan, after next stable tag. Contributors should 
raise issues early. A 'converted fork' can be used for community testing.

Thanks ... br

-Original Appointment-
From: devel@edk2.groups.io Group  
Sent: None
To: devel@edk2.groups.io Group
Subject: TianoCore Community Meeting - APAC/NAMO
When: Thursday, November 7, 2019 7:30 PM-8:00 PM (UTC-08:00) Pacific Time (US & 
Canada).
Where: https://bluejeans.com/889357567?src=join_info

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50279): https://edk2.groups.io/g/devel/message/50279
Mute This Topic: https://groups.io/mt/47161389/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Liming,
PE is UEFI spec required executable binary format. I like CLANGPDB more than 
CLANGPE given LLVM may generate DRAWF debug symbol even when generating PE.

> -Original Message-
> From: Gao, Liming 
> Sent: Friday, November 8, 2019 9:50 AM
> To: devel@edk2.groups.io; leif.lindh...@linaro.org; Andrew Fish 
> 
> Cc: Ni, Ray ; Justen, Jordan L ; 
> Gao, Liming ; Shi,
> Steven 
> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool 
> chain
> 
> Andrew and Leif:
>   Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will 
> support LLVM9 or the above.
>   So, this tool chain should have the specific word for its purpose, and 
> remove the version 9 to avoid the confuse.
> 
>   I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. 
> Now, CLANG9 tool chain
>   build rule family just uses CLANGPE. CLANGPE lets user know this tool chain 
> generates PE/COFF image.
>   And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> 
>   Last, I just review the changes. Tool chain name update is not big. If you 
> accept CLANGPE as tool chain name,
>   I will send the patch soon to catch 201911 stable tag.
> 
> Thanks
> Liming
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
> >Lindholm
> >Sent: Friday, November 08, 2019 2:37 AM
> >To: Andrew Fish 
> >Cc: devel@edk2.groups.io; Gao, Liming ; Ni, Ray
> >; Justen, Jordan L 
> >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> >chain
> >
> >Hi Andrew,
> >
> >Yeah, I'm pretty easy with regards to what we change it to.
> >Although if we're bikeshedding, I would prefer not using _ in the
> >toolchain profile name.
> >
> >I'm ... optimistic ... it won't break any of my existing scripts, but
> >since the build system uses it as a
> >__ separator, it would
> >be nice if we didn't risk confusion there.
> >
> >(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> >something along those lines.)
> >
> >Regards,
> >
> >Leif
> >
> >On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> >> Leif,
> >>
> >> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> >CLANG_PDB as assuming the PDE debugging experience is awesome/exists
> >on Linux and macOS is not a given.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm 
> >wrote:
> >> >
> >> > Oops, sorry, missed this in search.
> >> >
> >> > On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
> >> >> Andrew:
> >> >>
> >> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> >> >>  page
> >> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
> >Chain
> >> >>  to introduce it.
> >> >
> >> > Why should users be expected to go and read documentation in order to
> >> > learn that fundamental and incompatible changes to output and debug
> >> > format has been made as part of what looks like a simple version bump?
> >> >
> >> >>  And, we have CLANG38 tool chain. It generates ELF
> >> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> >> >>  release. Current tool chain tag name includes compiler name and
> >> >>  version. There is no specific info in the tool chain name. The
> >> >>  developer can get the more tool chain information from wiki page.
> >> >
> >> > We aleady have the problem that people think they need to use GCC5 to
> >> > build EDK2 since that is the highest named GCC toolchain profile.
> >> >
> >> > Let's not make this situation *worse* by setting up a multidimensional
> >> > feature matrix, based off random numerical values.
> >> >
> >> > So say that we next have a pressing need to create a new toolchain
> >> > profile for clang 10, using the old ELF mechanism. Are you then
> >> > suggesting we set up a table on said wiki page where people have to go
> >> > and look up what the object and debug formats are for each CLANG##
> >> > toolchain profile?
> >> >
> >> > And what if you then end up needing to do the same for the PDB
> >> > flavour?
> >> >
> >> >>  CLANG9 is designed to support Emulator for Windows host only.
> >> >
> >> > Which is why it makes no sense to name it as a successor of
> >> > CLANG38.
> >> >
> >> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> >> >>  try it before.
> >> >>
> >> >>  CLANG9 goal is to align the same compiler in the different host
> >> >>  development environment. It can replace VS or GCC compiler. On
> >> >>  Windows Host, I verify VS debugger for the source level debug. On
> >> >>  Linux host, I have not verified llvm debugger. I will investigate
> >> >>  the debugger solution for OVMF in Linux host.
> >> >
> >> > We are not asking you to throw out this toolchain profile.
> >> >
> >> > We are saying that since the functionality it provides is completely
> >> > unrelated to that of CLANG38, it should not be named in a way that
> >> > suggests it is merely a revision

[edk2-devel] Upcoming Event: TianoCore Community Meeting - APAC/NAMO - Thu, 11/07/2019 7:30pm-8:00pm #cal-reminder

2019-11-07 Thread devel@edk2.groups.io Calendar

*Reminder:* TianoCore Community Meeting - APAC/NAMO

*When:* Thursday, 7 November 2019, 7:30pm to 8:00pm, (GMT-08:00) America/Los 
Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503252 )

*Organizer:* Stephano Cetola stephano.cet...@intel.com ( 
stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20APAC%2FNAMO
 )

*Description:*

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50277): https://edk2.groups.io/g/devel/message/50277
Mute This Topic: https://groups.io/mt/47122145/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

2019-11-07 Thread Tiger Liu(BJ-RD)

Hi, Laszlo:
Got it.

Thanks

Best wishes,
-邮件原件-
发件人: Gao, Liming 
发送时间: 2019年11月7日 23:16
收件人: Laszlo Ersek ; devel@edk2.groups.io; Tiger Liu(BJ-RD) 

主题: RE: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

BaseTools can handle the space between them.

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, November 7, 2019 11:12 PM
> To: Gao, Liming ; devel@edk2.groups.io;
> tiger...@zhaoxin.com
> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
>
> On 11/07/19 15:59, Gao, Liming wrote:
> > In FDF, you also need to specify this file guid and match the one in DSC. 
> > The syntax is like below:
> >
> > INF FILE_GUID= D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
> > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
>
> Thanks! (I assume there is no space character right after
> "FILE_GUID=".)
>
> Cheers
> Laszlo
>
> > Thanks
> > Liming
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of
> >> Laszlo Ersek
> >> Sent: Thursday, November 7, 2019 6:56 PM
> >> To: devel@edk2.groups.io; tiger...@zhaoxin.com
> >> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
> >>
> >> On 11/07/19 05:51, Tiger Liu(BJ-RD) wrote:
> >>> Dear All:
> >>> I have a question about FILE_GUID override rule in dsc file.
> >>> For example:
> >>>   ..
> >>>   UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> >>> 
> >>>   FILE_GUID = D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
> >>> ..
> >>>   }
> >>>
> >>> Usually, will define FILE_GUID in PiSmmCpuDxeSmm.inf .
> >>>
> >>> Why override it in dsc file?
> >>
> >> IIRC, such overrides allow the platform DSC file to build the same
> >> module multiple times, most likely with other overrides too (such
> >> as PCD and lib class resolution). The resultant binaries will not
> >> conflict in any firmware volume / firmware file-system, by FILE_GUID.
> >>
> >> I don't remember the syntax, to be used in the FDF file, for
> >> refering to all of the builds of the same module INF file.
> >>
> >> Thanks
> >> Laszlo
> >>
> >>
> >> 
> >



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

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50276): https://edk2.groups.io/g/devel/message/50276
Mute This Topic: https://groups.io/mt/45221205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH] MinPlatformPkg: Add SetCacheMtrrLib class to dsc.

2019-11-07 Thread Kubacki, Michael A

Reviewed-by: Michael Kubacki 

> -Original Message-
> From: Chiu, Chasel 
> Sent: Thursday, November 7, 2019 6:15 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Desimone, Nathaniel
> L ; Gao, Liming 
> Subject: [edk2-platforms: PATCH] MinPlatformPkg: Add SetCacheMtrrLib
> class to dsc.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2314
> 
> Added SetCacheMtrrLib class to MinPlatformPkg.dsc.
> 
> Cc: Michael Kubacki 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Chasel Chiu 
> ---
>  Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> index 5f9363ff32..17272f819c 100644
> --- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> +++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> @@ -94,6 +94,7 @@
> 
> ReportFvLib|MinPlatformPkg/PlatformInit/Library/PeiReportFvLib/PeiReport
> FvLib.inf
> 
> TestPointCheckLib|MinPlatformPkg/Test/Library/TestPointCheckLib/PeiTest
> PointCheckLib.inf
>TestPointLib|MinPlatformPkg/Test/Library/TestPointLib/PeiTestPointLib.inf
> +
> +
> SetCacheMtrrLib|$(PLATFORM_PACKAGE)/Library/SetCacheMtrrLib/SetCac
> heMt
> + rrLibNull.inf
> 
>  [LibraryClasses.common.DXE_DRIVER]
>#
> @@ -189,4 +190,4 @@
>  !endif
> 
>  [BuildOptions]
> -  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES \ No
> newline at end of file
> +  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> --
> 2.13.3.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50275): https://edk2.groups.io/g/devel/message/50275
Mute This Topic: https://groups.io/mt/47032665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH] MinPlatformPkg: Add SetCacheMtrrLib class to dsc.

Reviewed-by: Liming Gao 

>-Original Message-
>From: Chiu, Chasel
>Sent: Friday, November 08, 2019 10:15 AM
>To: devel@edk2.groups.io
>Cc: Kubacki, Michael A ; Desimone, Nathaniel L
>; Gao, Liming 
>Subject: [edk2-platforms: PATCH] MinPlatformPkg: Add SetCacheMtrrLib class
>to dsc.
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2314
>
>Added SetCacheMtrrLib class to MinPlatformPkg.dsc.
>
>Cc: Michael Kubacki 
>Cc: Nate DeSimone 
>Cc: Liming Gao 
>Signed-off-by: Chasel Chiu 
>---
> Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
>b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
>index 5f9363ff32..17272f819c 100644
>--- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
>+++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
>@@ -94,6 +94,7 @@
>
>ReportFvLib|MinPlatformPkg/PlatformInit/Library/PeiReportFvLib/PeiReport
>FvLib.inf
>
>TestPointCheckLib|MinPlatformPkg/Test/Library/TestPointCheckLib/PeiTestP
>ointCheckLib.inf
>   TestPointLib|MinPlatformPkg/Test/Library/TestPointLib/PeiTestPointLib.inf
>+
>SetCacheMtrrLib|$(PLATFORM_PACKAGE)/Library/SetCacheMtrrLib/SetCach
>eMtrrLibNull.inf
>
> [LibraryClasses.common.DXE_DRIVER]
>   #
>@@ -189,4 +190,4 @@
> !endif
>
> [BuildOptions]
>-  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
>\ No newline at end of file
>+  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
>--
>2.13.3.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50274): https://edk2.groups.io/g/devel/message/50274
Mute This Topic: https://groups.io/mt/47032665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH] MinPlatformPkg: Add SetCacheMtrrLib class to dsc.

2019-11-07 Thread Chiu, Chasel

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2314

Added SetCacheMtrrLib class to MinPlatformPkg.dsc.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc 
b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
index 5f9363ff32..17272f819c 100644
--- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
+++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
@@ -94,6 +94,7 @@
   
ReportFvLib|MinPlatformPkg/PlatformInit/Library/PeiReportFvLib/PeiReportFvLib.inf
   
TestPointCheckLib|MinPlatformPkg/Test/Library/TestPointCheckLib/PeiTestPointCheckLib.inf
   TestPointLib|MinPlatformPkg/Test/Library/TestPointLib/PeiTestPointLib.inf
+  
SetCacheMtrrLib|$(PLATFORM_PACKAGE)/Library/SetCacheMtrrLib/SetCacheMtrrLibNull.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   #
@@ -189,4 +190,4 @@
 !endif
 
 [BuildOptions]
-  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
\ No newline at end of file
+  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
-- 
2.13.3.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50273): https://edk2.groups.io/g/devel/message/50273
Mute This Topic: https://groups.io/mt/47032665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 4/8] MdePkg/Smbios.h: SMBIOS 3.3.0 Update Intel Persistent Memory string

Reviewed-by: Liming Gao 

>-Original Message-
>From: Gao, Zhichao
>Sent: Thursday, November 07, 2019 8:52 AM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D ; Gao, Liming
>; Chaganty, Rangasai V
>
>Subject: [PATCH V3 4/8] MdePkg/Smbios.h: SMBIOS 3.3.0 Update Intel
>Persistent Memory string
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2305
>
>Memory Device (Type 17):
>– SMBIOSCR00179: update the string for Intel persistent memory
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Sai Chaganty 
>Signed-off-by: Zhichao Gao 
>---
> MdePkg/Include/IndustryStandard/SmBios.h | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/MdePkg/Include/IndustryStandard/SmBios.h
>b/MdePkg/Include/IndustryStandard/SmBios.h
>index 9aa8cf3e72..8b3c4d7ba9 100644
>--- a/MdePkg/Include/IndustryStandard/SmBios.h
>+++ b/MdePkg/Include/IndustryStandard/SmBios.h
>@@ -1753,6 +1753,10 @@ typedef enum {
>   MemoryTechnologyNvdimmN   = 0x04,
>   MemoryTechnologyNvdimmF   = 0x05,
>   MemoryTechnologyNvdimmP   = 0x06,
>+  //
>+  // This definition is updated to represent Intel
>+  // Optane DC Presistent Memory in SMBIOS spec 3.3.0
>+  //
>   MemoryTechnologyIntelPersistentMemory = 0x07
> } MEMORY_DEVICE_TECHNOLOGY;
>
>--
>2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50272): https://edk2.groups.io/g/devel/message/50272
Mute This Topic: https://groups.io/mt/44839808/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Andrew and Leif:
  Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will 
support LLVM9 or the above. 
  So, this tool chain should have the specific word for its purpose, and remove 
the version 9 to avoid the confuse. 

  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. 
Now, CLANG9 tool chain 
  build rule family just uses CLANGPE. CLANGPE lets user know this tool chain 
generates PE/COFF image. 
  And, PE/COFF image debug symbol is PDB. So, PE also means PDB. 

  Last, I just review the changes. Tool chain name update is not big. If you 
accept CLANGPE as tool chain name, 
  I will send the patch soon to catch 201911 stable tag. 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
>Lindholm
>Sent: Friday, November 08, 2019 2:37 AM
>To: Andrew Fish 
>Cc: devel@edk2.groups.io; Gao, Liming ; Ni, Ray
>; Justen, Jordan L 
>Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
>chain
>
>Hi Andrew,
>
>Yeah, I'm pretty easy with regards to what we change it to.
>Although if we're bikeshedding, I would prefer not using _ in the
>toolchain profile name.
>
>I'm ... optimistic ... it won't break any of my existing scripts, but
>since the build system uses it as a
>__ separator, it would
>be nice if we didn't risk confusion there.
>
>(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
>something along those lines.)
>
>Regards,
>
>Leif
>
>On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>> Leif,
>>
>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
>CLANG_PDB as assuming the PDE debugging experience is awesome/exists
>on Linux and macOS is not a given.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm 
>wrote:
>> >
>> > Oops, sorry, missed this in search.
>> >
>> > On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
>> >> Andrew:
>> >>
>> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
>> >>  page
>> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
>Chain
>> >>  to introduce it.
>> >
>> > Why should users be expected to go and read documentation in order to
>> > learn that fundamental and incompatible changes to output and debug
>> > format has been made as part of what looks like a simple version bump?
>> >
>> >>  And, we have CLANG38 tool chain. It generates ELF
>> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
>> >>  release. Current tool chain tag name includes compiler name and
>> >>  version. There is no specific info in the tool chain name. The
>> >>  developer can get the more tool chain information from wiki page.
>> >
>> > We aleady have the problem that people think they need to use GCC5 to
>> > build EDK2 since that is the highest named GCC toolchain profile.
>> >
>> > Let's not make this situation *worse* by setting up a multidimensional
>> > feature matrix, based off random numerical values.
>> >
>> > So say that we next have a pressing need to create a new toolchain
>> > profile for clang 10, using the old ELF mechanism. Are you then
>> > suggesting we set up a table on said wiki page where people have to go
>> > and look up what the object and debug formats are for each CLANG##
>> > toolchain profile?
>> >
>> > And what if you then end up needing to do the same for the PDB
>> > flavour?
>> >
>> >>  CLANG9 is designed to support Emulator for Windows host only.
>> >
>> > Which is why it makes no sense to name it as a successor of
>> > CLANG38.
>> >
>> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
>> >>  try it before.
>> >>
>> >>  CLANG9 goal is to align the same compiler in the different host
>> >>  development environment. It can replace VS or GCC compiler. On
>> >>  Windows Host, I verify VS debugger for the source level debug. On
>> >>  Linux host, I have not verified llvm debugger. I will investigate
>> >>  the debugger solution for OVMF in Linux host.
>> >
>> > We are not asking you to throw out this toolchain profile.
>> >
>> > We are saying that since the functionality it provides is completely
>> > unrelated to that of CLANG38, it should not be named in a way that
>> > suggests it is merely a revision update.
>> >
>> > /
>> >Leif
>> >
>> >> Thanks
>> >> Liming
>> >> From: af...@apple.com 
>> >> Sent: Saturday, October 26, 2019 2:45 AM
>> >> To: devel@edk2.groups.io; Gao, Liming 
>> >> Cc: Ni, Ray ; Justen, Jordan L
>
>> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>tool chain
>> >>
>> >> Liming,
>> >>
>> >> Sorry I missed this mail. Thanks for the info! I was doing some research
>into this too and now I think I finally understand. I think the name for the 
>tool
>chain really confused me and we should think about changing the name.
>> >>
>> >> From what I understand CLANG9 means produce PE/COFF directly and
>used the PDB debugging format. I see from the llvm site

Re: [edk2-devel] [edk2-non-osi] [PATCH] edk2-non-osi: Update PurleySiliconBinPkg maintainers

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Desimone, Nathaniel L
> 
> Sent: Wednesday, November 6, 2019 2:19 PM
> To: devel@edk2.groups.io
> Cc: Gillispie; Gillispie, Thad
> ; Bu; Bu, Daocheng
> ; Oram, Isaac W
> ; Kubacki, Michael A
> ; Kinney, Michael D
> 
> Subject: [edk2-non-osi] [PATCH] edk2-non-osi: Update
> PurleySiliconBinPkg maintainers
> 
> Cc: Gillispie, Thad 
> Cc: Bu, Daocheng 
> Cc: Isaac W Oram 
> Cc: Michael A Kubacki 
> Cc: Michael D Kinney 
> Signed-off-by: Nate DeSimone
> 
> ---
>  Maintainers.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index
> f72caa1..0dcd44a 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -56,9 +56,8 @@ M: Michael A Kubacki
> 
>  M: Sai Chaganty 
> Silicon/Intel/PurleySiliconBinPkg-M: Gillispie, Thad
> -M: Bu, Daocheng
> -M: Oram, Isaac W
> +M: Nate DeSimone
> +M: Isaac W Oram
>   Silicon/Intel/QuarkSocBinPkg
> M: Michael D Kinney --
> 2.23.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50270): https://edk2.groups.io/g/devel/message/50270
Mute This Topic: https://groups.io/mt/44640307/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

2019-11-07 Thread Tiger Liu(BJ-RD)

Hi, Isaac:
Got it!

Maybe, these three DXE/SMM drivers are all provided by FvPostMemorySilicon.Fv
#UefiCpuPkg/CpuDxe/CpuDxe.inf
#UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
#MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf

Thanks
-邮件原件-
发件人: Oram, Isaac W 
发送时间: 2019年11月8日 6:18
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) ; Kubacki, 
Michael A 
主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Tiger,

I believe that the solution used a silicon specific PciHostBridge driver 
provided by one of the binary FV providing silicon components (probably FILE = 
$(SILICON_BIN_PKG)/FvPostMemorySilicon/$(TARGET)/FvPostMemorySilicon.Fv).

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tiger Liu(BJ-RD)
Sent: Wednesday, November 6, 2019 9:45 PM
To: Kubacki, Michael A ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Hi, Michael:
I have a question about PCI host bridge driver in Olympus board.

I found PciHostBridge driver is deleted in CoreDxeInclude.dsc.
  #MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf

So, it seems BoardMtOlympus\PlatformPkg.dsc does not include any PciHostBridge 
driver implementation.

Thanks
-邮件原件-
发件人: Tiger Liu(BJ-RD)
发送时间: 2019年11月6日 15:48
收件人: 'Kubacki, Michael A' ; devel@edk2.groups.io
主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Got it.

Thank you very much.

Best wishes,
-邮件原件-
发件人: Kubacki, Michael A 
发送时间: 2019年11月6日 15:05
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Unfortunately not. That's why we're trying to add support for these other 
commercially available systems such as the System 76 laptop and the UP Xtreme 
board.

The next product family that will likely get an open source board package added 
will be Comet Lake (client) as tracked here: 
https://bugzilla.tianocore.org/show_bug.cgi?id=2280

We very much would like to add back open source server platform code including 
support for a commercially available board and we're evaluating a few options 
but there's nothing definitive enough at the moment to give a target system or 
ETA.

Thanks,
Michael

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tiger
> Liu(BJ-RD)
> Sent: Tuesday, November 5, 2019 10:47 PM
> To: devel@edk2.groups.io; Kubacki, Michael A
> 
> Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS
> code support
>
> Hi, Michael:
> Got it.
> Thanks
>
> For "Reference and Validation Platform" motherboard, could user buy it
> at open market?
> For example, buy it on Amazon.
>
> Thanks
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Kubacki, Michael A
> 发送时间: 2019年11月6日 10:12
> 收件人: Tiger Liu(BJ-RD) ; devel@edk2.groups.io
> 主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code
> support
>
> No other OCP support at the moment. Current board support is
> summarized in this Readme.md:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Readme.md#intel
>
> Newer Intel platform firmware is following the EDK II Minimum Platform
> specification and the boards supported are documented here:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Platform/Intel/Readme.md#supported-hardware
>
> KabylakeOpenBoardPkg supports two boards:
>  * KabylakeRvp3 (an Intel Kaby Lake Y Reference and Validation
> Platform)
>  * GalagoPro3 (a commercial laptop with Kaby Lake from System 76)
>
> WhiskeylakeOpenBoardPkg currently supports:
>  * WhiskeylakeURvp (an Intel Whiskey Lake U Reference and Validation
> Platform)
>
> There is a plan to add board support for the UP Xtreme board in
> WhiskeylakeOpenBoardPkg soon as noted here:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2191.
>
> Thanks,
> Michael
>
> > -Original Message-
> > From: Tiger Liu(BJ-RD) 
> > Sent: Tuesday, November 5, 2019 5:32 PM
> > To: Kubacki, Michael A ;
> > devel@edk2.groups.io
> > Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS
> > code support
> >
> > Hi, Michael:
> > Thanks for your reply!
> >
> > Is there any other project For Intel open source platform firmware?
> >
> > KabylakeOpenBoardPkg / WhiskeylakeOpenBoardPkg is also for OCP
> > platform board?
> >
> > Thanks
> > -邮件原件-
> > 发件人: Kubacki, Michael A 
> > 发送时间: 2019年11月6日 2:38
> > 收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
> > 主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code
> > support
> >
> > Hi,
> >
> > The PurleyOpenBoardPkg code is being removed as noted in the
> > following patch series recently sent to the mailing list -
> > https://edk2.groups.io/g/devel/message/49843.
> >
> > It has not been tested in some time and does not align with our
> > vision for Intel open source platform firmware. The effort required
> > to update the code and sustain testing alongside a large number of
> > planned changes elsewhere that

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

2019-11-07 Thread Andrew Fish via Groups.Io




> On Nov 7, 2019, at 12:37 PM, Leif Lindholm  wrote:
> 
> Hi Andrew,
> 
> Yeah, I'm pretty easy with regards to what we change it to.
> Although if we're bikeshedding, I would prefer not using _ in the
> toolchain profile name.
> 
> I'm ... optimistic ... it won't break any of my existing scripts, but
> since the build system uses it as a
> __ separator, it would
> be nice if we didn't risk confusion there.
> 
> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> something along those lines.)
> 

Leif,

Sorry the _ is muscle  memory. I like adding the PDB part as the clang debugger 
does not support PDB for 1st class debugging. 

Thanks,

Andrew Fish

> Regards,
> 
> Leif
> 
> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>> Leif,
>> 
>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as 
>> assuming the PDE debugging experience is awesome/exists on Linux and macOS 
>> is not a given. 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm  wrote:
>>> 
>>> Oops, sorry, missed this in search.
>>> 
>>> On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
 Andrew:
 
 I prefer to keep short CLANG9 as the tool chain name. I add wiki
 page
 https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
 to introduce it.
>>> 
>>> Why should users be expected to go and read documentation in order to
>>> learn that fundamental and incompatible changes to output and debug
>>> format has been made as part of what looks like a simple version bump?
>>> 
 And, we have CLANG38 tool chain. It generates ELF
 image and DWARF debug symbol format. It can work with LLVM 9.0
 release. Current tool chain tag name includes compiler name and
 version. There is no specific info in the tool chain name. The
 developer can get the more tool chain information from wiki page.
>>> 
>>> We aleady have the problem that people think they need to use GCC5 to
>>> build EDK2 since that is the highest named GCC toolchain profile.
>>> 
>>> Let's not make this situation *worse* by setting up a multidimensional
>>> feature matrix, based off random numerical values.
>>> 
>>> So say that we next have a pressing need to create a new toolchain
>>> profile for clang 10, using the old ELF mechanism. Are you then
>>> suggesting we set up a table on said wiki page where people have to go
>>> and look up what the object and debug formats are for each CLANG##
>>> toolchain profile?
>>> 
>>> And what if you then end up needing to do the same for the PDB
>>> flavour?
>>> 
 CLANG9 is designed to support Emulator for Windows host only.
>>> 
>>> Which is why it makes no sense to name it as a successor of
>>> CLANG38.
>>> 
 CLANG38 may be used for Emulator in Linux or Mac. I don’t
 try it before.
 
 CLANG9 goal is to align the same compiler in the different host
 development environment. It can replace VS or GCC compiler. On
 Windows Host, I verify VS debugger for the source level debug. On
 Linux host, I have not verified llvm debugger. I will investigate
 the debugger solution for OVMF in Linux host.
>>> 
>>> We are not asking you to throw out this toolchain profile.
>>> 
>>> We are saying that since the functionality it provides is completely
>>> unrelated to that of CLANG38, it should not be named in a way that
>>> suggests it is merely a revision update.
>>> 
>>> /
>>>   Leif
>>> 
 Thanks
 Liming
 From: af...@apple.com 
 Sent: Saturday, October 26, 2019 2:45 AM
 To: devel@edk2.groups.io; Gao, Liming 
 Cc: Ni, Ray ; Justen, Jordan L 
 
 Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool 
 chain
 
 Liming,
 
 Sorry I missed this mail. Thanks for the info! I was doing some research 
 into this too and now I think I finally understand. I think the name for 
 the tool chain really confused me and we should think about changing the 
 name.
 
 From what I understand CLANG9 means produce PE/COFF directly and used the 
 PDB debugging format. I see from the llvm site that the linker can produce 
 PDB directly as you mention. This all makes sense to me now as LLVM tries 
 to make it easy to be a drop in replacement for VC++ or GCC. So this tool 
 chain is designed to be able to cross build a "Windows App" on a Linux or 
 macOS. It also looks like the llvm debugger, lldb, is lagging in its 
 support for PDB based debugging.
 
 
 Anyway I think Leif and I agree the toolchain name is very confusing. I'd 
 rather see it called CLANG9_WIN or CLANG_PDB.
 
 
 On Oct 18, 2019, at 7:27 AM, Liming Gao 
 mailto:liming@intel.com>> wrote:
 
 Andrew:
 Here is the cover letter on CLANG9 introduction. 
 https://edk2.groups.io/g/devel/message/49157
 
 1)  Yes. CLANG9 tool chain is added to directly generate PE/COFF

Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

2019-11-07 Thread Kubacki, Michael A

Rebecca, that is correct. No future work is planned at this time.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> rebe...@bsdio.com
> Sent: Wednesday, November 6, 2019 3:04 PM
> To: devel@edk2.groups.io; Kubacki, Michael A
> ; Tiger Liu(BJ-RD) 
> Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code
> support
> 
> I was wondering if there were any plans to update the code for the UP
> Squared that's on the devel-IntelAtomProcessorE3900 branch of edk2-
> platforms?
> I guess with mention of support for the UP Xtreme, the UP Squared isn't
> going to have any more work done on it?
> 
> --
> Rebecca Cran
> 
> On 2019-11-05 19:11, Kubacki, Michael A wrote:
> > No other OCP support at the moment. Current board support is
> summarized in this Readme.md:
> > https://github.com/tianocore/edk2-
> platforms/blob/master/Readme.md#inte
> > l
> >
> > Newer Intel platform firmware is following the EDK II Minimum Platform
> > specification and the boards supported are documented here:
> > https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel
> > /Readme.md#supported-hardware
> >
> > KabylakeOpenBoardPkg supports two boards:
> >  * KabylakeRvp3 (an Intel Kaby Lake Y Reference and Validation
> > Platform)
> >  * GalagoPro3 (a commercial laptop with Kaby Lake from System 76)
> >
> > WhiskeylakeOpenBoardPkg currently supports:
> >  * WhiskeylakeURvp (an Intel Whiskey Lake U Reference and Validation
> > Platform)
> >
> > There is a plan to add board support for the UP Xtreme board in
> > WhiskeylakeOpenBoardPkg soon as noted here:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2191.
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50266): https://edk2.groups.io/g/devel/message/50266
Mute This Topic: https://groups.io/mt/42100924/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 22/22] Readme.md: Add CI build status badges



On Thu, Nov 07, 2019 at 07:42:27PM +, Kinney, Michael D wrote:
> Hi Leif,
> 
> I really like the build status information in Readme.md
> so it is visible whenever anyone navigates to the edk2
> repo.

As do I. Just not at any cost (including nullifying the entire point
of markdown).

> This matches what many other open source projects
> provide.
> 
> GitHub markdown does support HTML, so one idea is to 
> put this content into an HTML table and that would
> allow us to format the Readme.md file with each hyperlink
> on its own line.

I think that might work.

> If we remove the content from a markdown table, then there
> are some other pure markdown methods to put each hyperlink
> on its own line.
> 
> If we can get down to one hyperlink per line in Readme.md,
> does that address your concerns? 

My main problem is that the current version basically looks like a
transfer error. If we can make it look like a compartmentalised
section of the file that provides real value when viewed through
another tool, I'm quite OK with that.

Regards,

Leif

> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Thursday, November 7, 2019 8:00 AM
> > To: Kinney, Michael D 
> > Cc: devel@edk2.groups.io; Andrew Fish ;
> > Laszlo Ersek 
> > Subject: Re: [Patch v4 22/22] Readme.md: Add CI build
> > status badges
> > 
> > On Wed, Nov 06, 2019 at 05:13:49PM -0800, Michael D
> > Kinney wrote:
> > > Update Readme.md with status badges from the most
> > recent EDK II
> > > Continuous Integration(CI) build.
> > >
> > > Cc: Andrew Fish 
> > > Cc: Laszlo Ersek 
> > > Cc: Leif Lindholm 
> > > Signed-off-by: Michael D Kinney
> > 
> > > ---
> > >  Readme.md | 11 +++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/Readme.md b/Readme.md
> > > index 27e4ce0771..0207923763 100644
> > > --- a/Readme.md
> > > +++ b/Readme.md
> > > @@ -3,6 +3,17 @@
> > >  A modern, feature-rich, cross-platform firmware
> > development
> > > environment  for the UEFI and PI specifications from
> > www.uefi.org.
> > >
> > > +# Build Status
> > > +
> > > +| Host Type | Toolchain | Branch  | Build Status |
> > Test Status | Code
> > > +| Coverage |
> > > +| : | : | :-- | :--- | :-
> > - | : |
> > > +| Windows   | VS2019| master  | [![Build
> > Status](https://dev.azure.com/tianocore/edk2-ci-
> > play/_apis/build/status/edk2-
> > staging/Windows%20VS2019%20CI?branchName=master)](https:
> > //dev.azure.com/tianocore/edk2-ci-
> > play/_build/latest?definitionId=27=master) |
> > [![Azure DevOps tests](https://img.shields.io/azure-
> > devops/tests/tianocore/edk2-ci-
> > play/14.svg)](https://dev.azure.com/tianocore/edk2-ci-
> > play/_build/latest?definitionId=27=master) |
> > [![Code Coverage](https://img.shields.io/badge/coverage-
> > coming_soon-blue)](https://dev.azure.com/tianocore/edk2-
> > ci-play/_build/latest?definitionId=27=master)
> > |
> > > +| Ubuntu| GCC   | master  | [![Build
> > Status](https://dev.azure.com/tianocore/edk2-ci-
> > play/_apis/build/status/edk2-
> > staging/Ubuntu%20GCC5%20CI?branchName=master)](https://d
> > ev.azure.com/tianocore/edk2-ci-
> > play/_build/latest?definitionId=26=master)
> > | [![Azure DevOps tests](https://img.shields.io/azure-
> > devops/tests/tianocore/edk2-ci-
> > play/15.svg)](https://dev.azure.com/tianocore/edk2-ci-
> > play/_build/latest?definitionId=26=master) |
> > [![Code Coverage](https://img.shields.io/badge/coverage-
> > coming_soon-blue)](https://dev.azure.com/tianocore/edk2-
> > ci-play/_build/latest?definitionId=26=master)
> > |
> > 
> > I'm still not super happy about this.
> > If there is no hacky way of embedding this from another
> > file, could we consider breaking it out into a separate
> > BuildStatus.md and putting a link to that at the top of
> > this file?
> > 
> > /
> > Leif.
> > 
> > > +
> > > +[More CI Build information](.pytool/Readme.md)
> > > +
> > > +# License Details
> > > +
> > >  The majority of the content in the EDK II open source
> > project uses a
> > > [BSD-2-Clause Plus Patent License](License.txt).  The
> > EDK II open
> > > source project  contains the following components that
> > are covered by additional licenses:
> > > --
> > > 2.21.0.windows.1
> > >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50265): https://edk2.groups.io/g/devel/message/50265
Mute This Topic: https://groups.io/mt/44874114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

2019-11-07 Thread Oram, Isaac W

Tiger,

I believe that the solution used a silicon specific PciHostBridge driver 
provided by one of the binary FV providing silicon components (probably FILE = 
$(SILICON_BIN_PKG)/FvPostMemorySilicon/$(TARGET)/FvPostMemorySilicon.Fv).

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tiger Liu(BJ-RD)
Sent: Wednesday, November 6, 2019 9:45 PM
To: Kubacki, Michael A ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Hi, Michael:
I have a question about PCI host bridge driver in Olympus board.

I found PciHostBridge driver is deleted in CoreDxeInclude.dsc.
  #MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf

So, it seems BoardMtOlympus\PlatformPkg.dsc does not include any PciHostBridge 
driver implementation.

Thanks
-邮件原件-
发件人: Tiger Liu(BJ-RD)
发送时间: 2019年11月6日 15:48
收件人: 'Kubacki, Michael A' ; devel@edk2.groups.io
主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Got it.

Thank you very much.

Best wishes,
-邮件原件-
发件人: Kubacki, Michael A 
发送时间: 2019年11月6日 15:05
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code support

Unfortunately not. That's why we're trying to add support for these other 
commercially available systems such as the System 76 laptop and the UP Xtreme 
board.

The next product family that will likely get an open source board package added 
will be Comet Lake (client) as tracked here: 
https://bugzilla.tianocore.org/show_bug.cgi?id=2280

We very much would like to add back open source server platform code including 
support for a commercially available board and we're evaluating a few options 
but there's nothing definitive enough at the moment to give a target system or 
ETA.

Thanks,
Michael

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tiger
> Liu(BJ-RD)
> Sent: Tuesday, November 5, 2019 10:47 PM
> To: devel@edk2.groups.io; Kubacki, Michael A 
> 
> Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS 
> code support
>
> Hi, Michael:
> Got it.
> Thanks
>
> For "Reference and Validation Platform" motherboard, could user buy it 
> at open market?
> For example, buy it on Amazon.
>
> Thanks
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Kubacki, Michael A
> 发送时间: 2019年11月6日 10:12
> 收件人: Tiger Liu(BJ-RD) ; devel@edk2.groups.io
> 主题: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code 
> support
>
> No other OCP support at the moment. Current board support is 
> summarized in this Readme.md:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Readme.md#intel
>
> Newer Intel platform firmware is following the EDK II Minimum Platform 
> specification and the boards supported are documented here:
> https://github.com/tianocore/edk2-
> platforms/blob/master/Platform/Intel/Readme.md#supported-hardware
>
> KabylakeOpenBoardPkg supports two boards:
>  * KabylakeRvp3 (an Intel Kaby Lake Y Reference and Validation
> Platform)
>  * GalagoPro3 (a commercial laptop with Kaby Lake from System 76)
>
> WhiskeylakeOpenBoardPkg currently supports:
>  * WhiskeylakeURvp (an Intel Whiskey Lake U Reference and Validation
> Platform)
>
> There is a plan to add board support for the UP Xtreme board in 
> WhiskeylakeOpenBoardPkg soon as noted here:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2191.
>
> Thanks,
> Michael
>
> > -Original Message-
> > From: Tiger Liu(BJ-RD) 
> > Sent: Tuesday, November 5, 2019 5:32 PM
> > To: Kubacki, Michael A ; 
> > devel@edk2.groups.io
> > Subject: Re: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS 
> > code support
> >
> > Hi, Michael:
> > Thanks for your reply!
> >
> > Is there any other project For Intel open source platform firmware?
> >
> > KabylakeOpenBoardPkg / WhiskeylakeOpenBoardPkg is also for OCP 
> > platform board?
> >
> > Thanks
> > -邮件原件-
> > 发件人: Kubacki, Michael A 
> > 发送时间: 2019年11月6日 2:38
> > 收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
> > 主题: RE: [edk2-devel] [edk2] OCP : Olympus project's UEFI BIOS code 
> > support
> >
> > Hi,
> >
> > The PurleyOpenBoardPkg code is being removed as noted in the 
> > following patch series recently sent to the mailing list - 
> > https://edk2.groups.io/g/devel/message/49843.
> >
> > It has not been tested in some time and does not align with our 
> > vision for Intel open source platform firmware. The effort required 
> > to update the code and sustain testing alongside a large number of 
> > planned changes elsewhere that will impact PurleyOpenBoardPkg led to 
> > the decision to remove the package before the next stable tag.
> >
> > Prior to removal the code should compile by following the 
> > instructions
> here:
> > https://github.com/tianocore/edk2-
> > platforms/blob/master/Platform/Intel/Readme.md
> >
> > Thanks,
> > Michael
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of 
> > > Tiger
> > >

Re: [edk2-devel] [Patch v4 11/22] MdeModulePkg: Add YAML file for CI builds

Hao Wu,

I agree that this duplicate GUID exception can be removed.

I tried it out with a PR against edk2-staging/edk2-ci and 
it passed all checks.

https://github.com/tianocore/edk2-staging/pull/180

Mike

> -Original Message-
> From: Wu, Hao A 
> Sent: Wednesday, November 6, 2019 7:03 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Wang, Jian J 
> Subject: RE: [Patch v4 11/22] MdeModulePkg: Add YAML
> file for CI builds
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, November 07, 2019 9:14 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A
> > Subject: [Patch v4 11/22] MdeModulePkg: Add YAML file
> for CI builds
> >
> > Add YAML file to the package directory with the
> configuration of the
> > checks to perform during a CI build.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Signed-off-by: Michael D Kinney
> 
> > ---
> >  MdeModulePkg/MdeModulePkg.ci.yaml | 81
> > +++
> >  1 file changed, 81 insertions(+)
> >  create mode 100644 MdeModulePkg/MdeModulePkg.ci.yaml
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml
> > b/MdeModulePkg/MdeModulePkg.ci.yaml
> > new file mode 100644
> > index 00..6ae58d5379
> > --- /dev/null
> > +++ b/MdeModulePkg/MdeModulePkg.ci.yaml
> > @@ -0,0 +1,81 @@
> > +##
> > +# CI configuration for MdeModulePkg
> > +#
> > +# Copyright (c) Microsoft Corporation # SPDX-License-
> Identifier:
> > +BSD-2-Clause-Patent ## {
> > +## options defined ci/Plugin/CompilerPlugin
> > +"CompilerPlugin": {
> > +"DscPath": "MdeModulePkg.dsc"
> > +},
> > +
> > +## options defined ci/Plugin/CharEncodingCheck
> > +"CharEncodingCheck": {
> > +"IgnoreFiles": []
> > +},
> > +
> > +## options defined ci/Plugin/DependencyCheck
> > +"DependencyCheck": {
> > +"AcceptableDependencies": [
> > +"MdePkg/MdePkg.dec",
> > +"MdeModulePkg/MdeModulePkg.dec",
> > +"StandaloneMmPkg/StandaloneMmPkg.dec",
> > +"ArmPkg/ArmPkg.dec"  # this should be
> fixed by promoting
> > + an
> > abstraction
> > +],
> > +# For host based unit tests
> > +"AcceptableDependencies-HOST_APPLICATION":[],
> > +# For UEFI shell based apps
> > +"AcceptableDependencies-UEFI_APPLICATION":[],
> > +"IgnoreInf": []
> > +},
> > +
> > +## options defined ci/Plugin/DscCompleteCheck
> > +"DscCompleteCheck": {
> > +"IgnoreInf": [],
> > +"DscPath": "MdeModulePkg.dsc"
> > +},
> > +
> > +## options defined ci/Plugin/GuidCheck
> > +"GuidCheck": {
> > +"IgnoreGuidName": [],
> > +"IgnoreGuidValue": ["----
> "],
> > +"IgnoreFoldersAndFiles": [],
> > +"IgnoreDuplicates": [
> > +
> >
> "gEdkiiFormBrowserExProtocolGuid=gEfiFormBrowserExProtoc
> olGuid",
> > +
> "gEfiPeiMmAccessPpiGuid=gPeiSmmAccessPpiGuid",
> > +
> "gPeiSmmControlPpiGuid=gEfiPeiMmControlPpiGuid",
> > +"gEdkiiSerialPortLibVendorGuid=SerialDxe"
> # Is this a bug
> 
> 
> Hello Mike,
> 
> I think the above GUID duplication (serial-related) has
> already been addressed via commits:
> 
> SHA-1: 0d85e67714e31e0dbe4241ab2ebb7c423aba174d
> * MdeModulePkg/SerialDxe: Update the file Guid in
> SerialDxe.inf
> 
> SHA-1: 9790f62be1aa5ee9460d4c4ec8c720919523bb62
> * MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID format
> 
> Could you help to confirm whether the item can be
> removed?
> 
> With it handled,
> Reviewed-by: Hao A Wu 
> 
> Best Regards,
> Hao Wu
> 
> 
> > +]
> > +},
> > +
> > +## options defined ci/Plugin/LibraryClassCheck
> > +"LibraryClassCheck": {
> > +"IgnoreHeaderFile": []
> > +},
> > +
> > +## options defined ci/Plugin/SpellCheck
> > +"SpellCheck": {
> > +"AuditOnly": True,   # Fails test but
> run in AuditOnly mode to collect
> > log
> > +"IgnoreStandardPaths": [ # Standard
> Plugin defined paths that should
> > be ignore
> > +"*.c", "*.asm", "*.h", "*.nasm", "*.s",
> "*.asl", "*.inf"
> > +],
> > +"IgnoreFiles": [ # use gitignore
> syntax to ignore errors in matching
> > files
> > +
> "Library/LzmaCustomDecompressLib/Sdk/DOC/*"
> > +],
> > +"ExtendWords": [   # words to extend
> to the dictionary for this
> > package
> > +"LIGHTGRAY",
> > +"DARKGRAY",
> > +"LIGHTBLUE",
> > +"LIGHTGREEN",
> > +"LIGHTCYAN",
> > +"LIGHTRED",
> > +"LIGHTMAGENTA",
> > +"FVMAIN",
> > +"VARCHECKPCD",
> > +"Getxx",
> > +"lzturbo"
> > +],
> > +"AdditionalIncludePaths": [] # Additional
> paths to spell
> > + check relative to
> > package root (wildcards supported)
> > +}
> > +}
> > --
> > 2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all

Re: [edk2-devel] [Patch v4 22/22] Readme.md: Add CI build status badges

Hi Leif,

I really like the build status information in Readme.md
so it is visible whenever anyone navigates to the edk2
repo.  This matches what many other open source projects
provide.

GitHub markdown does support HTML, so one idea is to 
put this content into an HTML table and that would
allow us to format the Readme.md file with each hyperlink
on its own line.

If we remove the content from a markdown table, then there
are some other pure markdown methods to put each hyperlink
on its own line.

If we can get down to one hyperlink per line in Readme.md,
does that address your concerns? 

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm 
> Sent: Thursday, November 7, 2019 8:00 AM
> To: Kinney, Michael D 
> Cc: devel@edk2.groups.io; Andrew Fish ;
> Laszlo Ersek 
> Subject: Re: [Patch v4 22/22] Readme.md: Add CI build
> status badges
> 
> On Wed, Nov 06, 2019 at 05:13:49PM -0800, Michael D
> Kinney wrote:
> > Update Readme.md with status badges from the most
> recent EDK II
> > Continuous Integration(CI) build.
> >
> > Cc: Andrew Fish 
> > Cc: Laszlo Ersek 
> > Cc: Leif Lindholm 
> > Signed-off-by: Michael D Kinney
> 
> > ---
> >  Readme.md | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Readme.md b/Readme.md
> > index 27e4ce0771..0207923763 100644
> > --- a/Readme.md
> > +++ b/Readme.md
> > @@ -3,6 +3,17 @@
> >  A modern, feature-rich, cross-platform firmware
> development
> > environment  for the UEFI and PI specifications from
> www.uefi.org.
> >
> > +# Build Status
> > +
> > +| Host Type | Toolchain | Branch  | Build Status |
> Test Status | Code
> > +| Coverage |
> > +| : | : | :-- | :--- | :-
> - | : |
> > +| Windows   | VS2019| master  | [![Build
> Status](https://dev.azure.com/tianocore/edk2-ci-
> play/_apis/build/status/edk2-
> staging/Windows%20VS2019%20CI?branchName=master)](https:
> //dev.azure.com/tianocore/edk2-ci-
> play/_build/latest?definitionId=27=master) |
> [![Azure DevOps tests](https://img.shields.io/azure-
> devops/tests/tianocore/edk2-ci-
> play/14.svg)](https://dev.azure.com/tianocore/edk2-ci-
> play/_build/latest?definitionId=27=master) |
> [![Code Coverage](https://img.shields.io/badge/coverage-
> coming_soon-blue)](https://dev.azure.com/tianocore/edk2-
> ci-play/_build/latest?definitionId=27=master)
> |
> > +| Ubuntu| GCC   | master  | [![Build
> Status](https://dev.azure.com/tianocore/edk2-ci-
> play/_apis/build/status/edk2-
> staging/Ubuntu%20GCC5%20CI?branchName=master)](https://d
> ev.azure.com/tianocore/edk2-ci-
> play/_build/latest?definitionId=26=master)
> | [![Azure DevOps tests](https://img.shields.io/azure-
> devops/tests/tianocore/edk2-ci-
> play/15.svg)](https://dev.azure.com/tianocore/edk2-ci-
> play/_build/latest?definitionId=26=master) |
> [![Code Coverage](https://img.shields.io/badge/coverage-
> coming_soon-blue)](https://dev.azure.com/tianocore/edk2-
> ci-play/_build/latest?definitionId=26=master)
> |
> 
> I'm still not super happy about this.
> If there is no hacky way of embedding this from another
> file, could we consider breaking it out into a separate
> BuildStatus.md and putting a link to that at the top of
> this file?
> 
> /
> Leif.
> 
> > +
> > +[More CI Build information](.pytool/Readme.md)
> > +
> > +# License Details
> > +
> >  The majority of the content in the EDK II open source
> project uses a
> > [BSD-2-Clause Plus Patent License](License.txt).  The
> EDK II open
> > source project  contains the following components that
> are covered by additional licenses:
> > --
> > 2.21.0.windows.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50262): https://edk2.groups.io/g/devel/message/50262
Mute This Topic: https://groups.io/mt/44874114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II Maintainers please test the pull request commit gate

Hi Liming,

Yes.  I see that one as a personal build.

If you do another one and add the 'push' label, it 
should auto commit the change to SampleFile.txt.

Mike

> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, November 7, 2019 7:18 AM
> To: devel@edk2.groups.io; ler...@redhat.com; Kinney,
> Michael D 
> Subject: RE: [edk2-devel] EDK II Maintainers please test
> the pull request commit gate
> 
> I do my test on https://github.com/tianocore/edk2-
> staging/pull/60. But, I have not tested hub utility.
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io  On
> Behalf Of Laszlo
> > Ersek
> > Sent: Thursday, November 7, 2019 7:01 PM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > 
> > Subject: Re: [edk2-devel] EDK II Maintainers please
> test the pull
> > request commit gate
> >
> > On 11/07/19 03:24, Michael D Kinney wrote:
> > > EDK II Maintainers,
> > >
> > > Please take a few minutes to test the GitHub pull
> request commit
> > > gate feature under review in the edk2-staging/edk2-
> ci branch.  This
> > > will be the only method to push patches to the edk2
> repo in the near
> > > future, and we want all current EDK II Maintainers
> to make sure they
> > > know how to use this new process on the edk2-staging
> repo before it
> > > is activated on the
> > > edk2 repo.
> > >
> > > Please perform the following steps:
> > > * Create a personal fork of the edk2-staging repo.
> >
> > Slight but relevant clarification: please create a
> personal fork of
> > the edk2-staging repo *on GitHub.com*.
> >
> > > * Check out the edk2-ci branch from your personal
> > >   fork of the edk2-staging repo
> > > * Create a new branch based on the edk2-ci branch
> > > * Edit the file SampleFile.txt in the root of this
> > >   branch and add an Acked-by:  tag to
> > >   the end of this file.
> > > * Submit a pull request against the Tianocore
> > >   edk2-staging/edk2-ci.  Set the 'push' label so
> > >   the change to SampleFile.txt will be committed
> > >   if all checks pass.
> > >
> > >   NOTE: Make sure you select the 'edk2-ci' branch.
> > >   The default branch for the edk2-staging repo is
> > >   the 'about' branch and the pull request will not
> > >   work against the 'about' branch.
> > >
> > > * Verify that all checks pass and your change to
> > >   SampleFile.txt was merged into the
> > >   edk2-staging/edk2-ci branch.
> > >
> > > For those that prefer command line tools over a
> WebUI, the command
> > > line utility called 'hub' can be used to submit a
> pull request and
> > > check the status of a pull request.
> > >
> > > * https://github.com/github/hub
> > > * https://github.com/github/hub/releases
> > > * https://hub.github.com/hub.1.html
> >
> > I've gone through the above (except the personal
> Acked-by tag)
> > earlier,
> > successfully:
> >
> > https://github.com/tianocore/edk2-staging/pull/99
> >
> > Thanks!
> > Laszlo
> >
> >
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50261): https://edk2.groups.io/g/devel/message/50261
Mute This Topic: https://groups.io/mt/44980130/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg: Add YAML file for CI builds

2019-11-07 Thread Sean via Groups.Io

Laszlo,

Our legal team has requested that we don't include the copyright year. 

Thanks
Sean




-Original Message-
From: Kinney, Michael D  
Sent: Thursday, November 7, 2019 11:23 AM
To: devel@edk2.groups.io; ler...@redhat.com; Sean Brogan 

Cc: Dong, Eric ; Ni, Ray 
Subject: RE: [edk2-devel] [Patch v4 17/22] UefiCpuPkg: Add YAML file for CI 
builds

Hi Laszlo,

I will let Sean comment on the copyright line contents.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo 
> Ersek
> Sent: Thursday, November 7, 2019 2:48 AM
> To: Kinney, Michael D ; 
> devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray 
> Subject: Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg:
> Add YAML file for CI builds
> 
> On 11/07/19 11:42, Laszlo Ersek wrote:
> > On 11/07/19 02:13, Michael D Kinney wrote:
> >> Add YAML file to the package directory with the
> configuration of the
> >> checks to perform during a CI build.
> >>
> >> Cc: Eric Dong 
> >> Cc: Ray Ni 
> >> Cc: Laszlo Ersek 
> >> Signed-off-by: Michael D Kinney
> 
> >> Acked-by: Laszlo Ersek 
> >> ---
> >>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 51
> >> +++
> >>  1 file changed, 51 insertions(+)
> >>  create mode 100644 UefiCpuPkg/UefiCpuPkg.ci.yaml
> >>
> >> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml 
> >> b/UefiCpuPkg/UefiCpuPkg.ci.yaml new file mode 100644
> index
> >> 00..81da29b878
> >> --- /dev/null
> >> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> >> @@ -0,0 +1,51 @@
> >> +##
> >> +# CI configuration for UefiCpuPkg
> >> +#
> >> +# Copyright (c) Microsoft Corporation # SPDX-
> License-Identifier:
> >> +BSD-2-Clause-Patent ## {
> >> +"CompilerPlugin": {
> >> +"DscPath": "UefiCpuPkg.dsc"
> >> +},
> >> +"CharEncodingCheck": {
> >> +"IgnoreFiles": []
> >> +},
> >> +"DependencyCheck": {
> >> +"AcceptableDependencies": [
> >> +"MdePkg/MdePkg.dec",
> >> +"MdeModulePkg/MdeModulePkg.dec",
> >> +"UefiCpuPkg/UefiCpuPkg.dec"
> >> +],
> >> +# For host based unit tests
> >> +"AcceptableDependencies-
> HOST_APPLICATION":[],
> >> +# For UEFI shell based apps
> >> +"AcceptableDependencies-
> UEFI_APPLICATION":[],
> >> +"IgnoreInf": []
> >> +},
> >> +"DscCompleteCheck": {
> >> +"DscPath": "UefiCpuPkg.dsc",
> >> +"IgnoreInf": [
> >> +
> "UefiCpuPkg/ResetVector/FixupVtf/Vtf.inf",
> >> +"UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf"
> >> +]
> >> +},
> >> +"GuidCheck": {
> >> +"IgnoreGuidName": ["SecCore",
> "ResetVector"], # Expected duplication for 
> gEfiFirmwareVolumeTopFileGuid
> >> +"IgnoreGuidValue": [],
> >> +"IgnoreFoldersAndFiles": [],
> >> +"IgnoreDuplicates": []
> >> +},
> >> +"LibraryClassCheck": {
> >> +"IgnoreHeaderFile": []
> >> +},
> >> +
> >> +## options defined ci/Plugin/SpellCheck
> >> +"SpellCheck": {
> >> +"AuditOnly": True,   # Fails test
> but run in AuditOnly mode to collect log
> >> +"IgnoreFiles": [],   # use gitignore
> syntax to ignore errors in matching files
> >> +"ExtendWords": [],   # words to
> extend to the dictionary for this package
> >> +"IgnoreStandardPaths": [],   # Standard
> Plugin defined paths that should be ignore
> >> +"AdditionalIncludePaths": [] # Additional
> paths to spell check (wildcards supported)
> >> +}
> >> +}
> >>
> >
> > This is a very nice patch: good commit message (subjet
> and body both),
> > and good file comment.
> >
> > One suggestion: I'd recommend adding "@file" to the
> comment block at
> > the top.
> >
> > With that:
> >
> > Acked-by: Laszlo Ersek 
> >
> > (Of course, should "@file" confuse the YAML parser,
> then I won't
> > insist, and my ACK still applies.)
> 
> Ah, another remark: I believe the copyright notice should state a 
> year.
> (Most likely "2019".)
> 
> Thanks
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50260): https://edk2.groups.io/g/devel/message/50260
Mute This Topic: https://groups.io/mt/44874095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II CI Phase 1 Unit Test Cases

Hi Liming,

I have not done those cases.  I have cases that
modify existing files.  I want to make sure that these
test case are testing the Azure Pipelines, GitHub, and 
Mergify features.

Some of your suggestions are more about testing git
which seems out of scope.

I have submitted other PRs to edk2-ci that do 
add/remove/rename files without any issues.

However, a change to BaseTools is interesting, because
we would want to know that the modified version of
BaseTools is used to run the CI tests. I can add that
one.  Perhaps a change that generates extra log messages
so the extra log message can be found in the CI logs.

Mike

> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, November 7, 2019 7:15 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: RE: EDK II CI Phase 1 Unit Test Cases
> 
> Mike:
>   Is there the case to add new file or remove the
> existing file or rename the file name?
> 
>   And, is there the case to update BaseTools C or Python
> code?
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io  On
> Behalf Of Michael
> > D Kinney
> > Sent: Thursday, November 7, 2019 10:07 AM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > 
> > Subject: [edk2-devel] EDK II CI Phase 1 Unit Test
> Cases
> >
> > Hello,
> >
> > The following link performs a query on the pull
> requests in
> > edk2-staging/edk2-ci branch that shows the unit tests
> cases that have
> > been run.
> >
> > https://github.com/tianocore/edk2-
> staging/pulls?utf8=%E2%9C%93=is%3A
> > pr+0005h+in%3Atitle+OR+0005+in%3Atitle
> >
> > It includes unit tests from maintainers and non-
> maintainers for patch
> > series that pass and fail the enabled checks and
> include the use of
> > the 'push' label by maintainers.
> >
> > Please review these unit test cases and provide
> feedback if there are
> > unit test cases that should be added or if any of
> these do not have
> > the expected results.
> >
> > These unit tests were run against the same sources
> that are under
> > review in the V4 patch series here:
> >
> > https://github.com/tianocore/edk2-staging/tree/edk2-
> ci_V4
> >
> > https://edk2.groups.io/g/devel/message/50126
> >
> > Thanks,
> >
> > Mike
> >
> >
> >
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50259): https://edk2.groups.io/g/devel/message/50259
Mute This Topic: https://groups.io/mt/44951738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II Maintainers please test the pull request commit gate

Laszlo,

The hub command line utility also shows an option to
create a fork without using the GitHub UI.  But since I
already have all the relevant forks I needed, I have not
tried this feature yet.

These GitHub commands are provided by hub:

   apiLow-level GitHub API request interface
   browse Open a GitHub page in the default browser
   ci-status  Show the status of GitHub checks for a commit
   compareOpen a compare page on GitHub
   create Create this repository on GitHub and add GitHub as origin
   delete Delete a repository on GitHub
   fork   Make a fork of a remote repository on GitHub and add as remote
   issue  List or create GitHub issues
   pr List or checkout GitHub pull requests
   pull-request   Open a pull request on GitHub
   releaseList or create GitHub releases
   sync   Fetch git objects from upstream and update branches

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, November 7, 2019 3:01 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] EDK II Maintainers please test
> the pull request commit gate
> 
> On 11/07/19 03:24, Michael D Kinney wrote:
> > EDK II Maintainers,
> >
> > Please take a few minutes to test the GitHub pull
> request commit gate
> > feature under review in the edk2-staging/edk2-ci
> branch.  This will be
> > the only method to push patches to the edk2 repo in
> the near future,
> > and we want all current EDK II Maintainers to make
> sure they know how
> > to use this new process on the edk2-staging repo
> before it is
> > activated on the
> > edk2 repo.
> >
> > Please perform the following steps:
> > * Create a personal fork of the edk2-staging repo.
> 
> Slight but relevant clarification: please create a
> personal fork of the edk2-staging repo *on GitHub.com*.
> 
> > * Check out the edk2-ci branch from your personal
> >   fork of the edk2-staging repo
> > * Create a new branch based on the edk2-ci branch
> > * Edit the file SampleFile.txt in the root of this
> >   branch and add an Acked-by:  tag to
> >   the end of this file.
> > * Submit a pull request against the Tianocore
> >   edk2-staging/edk2-ci.  Set the 'push' label so
> >   the change to SampleFile.txt will be committed
> >   if all checks pass.
> >
> >   NOTE: Make sure you select the 'edk2-ci' branch.
> >   The default branch for the edk2-staging repo is
> >   the 'about' branch and the pull request will not
> >   work against the 'about' branch.
> >
> > * Verify that all checks pass and your change to
> >   SampleFile.txt was merged into the
> >   edk2-staging/edk2-ci branch.
> >
> > For those that prefer command line tools over a WebUI,
> the command
> > line utility called 'hub' can be used to submit a pull
> request and
> > check the status of a pull request.
> >
> > * https://github.com/github/hub
> > * https://github.com/github/hub/releases
> > * https://hub.github.com/hub.1.html
> 
> I've gone through the above (except the personal Acked-
> by tag) earlier,
> successfully:
> 
> https://github.com/tianocore/edk2-staging/pull/99
> 
> Thanks!
> Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50258): https://edk2.groups.io/g/devel/message/50258
Mute This Topic: https://groups.io/mt/44980130/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg: Add YAML file for CI builds

Hi Laszlo,

I will let Sean comment on the copyright line contents.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Laszlo Ersek
> Sent: Thursday, November 7, 2019 2:48 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray
> 
> Subject: Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg:
> Add YAML file for CI builds
> 
> On 11/07/19 11:42, Laszlo Ersek wrote:
> > On 11/07/19 02:13, Michael D Kinney wrote:
> >> Add YAML file to the package directory with the
> configuration of the
> >> checks to perform during a CI build.
> >>
> >> Cc: Eric Dong 
> >> Cc: Ray Ni 
> >> Cc: Laszlo Ersek 
> >> Signed-off-by: Michael D Kinney
> 
> >> Acked-by: Laszlo Ersek 
> >> ---
> >>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 51
> >> +++
> >>  1 file changed, 51 insertions(+)
> >>  create mode 100644 UefiCpuPkg/UefiCpuPkg.ci.yaml
> >>
> >> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml
> >> b/UefiCpuPkg/UefiCpuPkg.ci.yaml new file mode 100644
> index
> >> 00..81da29b878
> >> --- /dev/null
> >> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> >> @@ -0,0 +1,51 @@
> >> +##
> >> +# CI configuration for UefiCpuPkg
> >> +#
> >> +# Copyright (c) Microsoft Corporation # SPDX-
> License-Identifier:
> >> +BSD-2-Clause-Patent ## {
> >> +"CompilerPlugin": {
> >> +"DscPath": "UefiCpuPkg.dsc"
> >> +},
> >> +"CharEncodingCheck": {
> >> +"IgnoreFiles": []
> >> +},
> >> +"DependencyCheck": {
> >> +"AcceptableDependencies": [
> >> +"MdePkg/MdePkg.dec",
> >> +"MdeModulePkg/MdeModulePkg.dec",
> >> +"UefiCpuPkg/UefiCpuPkg.dec"
> >> +],
> >> +# For host based unit tests
> >> +"AcceptableDependencies-
> HOST_APPLICATION":[],
> >> +# For UEFI shell based apps
> >> +"AcceptableDependencies-
> UEFI_APPLICATION":[],
> >> +"IgnoreInf": []
> >> +},
> >> +"DscCompleteCheck": {
> >> +"DscPath": "UefiCpuPkg.dsc",
> >> +"IgnoreInf": [
> >> +
> "UefiCpuPkg/ResetVector/FixupVtf/Vtf.inf",
> >> +"UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf"
> >> +]
> >> +},
> >> +"GuidCheck": {
> >> +"IgnoreGuidName": ["SecCore",
> "ResetVector"], # Expected duplication for
> gEfiFirmwareVolumeTopFileGuid
> >> +"IgnoreGuidValue": [],
> >> +"IgnoreFoldersAndFiles": [],
> >> +"IgnoreDuplicates": []
> >> +},
> >> +"LibraryClassCheck": {
> >> +"IgnoreHeaderFile": []
> >> +},
> >> +
> >> +## options defined ci/Plugin/SpellCheck
> >> +"SpellCheck": {
> >> +"AuditOnly": True,   # Fails test
> but run in AuditOnly mode to collect log
> >> +"IgnoreFiles": [],   # use gitignore
> syntax to ignore errors in matching files
> >> +"ExtendWords": [],   # words to
> extend to the dictionary for this package
> >> +"IgnoreStandardPaths": [],   # Standard
> Plugin defined paths that should be ignore
> >> +"AdditionalIncludePaths": [] # Additional
> paths to spell check (wildcards supported)
> >> +}
> >> +}
> >>
> >
> > This is a very nice patch: good commit message (subjet
> and body both),
> > and good file comment.
> >
> > One suggestion: I'd recommend adding "@file" to the
> comment block at
> > the top.
> >
> > With that:
> >
> > Acked-by: Laszlo Ersek 
> >
> > (Of course, should "@file" confuse the YAML parser,
> then I won't
> > insist, and my ACK still applies.)
> 
> Ah, another remark: I believe the copyright notice
> should state a year.
> (Most likely "2019".)
> 
> Thanks
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50257): https://edk2.groups.io/g/devel/message/50257
Mute This Topic: https://groups.io/mt/44874095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Hi Andrew,

Yeah, I'm pretty easy with regards to what we change it to.
Although if we're bikeshedding, I would prefer not using _ in the
toolchain profile name.

I'm ... optimistic ... it won't break any of my existing scripts, but
since the build system uses it as a
__ separator, it would
be nice if we didn't risk confusion there.

(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
something along those lines.)

Regards,

Leif

On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> Leif,
> 
> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as 
> assuming the PDE debugging experience is awesome/exists on Linux and macOS is 
> not a given. 
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm  wrote:
> > 
> > Oops, sorry, missed this in search.
> > 
> > On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
> >> Andrew:
> >> 
> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> >>  page
> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
> >>  to introduce it.
> > 
> > Why should users be expected to go and read documentation in order to
> > learn that fundamental and incompatible changes to output and debug
> > format has been made as part of what looks like a simple version bump?
> > 
> >>  And, we have CLANG38 tool chain. It generates ELF
> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> >>  release. Current tool chain tag name includes compiler name and
> >>  version. There is no specific info in the tool chain name. The
> >>  developer can get the more tool chain information from wiki page.
> > 
> > We aleady have the problem that people think they need to use GCC5 to
> > build EDK2 since that is the highest named GCC toolchain profile.
> > 
> > Let's not make this situation *worse* by setting up a multidimensional
> > feature matrix, based off random numerical values.
> > 
> > So say that we next have a pressing need to create a new toolchain
> > profile for clang 10, using the old ELF mechanism. Are you then
> > suggesting we set up a table on said wiki page where people have to go
> > and look up what the object and debug formats are for each CLANG##
> > toolchain profile?
> > 
> > And what if you then end up needing to do the same for the PDB
> > flavour?
> > 
> >>  CLANG9 is designed to support Emulator for Windows host only.
> > 
> > Which is why it makes no sense to name it as a successor of
> > CLANG38.
> > 
> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> >>  try it before.
> >> 
> >>  CLANG9 goal is to align the same compiler in the different host
> >>  development environment. It can replace VS or GCC compiler. On
> >>  Windows Host, I verify VS debugger for the source level debug. On
> >>  Linux host, I have not verified llvm debugger. I will investigate
> >>  the debugger solution for OVMF in Linux host.
> > 
> > We are not asking you to throw out this toolchain profile.
> > 
> > We are saying that since the functionality it provides is completely
> > unrelated to that of CLANG38, it should not be named in a way that
> > suggests it is merely a revision update.
> > 
> > /
> >Leif
> > 
> >> Thanks
> >> Liming
> >> From: af...@apple.com 
> >> Sent: Saturday, October 26, 2019 2:45 AM
> >> To: devel@edk2.groups.io; Gao, Liming 
> >> Cc: Ni, Ray ; Justen, Jordan L 
> >> 
> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool 
> >> chain
> >> 
> >> Liming,
> >> 
> >> Sorry I missed this mail. Thanks for the info! I was doing some research 
> >> into this too and now I think I finally understand. I think the name for 
> >> the tool chain really confused me and we should think about changing the 
> >> name.
> >> 
> >> From what I understand CLANG9 means produce PE/COFF directly and used the 
> >> PDB debugging format. I see from the llvm site that the linker can produce 
> >> PDB directly as you mention. This all makes sense to me now as LLVM tries 
> >> to make it easy to be a drop in replacement for VC++ or GCC. So this tool 
> >> chain is designed to be able to cross build a "Windows App" on a Linux or 
> >> macOS. It also looks like the llvm debugger, lldb, is lagging in its 
> >> support for PDB based debugging.
> >> 
> >> 
> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd 
> >> rather see it called CLANG9_WIN or CLANG_PDB.
> >> 
> >> 
> >> On Oct 18, 2019, at 7:27 AM, Liming Gao 
> >> mailto:liming@intel.com>> wrote:
> >> 
> >> Andrew:
> >> Here is the cover letter on CLANG9 introduction. 
> >> https://edk2.groups.io/g/devel/message/49157
> >> 
> >> 1)  Yes. CLANG9 tool chain is added to directly generate PE/COFF image 
> >> (EFI image).
> >> This tool chain uses LLVM clang C compiler and lld linker, generates 
> >> PE/COFF
> >> image and PDB compatible debug symbol format. Now, it supports IA32/X64 
> >> Archs.
> >> LLVM clang C compiler and lld linker are

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RPi: Prevent buffer over-read when the command line is empty

On Thu, Nov 07, 2019 at 05:35:27PM +, Pete Batard wrote:
> On 2019.11.07 17:27, Leif Lindholm wrote:
> > On Thu, Nov 07, 2019 at 05:05:20PM +, Pete Batard wrote:
> > > Hi Leif,
> > > 
> > > On 2019.11.07 16:21, Leif Lindholm wrote:
> > > > Patch looks good, but the term "command line" is a bit confusing.
> > > > 
> > > > I assume we're talking about whatever way parameters are passed from
> > > > pre-edk2 firmware to edk2, right?
> > > 
> > > Yes. This is basically what the Raspberry Pi VideoCore bootcode digests 
> > > and
> > > passes as boot arguments to the ARM boot loader (i.e. our TF-A + EFI
> > > firmware executable). It contains options that the user may have set in
> > > their 'config.txt' as well as other data.
> > 
> > Sure.
> > 
> > > > Is there a more precise term for this?
> > > 
> > > Would "boot arguments" or "external boot arguments" work for you? Or if 
> > > you
> > > prefer "(external) boot parameters" should be applicable too.
> > 
> > Either would be fine - I was just hoping there might be a recognized
> > standard name for them :)
> 
> Well, as far as I know, the recognized standard name is "commandline" as per
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> 
> For instance there exists an option called disable_commandline_tags which
> pertains to what we are talking about.

Right. I meant something non-context-dependent. Nevermind :)

> > So, I could update the subject line to
> > Platform/RPi: Prevent external boot arguments over-read
> > in order to keep it short, and change "command line" in the commit
> > message body to "external boot arguments" - does that work for you?
> 
> If you can do that, that's great. Thanks!

Done. And with that:
Reviewed-by: Leif Lindholm 
Pushed as 92f06ccddfcf. 

Thanks!

/
Leif

> /Pete
> 
> > 
> > Regards,
> > 
> > Leif
> > 
> > > Regards,
> > > 
> > > /Pete
> > > 
> > > > 
> > > > /
> > > >   Leif
> > > > 
> > > > On Mon, Nov 04, 2019 at 04:06:17PM +, Pete Batard wrote:
> > > > > From: Andrei Warkentin 
> > > > > 
> > > > > It is possible for the command line to be empty
> > > > > (Cmd->TagHead.TagValueSize = 0), in which case the code should not
> > > > > attempt to read the value at CommandLine[-1].
> > > > > 
> > > > > Signed-off-by: Pete Batard 
> > > > > ---
> > > > >Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 3 
> > > > > ++-
> > > > >1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git 
> > > > > a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
> > > > > b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > > > index 5a9d4c3f1787..9b4aa068857c 100644
> > > > > --- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > > > +++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > > > @@ -927,7 +927,8 @@ RpiFirmwareGetCommmandLine (
> > > > >  CopyMem (CommandLine, Cmd->CommandLine, 
> > > > > Cmd->TagHead.TagValueSize);
> > > > > -  if (CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
> > > > > +  if (Cmd->TagHead.TagValueSize == 0 ||
> > > > > +  CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
> > > > >//
> > > > >// Add a NUL terminator if required.
> > > > >//
> > > > > -- 
> > > > > 2.21.0.windows.1
> > > > > 
> > > 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50255): https://edk2.groups.io/g/devel/message/50255
Mute This Topic: https://groups.io/mt/41265683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

2019-11-07 Thread Andrew Fish via Groups.Io

Leif,

I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as 
assuming the PDE debugging experience is awesome/exists on Linux and macOS is 
not a given. 

Thanks,

Andrew Fish

> On Nov 7, 2019, at 11:19 AM, Leif Lindholm  wrote:
> 
> Oops, sorry, missed this in search.
> 
> On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
>> Andrew:
>> 
>>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>  page
>>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
>>  to introduce it.
> 
> Why should users be expected to go and read documentation in order to
> learn that fundamental and incompatible changes to output and debug
> format has been made as part of what looks like a simple version bump?
> 
>>  And, we have CLANG38 tool chain. It generates ELF
>>  image and DWARF debug symbol format. It can work with LLVM 9.0
>>  release. Current tool chain tag name includes compiler name and
>>  version. There is no specific info in the tool chain name. The
>>  developer can get the more tool chain information from wiki page.
> 
> We aleady have the problem that people think they need to use GCC5 to
> build EDK2 since that is the highest named GCC toolchain profile.
> 
> Let's not make this situation *worse* by setting up a multidimensional
> feature matrix, based off random numerical values.
> 
> So say that we next have a pressing need to create a new toolchain
> profile for clang 10, using the old ELF mechanism. Are you then
> suggesting we set up a table on said wiki page where people have to go
> and look up what the object and debug formats are for each CLANG##
> toolchain profile?
> 
> And what if you then end up needing to do the same for the PDB
> flavour?
> 
>>  CLANG9 is designed to support Emulator for Windows host only.
> 
> Which is why it makes no sense to name it as a successor of
> CLANG38.
> 
>>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>  try it before.
>> 
>>  CLANG9 goal is to align the same compiler in the different host
>>  development environment. It can replace VS or GCC compiler. On
>>  Windows Host, I verify VS debugger for the source level debug. On
>>  Linux host, I have not verified llvm debugger. I will investigate
>>  the debugger solution for OVMF in Linux host.
> 
> We are not asking you to throw out this toolchain profile.
> 
> We are saying that since the functionality it provides is completely
> unrelated to that of CLANG38, it should not be named in a way that
> suggests it is merely a revision update.
> 
> /
>Leif
> 
>> Thanks
>> Liming
>> From: af...@apple.com 
>> Sent: Saturday, October 26, 2019 2:45 AM
>> To: devel@edk2.groups.io; Gao, Liming 
>> Cc: Ni, Ray ; Justen, Jordan L 
>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool 
>> chain
>> 
>> Liming,
>> 
>> Sorry I missed this mail. Thanks for the info! I was doing some research 
>> into this too and now I think I finally understand. I think the name for the 
>> tool chain really confused me and we should think about changing the name.
>> 
>> From what I understand CLANG9 means produce PE/COFF directly and used the 
>> PDB debugging format. I see from the llvm site that the linker can produce 
>> PDB directly as you mention. This all makes sense to me now as LLVM tries to 
>> make it easy to be a drop in replacement for VC++ or GCC. So this tool chain 
>> is designed to be able to cross build a "Windows App" on a Linux or macOS. 
>> It also looks like the llvm debugger, lldb, is lagging in its support for 
>> PDB based debugging.
>> 
>> 
>> Anyway I think Leif and I agree the toolchain name is very confusing. I'd 
>> rather see it called CLANG9_WIN or CLANG_PDB.
>> 
>> 
>> On Oct 18, 2019, at 7:27 AM, Liming Gao 
>> mailto:liming@intel.com>> wrote:
>> 
>> Andrew:
>> Here is the cover letter on CLANG9 introduction. 
>> https://edk2.groups.io/g/devel/message/49157
>> 
>> 1)  Yes. CLANG9 tool chain is added to directly generate PE/COFF image 
>> (EFI image).
>> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
>> image and PDB compatible debug symbol format. Now, it supports IA32/X64 
>> Archs.
>> LLVM clang C compiler and lld linker are the standalone tool set. They don’t 
>> depend other lib to generate PE/COFF image.
>> 
>> 2)  Yes. CLANG9 is the cross OS tool chain. It can work on 
>> Windows/Linux/Mac host OS.
>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 
>> in Windows/Linux host OS.
>> 
>> 
>> On Linux can you source level debug Ovmf?
>> 
>> 
>> 3) This patch enables WinHost in Windows. It doesn’t enable UnixHost. 
>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
>> This patch can make other modules pass build in Windows/Linux/Mac only if 
>> LLVM9 tool set is installed.
>> But, the generated image may not work on Linux/Mac. I agree below linker 
>> flags are specific to windows host.
>> So, I suggest to add the conditional

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

2019-11-07 Thread Jeff Brasen

Fixing UiApp seems reasonable, I do think we would want a hook to the platform 
library in here as the enumeration that occurs in the UiApp is intended to do a 
full enumeration of the system and there may be platform specifics to how that 
occurs.

Thanks,
Jeff


From: Ni, Ray 
Sent: Thursday, November 7, 2019 12:21 AM
To: devel@edk2.groups.io; Jeff Brasen ; af...@apple.com
Cc: Ashish Singhal ; Laszlo Ersek ; 
Wang, Jian J ; Wu, Hao A ; Gao, 
Zhichao ; Kinney, Michael D 
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

I treat the issue in this way:

  1.  Platform Boot Manager library does a good job. It doesn't always call 
RefreshAll() API to auto-create the boot options
  2.  But UiApp doesn't. It constantly call RefreshAll().

Do you think that we can fix UiApp instead? For example, introducing a PCD to 
control the boot option refresh behavior?

Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Thursday, November 7, 2019 3:02 PM
To: Ni, Ray mailto:ray...@intel.com>>; 
af...@apple.com
Cc: devel@edk2.groups.io; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

The issue is there are some auto created options we do not want on our platform.
Get Outlook for Android


From: Ni, Ray mailto:ray...@intel.com>>
Sent: Wednesday, November 6, 2019 11:59:31 PM
To: Jeff Brasen mailto:jbra...@nvidia.com>>; 
af...@apple.com 
mailto:af...@apple.com>>
Cc: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration


Jeff,

RefreshAllBootOption() only modifies/creates the auto-created boot options. For 
the boot options created by platform boot manager library, they stay with no 
one touches. And all auto-created boot options are appended in the end of boot 
option list (through BootOrder).



From: Jeff Brasen mailto:jbra...@nvidia.com>>
Sent: Thursday, November 7, 2019 12:13 PM
To: af...@apple.com; Ni, Ray 
mailto:ray...@intel.com>>
Cc: devel@edk2.groups.io; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



As the suggestions below made sense, we updated our platform boot manager 
library to behave in this manner and for normal boots everything works well. 
However the UiApp and boot maintenance applications in EDK2 also call 
EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu which 
will re-create the skipped boot options with no place for the platform code to 
intervene.



What about a solution where we add a new Platform library function that allows 
for override of the behavior of BmEnumerateBootOptions? For example, either a 
function or protocol that takes the same parameters as this function and only 
if it returns NULL then we continue to the default enumeration code.  Or a 
function call inserted at the end that would modify the load option array after 
the system does the standard enumeration.



-Jeff



From: af...@apple.com 
mailto:af...@apple.com>>
Sent: Wednesday, November 6, 2019 9:20 AM
To: Ni, Ray mailto:ray...@intel.com>>
Cc: devel@edk2.groups.io; Jeff Brasen 
mailto:jbra...@nvidia.com>>; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Mike Kinney 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Ray,



Is there an obvious hook point we could point Jeff and Ashish at?



Long term it would be a good idea to have a Wiki page to give some guidance on 
how to customize the BDS.



Thanks,



Andrew Fish



On Nov 5, 2019, at 9:20 PM, Ni, Ray mailto:ray...@intel.com>> 
wrote:



Andrew,

I agree with your opinion.

It's

Re: [edk2-devel] [Patch v4 03/22] requirements.txt: Add python pip requirements file

Hi Laszlo,

requirements.txt is not only for CI.

If a developer wants to run the same tests that CI runs
locally that also need to install using pip and need 
this file.

Sean responded to this feedback earlier and pointed to 
some features that may depend on this specific filename
or a specific filename pattern.

https://edk2.groups.io/g/devel/message/49620

I agree that the pip command supports using a different
filename.  I considered several options:

1) Keep current requirements.txt in root
2) Change to pip_requirements.txt in root
3) Change to requirements.txt in the .pytool directory

I set (3) aside because the use of the python extensions
installed using pip are not limited to content in the
.pytool directory.  There is new content in BaseTools as
well that depends on the pip install components.  The 
root directory is the only common parent directory.

Given the feedback that there may be some services that
look for requirements.txt, I thought it would be better
to leave the filename alone and add the file header
comment block with a clear description of the file.

With this additional context, if there is still feedback
that the filename must be changed, then I would recommend
a filename change that also follows camel case in the root.  

PipRequirements.txt

Best regards,

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, November 7, 2019 2:40 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Sean Brogan ; Andrew Fish
> ; Leif Lindholm
> 
> Subject: Re: [Patch v4 03/22] requirements.txt: Add
> python pip requirements file
> 
> On 11/07/19 02:13, Michael D Kinney wrote:
> > From: Sean Brogan 
> >
> > Add pip requirements file that is used to install the
> python pip
> > modules build from the edk2-pytool-library and edk2-
> pytool-extensions
> > repositories.
> >
> > These python modules provide the extensions required
> to perform EDK II
> > Continuous Integration(CI) builds.
> >
> > Cc: Andrew Fish 
> > Cc: Laszlo Ersek 
> > Cc: Leif Lindholm 
> > Signed-off-by: Michael D Kinney
> 
> > ---
> >  requirements.txt | 17 +
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 requirements.txt
> >
> > diff --git a/requirements.txt b/requirements.txt new
> file mode 100644
> > index 00..4ad72cfc98
> > --- /dev/null
> > +++ b/requirements.txt
> > @@ -0,0 +1,17 @@
> > +## @file
> > +# EDK II Python PIP requirements file # # This file
> provides the list
> > +of python components to install using PIP.
> > +#
> > +# Copyright (c) Microsoft Corporation. All rights
> reserved. # #
> > +SPDX-License-Identifier: BSD-2-Clause-Patent # #
> > +https://pypi.org/project/pip/ #
> >
> +https://pip.pypa.io/en/stable/user_guide/#requirements-
> files
> > +#
> >
> +https://pip.pypa.io/en/stable/reference/pip_install/#re
> quirements-fil
> > +e-format
> > +#
> > +##
> > +
> > +edk2-pytool-library==0.10.*
> > +edk2-pytool-extensions==0.12.*
> >
> 
> This is better, but I still find the plain
> "requirements.txt" filename in the root directory of the
> project very confusing. What component
> *exactly* insists on this file path and file name?
> 
> I've checked
> 
> 
> https://pip.pypa.io/en/stable/user_guide/#requirements-
> files
> 
> and it seems like "pip" can take any pathname as an
> argument to option "-r".
> 
> There must be a component in the CI environment that
> invokes "pip". Can we file a feature request for that
> component, that it try "pip-requirements.txt" first?
> 
> Hmmm... I just googled "github pip requirements.txt",
> assuming that "github" was the component calling "pip".
> In the result list, I've found:
> 
> https://github.com/ClearingHouse/clearinghoused/blob/mas
> ter/pip-requirements.txt
> 
> Is it possible that github already knows to look for
> "pip-requirements.txt"? (Honestly I only suggested "pip-
> requirements.txt" above because it seemed sensible.) If
> that's the case, we should use it.
> 
> 
> Furthermore, my understanding is that "the list of
> python components to install using PIP" is only there
> for CI purposes. Can we please state that explicitly in
> the comment block? (The commit message already does
> that, and that's great.)
> 
> Basically when someone clones edk2 and runs "ls -l" for
> the first time, there's a good chance "requirements.txt"
> will be among the few files they open right after.
> 
> Thanks!
> Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50252): https://edk2.groups.io/g/devel/message/50252
Mute This Topic: https://groups.io/mt/44874051/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TianoCore Community Meeting - EMEA/NAMO

2019-11-07 Thread Brian Richardson

Meeting Minutes 2019-11-07 TianoCore Community Meeting (EMEA/NAMO)

Community Manager
? Stephano Cetola has moved to a position with the Linux Foundation. 
Thanks to Stephano for all of his work supporting and growing the TianoCore 
community.
? Brian Richardson (Intel) is temporarily serving as community manager, 
covering public facing items (community meetings, events). Thanks to other 
community members for help covering bug triage and design meetings.
? There is a plan to bring on a new community manager in a few months.
? Brian will update calendar invites for future meetings.

FOSDEM - Feb 1-2, 2020 in Brussels.
? Large open source firmware conference in Europe (~8,000 attendees).
? First year there is a dedicated 'open source firmware' track room. 
Covers topics like EDK II, coreboot, LinuxBoot, u-boot, and OpenBMC.
? Track room runs on Saturday (Feb 1). Should be a dozen 20 minute 
presentation slots available.
? CFP for firmware room closes December 1st.
? https://lists.fosdem.org/pipermail/fosdem/2019q4/002933.html

UEFI SCT - UTWG is looking for contributors. Plans to integrate UEFI SCT into 
CI system, but not as many resources working on the project at this time.
? Discussion of plans to 'modernize' the UEFI SCT codebase? Discussion 
of test philosophy that generated duplicate protocols. Related to work in 
edk2-test/edk2-staging repo that should be evaluated for future updates.
? UEFI SCT CI integration would run in OVMF or EmulatorPkg on a cloud 
agent. Physical targets require a future version of the CI system.

TianoCore CI Process
? v4 patch series is under review. Maintainers will need to review 
before it is active on edk2 master.
? Uses pull request instead of direct push to trigger CI.
? Please use labeling properly (don't set 'push' label for personal 
build). Push label causes changes to be pushed if all tests pass.
? Tries to run all tests. Some tests (build) will halt at first 
failure, others will report all failures.
? CI tests can be run locally or in the cloud (Azure), but there is an 
issue with fragmenting checkers on local systems (different results from cloud 
vs local due to skipped tests). See updated documentation (repo readme in v4).
? Once CI is active and tested (1-2 weeks), write access on the CI 
repos will be restricted to admins.

Code First Process - under discussion in stewards' meeting
? Goal is a process to develop proposals for future UEFI spec 
improvements in open source prior to submission to the UEFI Forum.
? Repo for development - edk2-staging is preferred. Need to 
identify/filter 'code first' branches. 
? Naming convention will be important to distinguish pre-spec 
implementations.
? Next Steps: RFC for code first process (under development).

Opens?
? Plans to switch to Linux line endings? Previously discussed.
○ Still the plan. Won't make next stable tag, but should be 
considered for following stable tag (test for side-effects of conversion).
○ Aligns EDK II with other open source repos.
○ Risks of change - assumptions of line-ending style in build 
tools; custom tools by downstream consumers.
○ Contributors should raise issues early to avoid/correct 
issues.
○ A 'converted fork' can be used for community testing.

Thanks … br

-Original Appointment-
From: devel@edk2.groups.io Group  
Sent: None
To: devel@edk2.groups.io Group
Subject: TianoCore Community Meeting - EMEA/NAMO
When: Thursday, November 7, 2019 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US 
& Canada).
Where: https://bluejeans.com/889357567?src=join_info

Meeting URL
https://bluejeans.com/889357567?src=join_info

Meeting ID
889 357 567

Want to dial in from a phone?

Dial one of the following numbers:
+1.408.740.7256 (US (San Jose))
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50251): https://edk2.groups.io/g/devel/message/50251
Mute This Topic: https://groups.io/mt/46391326/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

[edk2-devel] [PATCH 1/1] Readme.md: remove positional references from submodule description

Remove references to the number of submodules in the tree, as well as
reword the referring to specific submodules as "former" and "previous".
This means we won't need to keep updating the surrounding text if we
add/remove submodules.

Cc: Andrew Fish 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
Reviewed-by: Laszlo Ersek 
---
 Readme.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Readme.md b/Readme.md
index 27e4ce07719b..9bf60bede8ec 100644
--- a/Readme.md
+++ b/Readme.md
@@ -144,12 +144,12 @@ Signed-off-by: Contributor Name 
 # Submodules
 
 Submodule in EDK II is allowed but submodule chain should be avoided
-as possible as we can. Currently EDK II contains two submodules
+as possible as we can. Currently EDK II contains the following submodules
 
 - CryptoPkg/Library/OpensslLib/openssl
 - ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
 
-The latter one is actually required by previous one. It's inevitable
+ArmSoftFloatLib is actually required by OpensslLib. It's inevitable
 in openssl-1.1.1 (since stable201905) for floating point parameter
 conversion, but should be dropped once there's no such need in future
 release of openssl.
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50250): https://edk2.groups.io/g/devel/message/50250
Mute This Topic: https://groups.io/mt/46388412/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RPi: Prevent buffer over-read when the command line is empty

2019-11-07 Thread Pete Batard


On 2019.11.07 17:27, Leif Lindholm wrote:

On Thu, Nov 07, 2019 at 05:05:20PM +, Pete Batard wrote:

Hi Leif,

On 2019.11.07 16:21, Leif Lindholm wrote:

Patch looks good, but the term "command line" is a bit confusing.

I assume we're talking about whatever way parameters are passed from
pre-edk2 firmware to edk2, right?


Yes. This is basically what the Raspberry Pi VideoCore bootcode digests and
passes as boot arguments to the ARM boot loader (i.e. our TF-A + EFI
firmware executable). It contains options that the user may have set in
their 'config.txt' as well as other data.


Sure.


Is there a more precise term for this?


Would "boot arguments" or "external boot arguments" work for you? Or if you
prefer "(external) boot parameters" should be applicable too.


Either would be fine - I was just hoping there might be a recognized
standard name for them :)


Well, as far as I know, the recognized standard name is "commandline" as 
per 
https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md


For instance there exists an option called disable_commandline_tags 
which pertains to what we are talking about.



So, I could update the subject line to
Platform/RPi: Prevent external boot arguments over-read
in order to keep it short, and change "command line" in the commit
message body to "external boot arguments" - does that work for you?


If you can do that, that's great. Thanks!

/Pete



Regards,

Leif


Regards,

/Pete



/
  Leif

On Mon, Nov 04, 2019 at 04:06:17PM +, Pete Batard wrote:

From: Andrei Warkentin 

It is possible for the command line to be empty
(Cmd->TagHead.TagValueSize = 0), in which case the code should not
attempt to read the value at CommandLine[-1].

Signed-off-by: Pete Batard 
---
   Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 5a9d4c3f1787..9b4aa068857c 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -927,7 +927,8 @@ RpiFirmwareGetCommmandLine (
 CopyMem (CommandLine, Cmd->CommandLine, Cmd->TagHead.TagValueSize);
-  if (CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
+  if (Cmd->TagHead.TagValueSize == 0 ||
+  CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
   //
   // Add a NUL terminator if required.
   //
--
2.21.0.windows.1






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50249): https://edk2.groups.io/g/devel/message/50249
Mute This Topic: https://groups.io/mt/41265683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RPi: Prevent buffer over-read when the command line is empty

On Thu, Nov 07, 2019 at 05:05:20PM +, Pete Batard wrote:
> Hi Leif,
> 
> On 2019.11.07 16:21, Leif Lindholm wrote:
> > Patch looks good, but the term "command line" is a bit confusing.
> > 
> > I assume we're talking about whatever way parameters are passed from
> > pre-edk2 firmware to edk2, right?
> 
> Yes. This is basically what the Raspberry Pi VideoCore bootcode digests and
> passes as boot arguments to the ARM boot loader (i.e. our TF-A + EFI
> firmware executable). It contains options that the user may have set in
> their 'config.txt' as well as other data.

Sure.

> > Is there a more precise term for this?
> 
> Would "boot arguments" or "external boot arguments" work for you? Or if you
> prefer "(external) boot parameters" should be applicable too.

Either would be fine - I was just hoping there might be a recognized
standard name for them :)

So, I could update the subject line to
Platform/RPi: Prevent external boot arguments over-read
in order to keep it short, and change "command line" in the commit
message body to "external boot arguments" - does that work for you?

Regards,

Leif

> Regards,
> 
> /Pete
> 
> > 
> > /
> >  Leif
> > 
> > On Mon, Nov 04, 2019 at 04:06:17PM +, Pete Batard wrote:
> > > From: Andrei Warkentin 
> > > 
> > > It is possible for the command line to be empty
> > > (Cmd->TagHead.TagValueSize = 0), in which case the code should not
> > > attempt to read the value at CommandLine[-1].
> > > 
> > > Signed-off-by: Pete Batard 
> > > ---
> > >   Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 3 ++-
> > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
> > > b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > index 5a9d4c3f1787..9b4aa068857c 100644
> > > --- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > +++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> > > @@ -927,7 +927,8 @@ RpiFirmwareGetCommmandLine (
> > > CopyMem (CommandLine, Cmd->CommandLine, Cmd->TagHead.TagValueSize);
> > > -  if (CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
> > > +  if (Cmd->TagHead.TagValueSize == 0 ||
> > > +  CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
> > >   //
> > >   // Add a NUL terminator if required.
> > >   //
> > > -- 
> > > 2.21.0.windows.1
> > > 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50248): https://edk2.groups.io/g/devel/message/50248
Mute This Topic: https://groups.io/mt/41265683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Oops, sorry, missed this in search.

On Wed, Oct 30, 2019 at 03:43:44PM +, Liming Gao wrote:
> Andrew:
> 
>   I prefer to keep short CLANG9 as the tool chain name. I add wiki
>   page
>   https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
>   to introduce it.

Why should users be expected to go and read documentation in order to
learn that fundamental and incompatible changes to output and debug
format has been made as part of what looks like a simple version bump?

>   And, we have CLANG38 tool chain. It generates ELF
>   image and DWARF debug symbol format. It can work with LLVM 9.0
>   release. Current tool chain tag name includes compiler name and
>   version. There is no specific info in the tool chain name. The
>   developer can get the more tool chain information from wiki page.

We aleady have the problem that people think they need to use GCC5 to
build EDK2 since that is the highest named GCC toolchain profile.

Let's not make this situation *worse* by setting up a multidimensional
feature matrix, based off random numerical values.

So say that we next have a pressing need to create a new toolchain
profile for clang 10, using the old ELF mechanism. Are you then
suggesting we set up a table on said wiki page where people have to go
and look up what the object and debug formats are for each CLANG##
toolchain profile?

And what if you then end up needing to do the same for the PDB
flavour?

>   CLANG9 is designed to support Emulator for Windows host only.

Which is why it makes no sense to name it as a successor of
CLANG38.

>   CLANG38 may be used for Emulator in Linux or Mac. I don’t
>   try it before.
> 
>   CLANG9 goal is to align the same compiler in the different host
>   development environment. It can replace VS or GCC compiler. On
>   Windows Host, I verify VS debugger for the source level debug. On
>   Linux host, I have not verified llvm debugger. I will investigate
>   the debugger solution for OVMF in Linux host.

We are not asking you to throw out this toolchain profile.

We are saying that since the functionality it provides is completely
unrelated to that of CLANG38, it should not be named in a way that
suggests it is merely a revision update.

/
Leif

> Thanks
> Liming
> From: af...@apple.com 
> Sent: Saturday, October 26, 2019 2:45 AM
> To: devel@edk2.groups.io; Gao, Liming 
> Cc: Ni, Ray ; Justen, Jordan L 
> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool 
> chain
> 
> Liming,
> 
> Sorry I missed this mail. Thanks for the info! I was doing some research into 
> this too and now I think I finally understand. I think the name for the tool 
> chain really confused me and we should think about changing the name.
> 
> From what I understand CLANG9 means produce PE/COFF directly and used the PDB 
> debugging format. I see from the llvm site that the linker can produce PDB 
> directly as you mention. This all makes sense to me now as LLVM tries to make 
> it easy to be a drop in replacement for VC++ or GCC. So this tool chain is 
> designed to be able to cross build a "Windows App" on a Linux or macOS. It 
> also looks like the llvm debugger, lldb, is lagging in its support for PDB 
> based debugging.
> 
> 
> Anyway I think Leif and I agree the toolchain name is very confusing. I'd 
> rather see it called CLANG9_WIN or CLANG_PDB.
> 
> 
> On Oct 18, 2019, at 7:27 AM, Liming Gao 
> mailto:liming@intel.com>> wrote:
> 
> Andrew:
>  Here is the cover letter on CLANG9 introduction. 
> https://edk2.groups.io/g/devel/message/49157
> 
> 1)  Yes. CLANG9 tool chain is added to directly generate PE/COFF image 
> (EFI image).
> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> LLVM clang C compiler and lld linker are the standalone tool set. They don’t 
> depend other lib to generate PE/COFF image.
> 
> 2)  Yes. CLANG9 is the cross OS tool chain. It can work on 
> Windows/Linux/Mac host OS.
> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in 
> Windows/Linux host OS.
> 
> 
> On Linux can you source level debug Ovmf?
> 
> 
> 3) This patch enables WinHost in Windows. It doesn’t enable UnixHost. 
> Now, EmulatorPkg with CLANG9 only works on Windows Host.
> This patch can make other modules pass build in Windows/Linux/Mac only if 
> LLVM9 tool set is installed.
> But, the generated image may not work on Linux/Mac. I agree below linker 
> flags are specific to windows host.
> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE 
> for them.
> 
> 
> For the EmulatorPkg the Host is a native App for that OS you build on, but it 
> seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you 
> might be able to override all the linker commands to build a native app, or 
> just use the system linker for the Host?
> 
> I'm not sure how well debugging will work mixing

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Hi Liming,

I don't feel we can release the stable tag with the toolchain
profile still holding this name. Do you have any comments?

Best Regards,

Leif

On Fri, Oct 25, 2019 at 11:45:10AM -0700, Andrew Fish via Groups.Io wrote:
> Liming,
> 
> Sorry I missed this mail. Thanks for the info! I was doing some
> research into this too and now I think I finally understand. I think
> the name for the tool chain really confused me and we should think
> about changing the name.
> 
> From what I understand CLANG9 means produce PE/COFF directly and
> used the PDB debugging format. I see from the llvm site that the
> linker can produce PDB directly as you mention. This all makes sense
> to me now as LLVM tries to make it easy to be a drop in replacement
> for VC++ or GCC. So this tool chain is designed to be able to cross
> build a "Windows App" on a Linux or macOS. It also looks like the
> llvm debugger, lldb, is lagging in its support for PDB based
> debugging.
> 
> Anyway I think Leif and I agree the toolchain name is very
> confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
> 
> > On Oct 18, 2019, at 7:27 AM, Liming Gao  wrote:
> > 
> > Andrew:
> >  Here is the cover letter on CLANG9 introduction. 
> > https://edk2.groups.io/g/devel/message/49157 
> > 
> >
> > 1)  Yes. CLANG9 tool chain is added to directly generate PE/COFF image 
> > (EFI image).
> > This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> > image and PDB compatible debug symbol format. Now, it supports IA32/X64 
> > Archs.
> > LLVM clang C compiler and lld linker are the standalone tool set. They 
> > don’t depend other lib to generate PE/COFF image.
> >
> > 2)  Yes. CLANG9 is the cross OS tool chain. It can work on 
> > Windows/Linux/Mac host OS.
> > LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 
> > in Windows/Linux host OS.
> >
> 
> On Linux can you source level debug Ovmf? 
> 
> > 3) This patch enables WinHost in Windows. It doesn’t enable UnixHost. 
> > Now, EmulatorPkg with CLANG9 only works on Windows Host.
> > This patch can make other modules pass build in Windows/Linux/Mac only if 
> > LLVM9 tool set is installed.
> > But, the generated image may not work on Linux/Mac. I agree below linker 
> > flags are specific to windows host.
> > So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE 
> > for them.
> >
> 
> For the EmulatorPkg the Host is a native App for that OS you build on, but it 
> seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you 
> might be able to override all the linker commands to build a native app, or 
> just use the system linker for the Host?
> 
> I'm not sure how well debugging will work mixing PDB and DWARF symbol 
> formats? 
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > !if $(WIN_HOST_BUILD) == TRUE
> >   GCC:*_CLANG9_*_DLINK_FLAGS = /ALIGN:4096 /FILEALIGN:4096 
> > /SUBSYSTEM:CONSOLE
> >   GCC:DEBUG_CLANG9_*_DLINK_FLAGS = 
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x1
> >   GCC:NOOPT_CLANG9_*_DLINK_FLAGS = 
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x1
> > !endif
> >
> > Thanks
> > Liming
> >  <>From: af...@apple.com  
> > Sent: Friday, October 18, 2019 1:15 AM
> > To: Ni, Ray 
> > Cc: Gao, Liming ; devel@edk2.groups.io; Justen, 
> > Jordan L 
> > Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >
> > Ray,
> >
> > Sorry I'm coming a little late to this and I'm confused. I have some 
> > questions?
> > 1) Does CLANG9 imply CLANGPE? 
> > 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style 
> > arguments to CLANGPE linker on Linux and macOS?
> > 3) For the EmulatorPkg don't you have the extra requirement that compiler 
> > needs a standard C lib (or platform specific libs) to function?
> >a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the 
> > Linux and macOS systems will have a Windows SKD dir and a lot of Windows 
> > DLLs? Does all that come when you install CLANG9 when you install it on 
> > Linux or macOS?
> > 
> > 
> > So I guess I'm asking is the linker really the same for CLANG9 on all 
> > systems? I guess the answer could be yes, but it seems the C lib for the 
> > Host App is still an App for that OS and is OS dependent? 
> > 
> > 
> > Sorry if I'm missing something fundamental and this is a dumb question. 
> > 
> > 
> > Thanks,
> > 
> > 
> > Andrew Fish
> > 
> >
> >
> > 
> > 
> > On Oct 17, 2019, at 12:27 AM, Ni, Ray  > > wrote:
> >
> > Liming,
> > Emulator is using a generic SEC module. The host specific module is called 
> > "Host".
> > So I prefer to change the macro to "WIN_HOST_BUILD", with this change, 
> > Reviewed-by: Ray Ni mailto:ray...@intel.com>>
> > 
> > 
> > -Original Message-
> > From: Gao, Liming mailto:liming@intel.com>>
> > Sent: Thursday, October 17, 2019 2:56 PM
> > To:

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RPi: Prevent buffer over-read when the command line is empty

2019-11-07 Thread Pete Batard


Hi Leif,

On 2019.11.07 16:21, Leif Lindholm wrote:

Patch looks good, but the term "command line" is a bit confusing.

I assume we're talking about whatever way parameters are passed from
pre-edk2 firmware to edk2, right?


Yes. This is basically what the Raspberry Pi VideoCore bootcode digests 
and passes as boot arguments to the ARM boot loader (i.e. our TF-A + EFI 
firmware executable). It contains options that the user may have set in 
their 'config.txt' as well as other data.



Is there a more precise term for this?


Would "boot arguments" or "external boot arguments" work for you? Or if 
you prefer "(external) boot parameters" should be applicable too.


Regards,

/Pete



/
 Leif

On Mon, Nov 04, 2019 at 04:06:17PM +, Pete Batard wrote:

From: Andrei Warkentin 

It is possible for the command line to be empty
(Cmd->TagHead.TagValueSize = 0), in which case the code should not
attempt to read the value at CommandLine[-1].

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 5a9d4c3f1787..9b4aa068857c 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -927,7 +927,8 @@ RpiFirmwareGetCommmandLine (
  
CopyMem (CommandLine, Cmd->CommandLine, Cmd->TagHead.TagValueSize);
  
-  if (CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {

+  if (Cmd->TagHead.TagValueSize == 0 ||
+  CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
  //
  // Add a NUL terminator if required.
  //
--
2.21.0.windows.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50245): https://edk2.groups.io/g/devel/message/50245
Mute This Topic: https://groups.io/mt/41265683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Upcoming Event: TianoCore Community Meeting - EMEA/NAMO - Thu, 11/07/2019 9:00am-10:00am #cal-reminder

2019-11-07 Thread devel@edk2.groups.io Calendar

*Reminder:* TianoCore Community Meeting - EMEA/NAMO

*When:* Thursday, 7 November 2019, 9:00am to 10:00am, (GMT-08:00) America/Los 
Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503253 )

*Organizer:* Stephano Cetola stephano.cet...@intel.com ( 
stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20EMEA%2FNAMO
 )

*Description:*

Meeting URL
https://bluejeans.com/889357567?src=join_info

Meeting ID
889 357 567

Want to dial in from a phone?

Dial one of the following numbers:
+1.408.740.7256 (US (San Jose))
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50244): https://edk2.groups.io/g/devel/message/50244
Mute This Topic: https://groups.io/mt/46307143/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RPi: Prevent buffer over-read when the command line is empty

Patch looks good, but the term "command line" is a bit confusing.

I assume we're talking about whatever way parameters are passed from
pre-edk2 firmware to edk2, right? Is there a more precise term for
this?

/
Leif

On Mon, Nov 04, 2019 at 04:06:17PM +, Pete Batard wrote:
> From: Andrei Warkentin 
> 
> It is possible for the command line to be empty
> (Cmd->TagHead.TagValueSize = 0), in which case the code should not
> attempt to read the value at CommandLine[-1].
> 
> Signed-off-by: Pete Batard 
> ---
>  Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
> b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> index 5a9d4c3f1787..9b4aa068857c 100644
> --- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> +++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
> @@ -927,7 +927,8 @@ RpiFirmwareGetCommmandLine (
>  
>CopyMem (CommandLine, Cmd->CommandLine, Cmd->TagHead.TagValueSize);
>  
> -  if (CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
> +  if (Cmd->TagHead.TagValueSize == 0 ||
> +  CommandLine[Cmd->TagHead.TagValueSize - 1] != '\0') {
>  //
>  // Add a NUL terminator if required.
>  //
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50243): https://edk2.groups.io/g/devel/message/50243
Mute This Topic: https://groups.io/mt/41265683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 19/22] .pytool: Add CISettings.py and Readme.md

2019-11-07 Thread rebecca


On 11/6/19 6:13 PM, Michael D Kinney wrote:


+# Copyright (c) 2018, Microsoft Corporation


Should probably be 2019.


+# 
###
 #
+# Extra CmdLine configuration  
   #
+# 
###
 #
+
+def AddCommandLineOptions(self, parserObj):
+pass


The comment blocks don't seem very Pythonic.


+## Background
+
+While a number of CI solutions exist, this proposal will focus on the usage of
+Azure Dev Ops and Build Pipelines. For demonstration, a sample
+[TianoCore repo](https://github.com/tianocore/edk2-staging.git) (branch master)
+and [Dev Ops 
Pipeline](https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=14)
+have been set up.


Since this is no longer a proposal, should we update this text?


+Inspection of these files reveals the EDKII Tools commands that make up the
+primary processes for the CI build: 'stuart_setup', 'stuart_update', and
+'stuart_ci_build'. These commands come from the EDKII Tools PIP modules and are
+configured as described below. More documentation on the stuart tools can be
+found 
[here](https://github.com/tianocore/edk2-pytool-extensions/blob/master/docs/using.md)
+and 
[here](https://github.com/tianocore/edk2-pytool-extensions/blob/master/docs/features/feature_invocables.md).


What's the relevance of "stuart"?


--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50242): https://edk2.groups.io/g/devel/message/50242
Mute This Topic: https://groups.io/mt/44874101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP instructions that are patched already

I *think* I understand what's going on (thank you for detailed commit
message and comment block). And that looks like a good workaround.

Thanks!
Reviewed-by: Leif Lindholm 


On Thu, Nov 07, 2019 at 10:09:27AM +0100, Ard Biesheuvel wrote:
> (+ Leif, Liming)
> 
> On Thu, 7 Nov 2019 at 10:06, Ard Biesheuvel  wrote:
> >
> > In order to permit the use of compilers that only implement the small
> > code model [which involves the use of ADRP instructions that require
> > 4 KB segment alignment] for generating PE/COFF binaries with a small
> > footprint, we patch ADRP instructions into ADR instructions while doing
> > the ELF to PE/COFF conversion.
> >
> > As it turns out, the linker may be doing the same, but for different
> > reasons: there is a silicon erratum #843419 for ARM Cortex-A53 which
> > affects ADRP instructions appearing at a certain offset in memory, and
> > one of the mitigations for this erratum is to patch them into ADR
> > instructions at link time if the symbol reference is within -/+ 1 MB.
> > However, the LD linker fails to update the static relocation tables, and
> > so we end up with an ADR instruction in the fully linked binary, but
> > with a relocation entry in the RELA section identifying it as an ADRP
> > instruction.
> >
> > Since the linker has already updated the symbol reference, there is no
> > handling needed in GenFw for such instructions, and we can simply treat
> > it as an ordinary ADR. However, since it is guaranteed to be accompanied
> > by an add or load instruction with a LO12 relocation referencing the same
> > symbol, the section offset check we apply to ADR instructions is going to
> > take place anyway, so we can just disregard the ADR instruction entirely.
> >
> > Reported-by: Eugene Cohen 
> > Suggested-by: Eugene Cohen 
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
> > b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > index d574300ac4fe..d623dce1f9da 100644
> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > @@ -1044,6 +1044,19 @@ WriteSections64 (
> >  /* fall through */
> >
> >case R_AARCH64_ADR_PREL_PG_HI21:
> > +//
> > +// In order to handle Cortex-A53 erratum #843419, the LD 
> > linker may
> > +// convert ADRP instructions into ADR instructions, but without
> > +// updating the static relocation type, and so we may end up 
> > here
> > +// while the instruction in question is actually ADR. So let's
> > +// just disregard it: the section offset check we apply below 
> > to
> > +// ADR instructions will trigger for its 
> > R_AARCH64_xxx_ABS_LO12_NC
> > +// companion instruction as well, so it is safe to omit it 
> > here.
> > +//
> > +if ((*(UINT32 *)Targ & BIT31) == 0) {
> > +  break;
> > +}
> > +
> >  //
> >  // AArch64 PG_H21 relocations are typically paired with 
> > ABS_LO12
> >  // relocations, where a PC-relative reference with +/- 4 GB 
> > range is
> > --
> > 2.17.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50241): https://edk2.groups.io/g/devel/message/50241
Mute This Topic: https://groups.io/mt/45528390/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 22/22] Readme.md: Add CI build status badges

On Wed, Nov 06, 2019 at 05:13:49PM -0800, Michael D Kinney wrote:
> Update Readme.md with status badges from the most recent
> EDK II Continuous Integration(CI) build.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  Readme.md | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Readme.md b/Readme.md
> index 27e4ce0771..0207923763 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -3,6 +3,17 @@
>  A modern, feature-rich, cross-platform firmware development environment
>  for the UEFI and PI specifications from www.uefi.org.
>  
> +# Build Status
> +
> +| Host Type | Toolchain | Branch  | Build Status | Test Status | Code 
> Coverage |
> +| : | : | :-- | :--- | :-- | 
> : |
> +| Windows   | VS2019| master  | [![Build 
> Status](https://dev.azure.com/tianocore/edk2-ci-play/_apis/build/status/edk2-staging/Windows%20VS2019%20CI?branchName=master)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  | [![Azure DevOps 
> tests](https://img.shields.io/azure-devops/tests/tianocore/edk2-ci-play/14.svg)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  | [![Code 
> Coverage](https://img.shields.io/badge/coverage-coming_soon-blue)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  |
> +| Ubuntu| GCC   | master  | [![Build 
> Status](https://dev.azure.com/tianocore/edk2-ci-play/_apis/build/status/edk2-staging/Ubuntu%20GCC5%20CI?branchName=master)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
> | [![Azure DevOps 
> tests](https://img.shields.io/azure-devops/tests/tianocore/edk2-ci-play/15.svg)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
>  | [![Code 
> Coverage](https://img.shields.io/badge/coverage-coming_soon-blue)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
>  |

I'm still not super happy about this.
If there is no hacky way of embedding this from another file, could we
consider breaking it out into a separate BuildStatus.md and putting a
link to that at the top of this file?

/
Leif.

> +
> +[More CI Build information](.pytool/Readme.md)
> +
> +# License Details
> +
>  The majority of the content in the EDK II open source project uses a
>  [BSD-2-Clause Plus Patent License](License.txt).  The EDK II open source 
> project
>  contains the following components that are covered by additional licenses:
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50240): https://edk2.groups.io/g/devel/message/50240
Mute This Topic: https://groups.io/mt/44874114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 03/22] requirements.txt: Add python pip requirements file

On Thu, Nov 07, 2019 at 11:39:37AM +0100, Laszlo Ersek wrote:
> > +## @file
> > +# EDK II Python PIP requirements file
> > +#
> > +# This file provides the list of python components to install using PIP.
> > +#
> > +# Copyright (c) Microsoft Corporation. All rights reserved.
> > +#
> > +# SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +# https://pypi.org/project/pip/
> > +# https://pip.pypa.io/en/stable/user_guide/#requirements-files
> > +# 
> > https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format
> > +#
> > +##
> > +
> > +edk2-pytool-library==0.10.*
> > +edk2-pytool-extensions==0.12.*
> > 
> 
> This is better, but I still find the plain "requirements.txt" filename
> in the root directory of the project very confusing. What component
> *exactly* insists on this file path and file name?
> 
> I've checked
> 
>   https://pip.pypa.io/en/stable/user_guide/#requirements-files
> 
> and it seems like "pip" can take any pathname as an argument to option "-r".
> 
> There must be a component in the CI environment that invokes "pip". Can
> we file a feature request for that component, that it try
> "pip-requirements.txt" first?
> 
> Hmmm... I just googled "github pip requirements.txt", assuming that
> "github" was the component calling "pip". In the result list, I've found:
> 
> https://github.com/ClearingHouse/clearinghoused/blob/master/pip-requirements.txt
> 
> Is it possible that github already knows to look for
> "pip-requirements.txt"? (Honestly I only suggested
> "pip-requirements.txt" above because it seemed sensible.) If that's the
> case, we should use it.

I agree it would be sensible to investigate this approach first.

> Furthermore, my understanding is that "the list of python components to
> install using PIP" is only there for CI purposes. Can we please state
> that explicitly in the comment block? (The commit message already does
> that, and that's great.)

Good point.

> Basically when someone clones edk2 and runs "ls -l" for the first time,
> there's a good chance "requirements.txt" will be among the few files
> they open right after.

Yeah. For a specific project to use that as a default config filename
is ... pretty arrogant.

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50239): https://edk2.groups.io/g/devel/message/50239
Mute This Topic: https://groups.io/mt/44874051/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Daniel P . Berrangé

On Thu, Nov 07, 2019 at 02:44:11PM +0100, Laszlo Ersek wrote:
> On 11/07/19 13:47, Paolo Bonzini wrote:
> > On 07/11/19 12:52, Daniel P. Berrangé wrote:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013
> >>
> >> Is it practical to provide a jitter entropy source for EDK2
> >> too ?
> > 
> > The hard part is not collecting jitter (though the firmware might be too
> > deterministic for that), but rather turning it into a random number seed
> > (mixing data from various sources, crediting entropy, etc.).
> 
> If there is *any* entropy source that (a) we can trust to be random
> enough and (b) depends only on the CPU, then we shouldn't struggle with
> virtio-rng (or similar devices) at all. RDRAND would be a no-brainer,
> but the "community literature" suggests it should not be trusted in itself.
> 
> I've read the commit message linked above, and it appears too good to be
> true.
> 
> The CPU Jitter RNG provides a source of good entropy by collecting
> CPU executing time jitter. [...] The RNG does not have any
> dependencies on any other service in the kernel. The RNG only needs
> a high-resolution time stamp. [...]
> 
> http://www.chronox.de/jent.html
> 
> The CPU Jitter Random Number Generator provides a non-physical true
> random number generator that works equally in kernel and user land.
> The only prerequisite is the availability of a high-resolution timer
> that is available in modern CPUs.
> 
> http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
> 
> Today’s operating systems provide non-physical true random number
> generators which are based on hardware events. With the advent of
> virtualization and the ever growing need of more high-quality random
> numbers, these random number generators reach their limits.
> Additional sources of entropy must be opened up. This document
> introduces an entropy source based on CPU execution time jitter. The
> design and implementation of a non-physical true random number
> generator, the CPU Jitter random number generator, its statistical
> properties and the maintenance and behavior of entropy is discussed
> in this document.
> 
> If this construct is legit, a core edk2 implementation (available to all
> platforms, and on all edk2 arches) would be a huge win.
> 
> On the other hand, we're having this discussion because the premise of
> TianoCore#1871 is that we shouldn't rely on just the CPU and a high
> resolution timer... I simply cannot decide if this construct is
> trustworthy. (With any solution that was based in the host's /dev/random
> or /dev/urandom, the trustworthiness question would be side-stepped in
> the firmware.)

I can't claim to have knowledge of whether the above text is accurate
or not, instead I just defer to the Linux maintainers recommendatiohns.
They've considered it acceptable to merge it into Linux, and to me that
says it should be acceptable to have in EDK2 too.

As a second data point, jitter entropy has been the recommended solution
in RHEL for VMs where there's no RDRAND or virtio-rng available. In RHEL-7
this was implemented in userspace in rng-tools rather than with the kernel
module I link above, but the approach is the same in both cases IIUC.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50237): https://edk2.groups.io/g/devel/message/50237
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II Maintainers please test the pull request commit gate

I do my test on https://github.com/tianocore/edk2-staging/pull/60. But, I have 
not tested hub utility. 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Thursday, November 7, 2019 7:01 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Subject: Re: [edk2-devel] EDK II Maintainers please test the pull request 
> commit gate
> 
> On 11/07/19 03:24, Michael D Kinney wrote:
> > EDK II Maintainers,
> >
> > Please take a few minutes to test the GitHub pull
> > request commit gate feature under review in the
> > edk2-staging/edk2-ci branch.  This will be the only
> > method to push patches to the edk2 repo in the near
> > future, and we want all current EDK II Maintainers to
> > make sure they know how to use this new process on
> > the edk2-staging repo before it is activated on the
> > edk2 repo.
> >
> > Please perform the following steps:
> > * Create a personal fork of the edk2-staging repo.
> 
> Slight but relevant clarification: please create a personal fork of the
> edk2-staging repo *on GitHub.com*.
> 
> > * Check out the edk2-ci branch from your personal
> >   fork of the edk2-staging repo
> > * Create a new branch based on the edk2-ci branch
> > * Edit the file SampleFile.txt in the root of this
> >   branch and add an Acked-by:  tag to
> >   the end of this file.
> > * Submit a pull request against the Tianocore
> >   edk2-staging/edk2-ci.  Set the 'push' label so
> >   the change to SampleFile.txt will be committed
> >   if all checks pass.
> >
> >   NOTE: Make sure you select the 'edk2-ci' branch.
> >   The default branch for the edk2-staging repo is
> >   the 'about' branch and the pull request will not
> >   work against the 'about' branch.
> >
> > * Verify that all checks pass and your change to
> >   SampleFile.txt was merged into the
> >   edk2-staging/edk2-ci branch.
> >
> > For those that prefer command line tools over a WebUI,
> > the command line utility called 'hub' can be used to
> > submit a pull request and check the status of a pull
> > request.
> >
> > * https://github.com/github/hub
> > * https://github.com/github/hub/releases
> > * https://hub.github.com/hub.1.html
> 
> I've gone through the above (except the personal Acked-by tag) earlier,
> successfully:
> 
> https://github.com/tianocore/edk2-staging/pull/99
> 
> Thanks!
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50236): https://edk2.groups.io/g/devel/message/50236
Mute This Topic: https://groups.io/mt/44980130/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

BaseTools can handle the space between them. 

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, November 7, 2019 11:12 PM
> To: Gao, Liming ; devel@edk2.groups.io; 
> tiger...@zhaoxin.com
> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
> 
> On 11/07/19 15:59, Gao, Liming wrote:
> > In FDF, you also need to specify this file guid and match the one in DSC. 
> > The syntax is like below:
> >
> > INF FILE_GUID= D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94 
> > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> 
> Thanks! (I assume there is no space character right after "FILE_GUID=".)
> 
> Cheers
> Laszlo
> 
> > Thanks
> > Liming
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> >> Sent: Thursday, November 7, 2019 6:56 PM
> >> To: devel@edk2.groups.io; tiger...@zhaoxin.com
> >> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
> >>
> >> On 11/07/19 05:51, Tiger Liu(BJ-RD) wrote:
> >>> Dear All:
> >>> I have a question about FILE_GUID override rule in dsc file.
> >>> For example:
> >>>   ..
> >>>   UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> >>> 
> >>>   FILE_GUID = D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
> >>> ..
> >>>   }
> >>>
> >>> Usually, will define FILE_GUID in PiSmmCpuDxeSmm.inf .
> >>>
> >>> Why override it in dsc file?
> >>
> >> IIRC, such overrides allow the platform DSC file to build the same
> >> module multiple times, most likely with other overrides too (such as PCD
> >> and lib class resolution). The resultant binaries will not conflict in
> >> any firmware volume / firmware file-system, by FILE_GUID.
> >>
> >> I don't remember the syntax, to be used in the FDF file, for refering to
> >> all of the builds of the same module INF file.
> >>
> >> Thanks
> >> Laszlo
> >>
> >>
> >> 
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50235): https://edk2.groups.io/g/devel/message/50235
Mute This Topic: https://groups.io/mt/45221205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II CI Phase 1 Unit Test Cases

Mike:
  Is there the case to add new file or remove the existing file or rename the 
file name?

  And, is there the case to update BaseTools C or Python code?

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D 
> Kinney
> Sent: Thursday, November 7, 2019 10:07 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Subject: [edk2-devel] EDK II CI Phase 1 Unit Test Cases
> 
> Hello,
> 
> The following link performs a query on the pull requests in
> edk2-staging/edk2-ci branch that shows the unit tests cases
> that have been run.
> 
> https://github.com/tianocore/edk2-staging/pulls?utf8=%E2%9C%93=is%3Apr+0005h+in%3Atitle+OR+0005+in%3Atitle
> 
> It includes unit tests from maintainers and non-maintainers
> for patch series that pass and fail the enabled checks and
> include the use of the 'push' label by maintainers.
> 
> Please review these unit test cases and provide feedback
> if there are unit test cases that should be added or if
> any of these do not have the expected results.
> 
> These unit tests were run against the same sources that are
> under review in the V4 patch series here:
> 
> https://github.com/tianocore/edk2-staging/tree/edk2-ci_V4
> 
> https://edk2.groups.io/g/devel/message/50126
> 
> Thanks,
> 
> Mike
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50234): https://edk2.groups.io/g/devel/message/50234
Mute This Topic: https://groups.io/mt/44951738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

On 11/07/19 15:59, Gao, Liming wrote:
> In FDF, you also need to specify this file guid and match the one in DSC. The 
> syntax is like below:
> 
> INF FILE_GUID= D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94 
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf

Thanks! (I assume there is no space character right after "FILE_GUID=".)

Cheers
Laszlo

> Thanks
> Liming
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Thursday, November 7, 2019 6:56 PM
>> To: devel@edk2.groups.io; tiger...@zhaoxin.com
>> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
>>
>> On 11/07/19 05:51, Tiger Liu(BJ-RD) wrote:
>>> Dear All:
>>> I have a question about FILE_GUID override rule in dsc file.
>>> For example:
>>>   ..
>>>   UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
>>> 
>>>   FILE_GUID = D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
>>> ..
>>>   }
>>>
>>> Usually, will define FILE_GUID in PiSmmCpuDxeSmm.inf .
>>>
>>> Why override it in dsc file?
>>
>> IIRC, such overrides allow the platform DSC file to build the same
>> module multiple times, most likely with other overrides too (such as PCD
>> and lib class resolution). The resultant binaries will not conflict in
>> any firmware volume / firmware file-system, by FILE_GUID.
>>
>> I don't remember the syntax, to be used in the FDF file, for refering to
>> all of the builds of the same module INF file.
>>
>> Thanks
>> Laszlo
>>
>>
>> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50233): https://edk2.groups.io/g/devel/message/50233
Mute This Topic: https://groups.io/mt/45221205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 14:58, Paolo Bonzini wrote:
> On 07/11/19 14:27, Laszlo Ersek wrote:
>> The VirtioRngDxe driver is a UEFI driver that follows the UEFI driver
>> model. Meaning (in this context), it is connected to the virtio-rng
>> device in the BDS phase, by platform BDS code.
>>
>> Put differently, the non-privileged driver that's the source of the
>> sensitive data would have to be a "platform DXE driver". The virtio
>> drivers are not such drivers however.
> 
> Yes, it would have to be a platform DXE driver.  What is it that limits
> virtio to the BDS phase?

For virtio-pci, we have:

- The PCI host bridge / root bridge driver, which is a platform DXE
driver, and produces PCI Root Bridge IO Protocol instances in its entry
point.

- The PCI bus driver, which is a UEFI driver that follows the UEFI
driver model. It only does its actual job when BDS connects it to the
PCI Root Bridge IO Protocol instances mentioned above. At that point,
the PCI bus driver produces a bunch of PCI IO protocol instances.

- The virtio 0.9.5 and virtio 1.0 PCI transport drivers. They are also
UEFI drivers that follow the UEFI driver model. They bind PCI IO
protocol instances when BDS says so, and produce VIRTIO_DEVICE_PROTOCOL
instances.

- The actual virtio device drivers (scsi, blk, net, rng, gpu) that bind
VIRTIO_DEVICE_PROTOCOL instances, when BDS says so, and produce the
use-case specific UEFI protocols (such as SCSI pass-thru, Block IO,
Simple Network, RNG, and Graphics Output).

For virtio-mmio, we have (on ARM only):

- a platform DXE driver that enumerates the virtio-mmio transports, in
its entry point function, based on the DTB that QEMU exposes. Each
register block / transport is turned into a VIRTIO_DEVICE_PROTOCOL
instances.

- The actual virtio device drivers (scsi, blk, net, rng, gpu) that bind
VIRTIO_DEVICE_PROTOCOL instances, when BDS says so, and produce the
use-case specific UEFI protocols (such as SCSI pass-thru, Block IO,
Simple Network, RNG, and Graphics Output).

UEFI drivers that follow the UEFI driver model allow BDS to orchestrate
device binding, and don't generally do anything unless called from BDS.

Platform DXE drivers do their job in their entry point functions. If
they have protocol dependencies, then they either spell that out as a
DEPEXes (dependency expressions, honored by the DXE Core during driver
dispatch), or else they operate with low-level protocol notification
callbacks (= they automatically take action, regardless of BDS, when a
particular protocol appears in the system). They produce their own
protocols in their entry point functions, or else in said protocol
notify callbacks, without being asked to by BDS.

UEFI-2.* strongly encourages device driver authors to structure their
drivers as such UEFI drivers that follow the UEFI driver model, and not
as platform DXE drivers.

A core idea in BDS is that the largest possible set of devices should
*not* be bound by drivers. If we don't connect anything that we don't
intend to boot off of (and don't need for other booting purposes [*],
then that makes for a speedy & frugal boot.

[*] such as console drivers (keyboard, serial, graphics), or RNG
drivers, ...

The set of devices connected by BDS is, by design, platform policy. When
the device drivers follow the UEFI driver model, platform BDS can manage
a large herd of 3rd party UEFI drivers, and only bind the set of devices
that's actually necessary.

When most device drivers are platform DXE drivers, all doing whatever
they want, and all acting on their own dependencies, it's very difficult
to express or implement a similar policy in a central component.

In OvmfPkg and ArmVirtPkg, we originally connected all drivers to all
devices. That was safe, but not too fast (especially when you had tens
or hundreds of virtio devices in the system). Nowadays, we connect only
what we really need for booting. That selection / binding procedure is
driven by the "bootorder" fw_cfg file from QEMU.

https://lists.01.org/hyperkitty/list/edk2-de...@lists.01.org/message/UAYFGPOQVI4FSHTU6MDLA6ULMUWSQ5HJ/

This selection is so effective that, when we first implemented it, we
actually stopped binding the virtio RNG device. (It was a regression --
I think the kernel's UEFI stub consumes it, if it's available, and we
noticed that the stub started complaining.) That happened because
virtio-rng is never a *bootable* device, and so it's never listed in the
"bootorder" fw_cfg file. Therefore we had to add custom BDS code to bind
virtio RNG devices "forcibly".

https://github.com/tianocore/edk2/commit/7ebad830d6ab6

Now, technically speaking, we could rewrite VirtioRngDxe to be a
platform DXE driver. It would register a protocol notify callback for
VIRTIO_DEVICE_PROTOCOL, it would investigate every such protocol
instance as they appeared in the protocol database, and bind whichever
was a virtio-rng device.

It wouldn't make a difference in the end, because the virtio PCI
transport drivers (producing

Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

In FDF, you also need to specify this file guid and match the one in DSC. The 
syntax is like below:

INF FILE_GUID= D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94 
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Thursday, November 7, 2019 6:56 PM
> To: devel@edk2.groups.io; tiger...@zhaoxin.com
> Subject: Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule
> 
> On 11/07/19 05:51, Tiger Liu(BJ-RD) wrote:
> > Dear All:
> > I have a question about FILE_GUID override rule in dsc file.
> > For example:
> >   ..
> >   UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> > 
> >   FILE_GUID = D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
> > ..
> >   }
> >
> > Usually, will define FILE_GUID in PiSmmCpuDxeSmm.inf .
> >
> > Why override it in dsc file?
> 
> IIRC, such overrides allow the platform DSC file to build the same
> module multiple times, most likely with other overrides too (such as PCD
> and lib class resolution). The resultant binaries will not conflict in
> any firmware volume / firmware file-system, by FILE_GUID.
> 
> I don't remember the syntax, to be used in the FDF file, for refering to
> all of the builds of the same module INF file.
> 
> Thanks
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50231): https://edk2.groups.io/g/devel/message/50231
Mute This Topic: https://groups.io/mt/45221205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Ard Biesheuvel

On Thu, 7 Nov 2019 at 14:44, Laszlo Ersek  wrote:
>
> On 11/07/19 13:47, Paolo Bonzini wrote:
> > On 07/11/19 12:52, Daniel P. Berrangé wrote:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013
> >>
> >> Is it practical to provide a jitter entropy source for EDK2
> >> too ?
> >
> > The hard part is not collecting jitter (though the firmware might be too
> > deterministic for that), but rather turning it into a random number seed
> > (mixing data from various sources, crediting entropy, etc.).
>
> If there is *any* entropy source that (a) we can trust to be random
> enough and (b) depends only on the CPU, then we shouldn't struggle with
> virtio-rng (or similar devices) at all. RDRAND would be a no-brainer,
> but the "community literature" suggests it should not be trusted in itself.
>
> I've read the commit message linked above, and it appears too good to be
> true.
>
> The CPU Jitter RNG provides a source of good entropy by collecting
> CPU executing time jitter. [...] The RNG does not have any
> dependencies on any other service in the kernel. The RNG only needs
> a high-resolution time stamp. [...]
>
> http://www.chronox.de/jent.html
>
> The CPU Jitter Random Number Generator provides a non-physical true
> random number generator that works equally in kernel and user land.
> The only prerequisite is the availability of a high-resolution timer
> that is available in modern CPUs.
>
> http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
>
> Today’s operating systems provide non-physical true random number
> generators which are based on hardware events. With the advent of
> virtualization and the ever growing need of more high-quality random
> numbers, these random number generators reach their limits.
> Additional sources of entropy must be opened up. This document
> introduces an entropy source based on CPU execution time jitter. The
> design and implementation of a non-physical true random number
> generator, the CPU Jitter random number generator, its statistical
> properties and the maintenance and behavior of entropy is discussed
> in this document.
>
> If this construct is legit, a core edk2 implementation (available to all
> platforms, and on all edk2 arches) would be a huge win.
>

 "that works equally in kernel and user land"

Firmware running at boot time on a single core without any serious
scheduling or I/O going on is not going to produce any entropy worth
mentioning, I'm afraid. And if it does, it is going to delay the boot
substantially.

> On the other hand, we're having this discussion because the premise of
> TianoCore#1871 is that we shouldn't rely on just the CPU and a high
> resolution timer... I simply cannot decide if this construct is
> trustworthy. (With any solution that was based in the host's /dev/random
> or /dev/urandom, the trustworthiness question would be side-stepped in
> the firmware.)
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50230): https://edk2.groups.io/g/devel/message/50230
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 07/11/19 14:27, Laszlo Ersek wrote:
> The VirtioRngDxe driver is a UEFI driver that follows the UEFI driver
> model. Meaning (in this context), it is connected to the virtio-rng
> device in the BDS phase, by platform BDS code.
> 
> Put differently, the non-privileged driver that's the source of the
> sensitive data would have to be a "platform DXE driver". The virtio
> drivers are not such drivers however.

Yes, it would have to be a platform DXE driver.  What is it that limits
virtio to the BDS phase?

Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50229): https://edk2.groups.io/g/devel/message/50229
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 13:47, Paolo Bonzini wrote:
> On 07/11/19 12:52, Daniel P. Berrangé wrote:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013
>>
>> Is it practical to provide a jitter entropy source for EDK2
>> too ?
> 
> The hard part is not collecting jitter (though the firmware might be too
> deterministic for that), but rather turning it into a random number seed
> (mixing data from various sources, crediting entropy, etc.).

If there is *any* entropy source that (a) we can trust to be random
enough and (b) depends only on the CPU, then we shouldn't struggle with
virtio-rng (or similar devices) at all. RDRAND would be a no-brainer,
but the "community literature" suggests it should not be trusted in itself.

I've read the commit message linked above, and it appears too good to be
true.

The CPU Jitter RNG provides a source of good entropy by collecting
CPU executing time jitter. [...] The RNG does not have any
dependencies on any other service in the kernel. The RNG only needs
a high-resolution time stamp. [...]

http://www.chronox.de/jent.html

The CPU Jitter Random Number Generator provides a non-physical true
random number generator that works equally in kernel and user land.
The only prerequisite is the availability of a high-resolution timer
that is available in modern CPUs.

http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html

Today’s operating systems provide non-physical true random number
generators which are based on hardware events. With the advent of
virtualization and the ever growing need of more high-quality random
numbers, these random number generators reach their limits.
Additional sources of entropy must be opened up. This document
introduces an entropy source based on CPU execution time jitter. The
design and implementation of a non-physical true random number
generator, the CPU Jitter random number generator, its statistical
properties and the maintenance and behavior of entropy is discussed
in this document.

If this construct is legit, a core edk2 implementation (available to all
platforms, and on all edk2 arches) would be a huge win.

On the other hand, we're having this discussion because the premise of
TianoCore#1871 is that we shouldn't rely on just the CPU and a high
resolution timer... I simply cannot decide if this construct is
trustworthy. (With any solution that was based in the host's /dev/random
or /dev/urandom, the trustworthiness question would be side-stepped in
the firmware.)

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50228): https://edk2.groups.io/g/devel/message/50228
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 0/6] Add Device Security driver

I forget to mention that this patch is also pushed to git:

The EDKII repo update is at 
https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV3
The EDKII platform repo update is at 
https://github.com/jyao1/edk2-platforms/tree/DeviceSecurityMasterV3

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Thursday, November 7, 2019 9:38 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH V3 0/6] Add Device Security driver
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> === V3 ===
> 
> The V3 version addresses the feedback below:
> 
> Liming Gao:
> 1. Add SPDM spec version and align to latest one 0.99a.
> 
> Rangasai Chaganty:
> 1. put a reference to the spec at the file header, for Intel PCI security 
> spec.
> 2. add some high level description above the structure definition that
>describes the structure.
> 3. on the services "GetDevicePolicy" and "SetDeviceState", Add more error
>return states
> 
> Ray Ni:
> 1. add comments to each field of structures like
> EDKII_DEVICE_SECURITY_POLICY
>and EDKII_DEVICE_SECURITY_STATE.
> 2. add comments to all the macros defined in this patch to explain the meaning
>and more important how they are going to impact the logic.
> 3. make the macro short
> EDKII_DEVICE_MEASUREMENT_POLICY_REQUIRED ->
> EDKII_DEVICE_MEASUREMENT_REQUIRED
> EDKII_DEVICE_AUTHENTICATION_POLICY_REQUIRED ->
> EDKII_DEVICE_AUTHENTICATION_REQUIRED
> 4. rename the SetDeviceState to NotifyDeviceState.
> 5. add comments to explain clearly what SetDeviceState() needs to do.
> 6. change the prototype so that caller needs to pass in a policy structure and
>GetDevicePolicy() fills the structure buffer using CopyMem.
> 7. add the version macro for
> EDKII_DEVICE_SECURITY_POLICY_PROTOCOL.Version,
>securitypolicy.version and securitystate.version.
> 8. add clear debug information for DvSec capability header.
> 
> === V2 ===
> 
> This patch series add support for device security based
> upon the DMTF SPDM specification.
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a
> .zip
> 
> We did design review at 18 Oct, 2019.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018
> And the feedback from the meeting is addressed.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-
> Device%20Firmware%20Security%20v2.pdf
> 
> The Device security protocol is added in EDKII repo.
> Here we add the producer what follows Intel PCI security spec
> to do the device firmware measurement.
> https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> security-enhancements-spec.html
> 
> The EDKII repo update is at
> https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
> The EDKII platform repo update is at https://github.com/jyao1/edk2-
> platforms/tree/DeviceSecurityMasterV2
> 
> The validation has been done on a Intel internal platform.
> The device measurement can be shown in TCG event log.
> 
> signed-off-by: Jiewen Yao 
> 
> Jiewen Yao (6):
>   IntelSiliconPkg/Include: Add Intel PciSecurity definition.
>   IntelSiliconPkg/Include: Add Platform Device Security Policy protocol
>   IntelSiliconPkg/dec: Add ProtocolGuid definition.
>   IntelSiliconPkg/IntelPciDeviceSecurityDxe: Add PciSecurity.
>   IntelSiliconPkg/SamplePlatformDevicePolicyDxe: Add sample policy.
>   IntelSiliconPkg/dsc: Add Device Security component.
> 
>  .../IntelPciDeviceSecurityDxe.c   | 697 ++
>  .../IntelPciDeviceSecurityDxe.inf |  45 ++
>  .../TcgDeviceEvent.h  | 178 +
>  .../SamplePlatformDevicePolicyDxe.c   | 204 +
>  .../SamplePlatformDevicePolicyDxe.inf |  40 +
>  .../IndustryStandard/IntelPciSecurity.h   |  92 +++
>  .../Protocol/PlatformDeviceSecurityPolicy.h   | 128 
>  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dec |   4 +
>  .../Intel/IntelSiliconPkg/IntelSiliconPkg.dsc |   3 +
>  9 files changed, 1391 insertions(+)
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> elPciDeviceSecurityDxe.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Int
> elPciDeviceSecurityDxe.inf
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/Tcg
> DeviceEvent.h
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyD
> xe/SamplePlatformDevicePolicyDxe.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyD
> xe/SamplePlatformDevicePolicyDxe.inf
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolicy.h
> 
> --
> 2.19.2.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You

Re: [edk2-devel] [PATCH V3 0/4] Add SPDM device security

Hi
I forget to mention that this patch is also pushed to git.

The EDKII repo update is at 
https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV3
The EDKII platform repo update is at 
https://github.com/jyao1/edk2-platforms/tree/DeviceSecurityMasterV3

Thank you
Yao Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Thursday, November 7, 2019 9:38 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH V3 0/4] Add SPDM device security
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
> 
> = v3 =
> 
> The patch addresses the feedback below:
> Liming Gao:
> 1) specify the spec version in file header for SPDM.
> 
> Ray Ni:
> 1) create a standalone function like PciDeviceAuthenticate() and
> move the new code to that function then call it from CreatePciIoDevice
> 
> = v2 =
> This patch series add support for device security based
> upon the DMTF SPDM specification.
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a
> .zip
> 
> We did design review at 18 Oct, 2019.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018
> And the feedback from the meeting is addressed.
> https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-
> Device%20Firmware%20Security%20v2.pdf
> 
> We add the Device security protocol in EDKII repo.
> PCI bus driver consumes the interface.
> If there is no producer, the PCI bus driver keeps current behavior.
> 
> So far, we only provide the producer what follows Intel
> PCI security spec.
> https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-
> security-enhancements-spec.html
> The implementation is put to EDKII platform repo.
> 
> The EDKII repo update is at
> https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
> The EDKII platform repo update is at https://github.com/jyao1/edk2-
> platforms/tree/DeviceSecurityMasterV2
> 
> The validation has been done on a Intel internal platform.
> The device measurement can be shown in TCG event log.
> 
> signed-off-by: Jiewen Yao 
> 
> Jiewen Yao (4):
>   MdePkg/Include: Add DMTF SPDM definition.
>   MdeModulePkg/Include: Add DeviceSecurity.h
>   MdeModulePkg/dec: Add EdkiiDeviceSecurityProtocolGuid.
>   MdeModulePkg/Pci: Add DeviceSecurity support.
> 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c   |  12 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |   1 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |   4 +-
>  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |  77 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |   4 +-
>  .../Include/Protocol/DeviceSecurity.h | 162 +
>  MdeModulePkg/MdeModulePkg.dec |   5 +
>  MdePkg/Include/IndustryStandard/Spdm.h| 320 ++
>  8 files changed, 581 insertions(+), 4 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Protocol/DeviceSecurity.h
>  create mode 100644 MdePkg/Include/IndustryStandard/Spdm.h
> 
> --
> 2.19.2.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50226): https://edk2.groups.io/g/devel/message/50226
Mute This Topic: https://groups.io/mt/46026514/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 5/6] IntelSiliconPkg/SamplePlatformDevicePolicyDxe: Add sample policy.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

This driver provides the platform sample policy to measure
a NVMe card.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 .../SamplePlatformDevicePolicyDxe.c   | 204 ++
 .../SamplePlatformDevicePolicyDxe.inf |  40 
 2 files changed, 244 insertions(+)
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.inf

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.c
 
b/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.c
new file mode 100644
index 00..5b0897d6af
--- /dev/null
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.c
@@ -0,0 +1,204 @@
+/** @file
+  EDKII Device Security library for PCI device
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EDKII_DEVICE_SECURITY_POLICY   mDeviceSecurityPolicyNone = {
+  EDKII_DEVICE_SECURITY_POLICY_REVISION,
+  0,
+  0,
+};
+EDKII_DEVICE_SECURITY_POLICY   mDeviceSecurityPolicyMeasurement = {
+  EDKII_DEVICE_SECURITY_POLICY_REVISION,
+  EDKII_DEVICE_MEASUREMENT_REQUIRED,
+  0,
+};
+
+/**
+  This function returns the device security policy associated with the device.
+
+  The device security driver may call this interface to get the platform policy
+  for the specific device and determine if the measurement or authentication
+  is required.
+
+  @param[in]  This   The protocol instance pointer.
+  @param[in]  DeviceId   The Identifier for the device.
+  @param[out] DeviceSecurityPolicy   The Device Security Policy associated 
with the device.
+
+  @retval EFI_SUCCESSThe device security policy is returned
+  @retval EFI_UNSUPPORTEDThe function is unsupported for the 
specific Device.
+**/
+EFI_STATUS
+EFIAPI
+GetDevicePolicy (
+  IN  EDKII_DEVICE_SECURITY_POLICY_PROTOCOL  *This,
+  IN  EDKII_DEVICE_IDENTIFIER*DeviceId,
+  OUT EDKII_DEVICE_SECURITY_POLICY   *DeviceSecurityPolicy
+  )
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT16  PciVendorId;
+  UINT16  PciDeviceId;
+
+  CopyMem (DeviceSecurityPolicy, , 
sizeof(EDKII_DEVICE_SECURITY_POLICY));
+
+  DEBUG ((DEBUG_INFO, "GetDevicePolicy - 0x%g\n", >DeviceType));
+
+  if (!CompareGuid (>DeviceType, 
)) {
+return EFI_SUCCESS;
+  }
+
+  Status = gBS->HandleProtocol (
+  DeviceId->DeviceHandle,
+  ,
+  (VOID **)
+  );
+  if (EFI_ERROR(Status)) {
+DEBUG ((DEBUG_ERROR, "Locate - DeviceIdentifierTypePci - %r\n", Status));
+return EFI_SUCCESS;
+  }
+
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET, 
1, );
+  ASSERT_EFI_ERROR(Status);
+  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_DEVICE_ID_OFFSET, 
1, );
+  ASSERT_EFI_ERROR(Status);
+  DEBUG ((DEBUG_INFO, "PCI Info - %04x:%04x\n", PciVendorId, PciDeviceId));
+
+  if ((PciVendorId == 0x8086) && (PciDeviceId == 0x0B60)) {
+CopyMem (DeviceSecurityPolicy, , 
sizeof(EDKII_DEVICE_SECURITY_POLICY));
+  }
+
+  return EFI_SUCCESS;
+}
+
+/**
+  This function sets the device state based upon the authentication result.
+
+  The device security driver may call this interface to give the platform
+  a notify based upon the measurement or authentication result.
+  If the authentication or measurement fails, the platform may choose:
+  1) Do nothing.
+  2) Disable this device or slot temporarily and continue boot.
+  3) Reset the platform and retry again.
+  4) Disable this device or slot permanently.
+  5) Any other platform specific action.
+
+  @param[in]  This   The protocol instance pointer.
+  @param[in]  DeviceId   The Identifier for the device.
+  @param[in]  DeviceSecurityStateThe Device Security state associated with 
the device.
+
+  @retval EFI_SUCCESSThe device state is set
+  @retval EFI_UNSUPPORTEDThe function is unsupported for the 
specific Device.
+**/
+EFI_STATUS
+EFIAPI
+NotifyDeviceState (
+  IN  EDKII_DEVICE_SECURITY_POLICY_PROTOCOL  *This,
+  IN  EDKII_DEVICE_IDENTIFIER*DeviceId,
+  IN  EDKII_DEVICE_SECURITY_STATE*DeviceSecurityState
+  )
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT16  PciVendorId;
+  UINT16

[edk2-devel] [PATCH V3 4/6] IntelSiliconPkg/IntelPciDeviceSecurityDxe: Add PciSecurity.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

This driver is to do the PCI device authentication
based upon Intel PCIe Security Specification.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
Signed-off-by: Yun Lou 
---
 .../IntelPciDeviceSecurityDxe.c   | 697 ++
 .../IntelPciDeviceSecurityDxe.inf |  45 ++
 .../TcgDeviceEvent.h  | 178 +
 3 files changed, 920 insertions(+)
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.inf
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/TcgDeviceEvent.h

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.c
 
b/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.c
new file mode 100644
index 00..8838d5635a
--- /dev/null
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.c
@@ -0,0 +1,697 @@
+/** @file
+  EDKII Device Security library for PCI device.
+  It follows the Intel PCIe Security Specification.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "TcgDeviceEvent.h"
+
+typedef struct {
+  EDKII_DEVICE_SECURITY_EVENT_DATA_HEADER   EventData;
+  SPDM_MEASUREMENT_BLOCK_COMMON_HEADER  CommonHeader;
+  SPDM_MEASUREMENT_BLOCK_DMTF_HEADERDmtfHeader;
+  UINT8 Digest[SHA256_DIGEST_SIZE];
+  EDKII_DEVICE_SECURITY_EVENT_DATA_PCI_CONTEXT  PciContext;
+} EDKII_DEVICE_SECURITY_PCI_EVENT_DATA;
+
+typedef struct {
+  UINTN Signature;
+  LIST_ENTRYLink;
+  UINTN PciSegment;
+  UINTN PciBus;
+  UINTN PciDevice;
+  UINTN PciFunction;
+} PCI_DEVICE_INSTANCE;
+
+#define PCI_DEVICE_INSTANCE_SIGNATURE  SIGNATURE_32 ('P', 'D', 'I', 'S')
+#define PCI_DEVICE_INSTANCE_FROM_LINK(a)  CR (a, PCI_DEVICE_INSTANCE, Link, 
PCI_DEVICE_INSTANCE_SIGNATURE)
+
+LIST_ENTRY mSecurityEventMeasurementDeviceList = 
INITIALIZE_LIST_HEAD_VARIABLE(mSecurityEventMeasurementDeviceList);;
+EDKII_DEVICE_SECURITY_POLICY_PROTOCOL  *mDeviceSecurityPolicy;
+
+/**
+  Record a PCI device into device list.
+
+  @param PciIoPciIo instance of the device
+  @param PciDeviceListThe list to record the the device
+**/
+VOID
+RecordPciDeviceInList(
+  IN EFI_PCI_IO_PROTOCOL  *PciIo,
+  IN LIST_ENTRY   *PciDeviceList
+  )
+{
+  UINTN PciSegment;
+  UINTN PciBus;
+  UINTN PciDevice;
+  UINTN PciFunction;
+  EFI_STATUSStatus;
+  PCI_DEVICE_INSTANCE   *NewPciDevice;
+
+  Status = PciIo->GetLocation (PciIo, , , , 
);
+  ASSERT_EFI_ERROR(Status);
+
+  NewPciDevice = AllocateZeroPool(sizeof(*NewPciDevice));
+  ASSERT_EFI_ERROR(NewPciDevice != NULL);
+
+  NewPciDevice->Signature   = PCI_DEVICE_INSTANCE_SIGNATURE;
+  NewPciDevice->PciSegment  = PciSegment;
+  NewPciDevice->PciBus  = PciBus;
+  NewPciDevice->PciDevice   = PciDevice;
+  NewPciDevice->PciFunction = PciFunction;
+
+  InsertTailList(PciDeviceList, >Link);
+}
+
+/**
+  Check if a PCI device is recorded in device list.
+
+  @param PciIoPciIo instance of the device
+  @param PciDeviceListThe list to record the the device
+
+  @retval TRUE  The PCI device is in the list.
+  @retval FALSE The PCI device is NOT in the list.
+**/
+BOOLEAN
+IsPciDeviceInList(
+  IN EFI_PCI_IO_PROTOCOL  *PciIo,
+  IN LIST_ENTRY   *PciDeviceList
+  )
+{
+  UINTN PciSegment;
+  UINTN PciBus;
+  UINTN PciDevice;
+  UINTN PciFunction;
+  EFI_STATUSStatus;
+  LIST_ENTRY*Link;
+  PCI_DEVICE_INSTANCE   *CurrentPciDevice;
+
+  Status = PciIo->GetLocation (PciIo, , , , 
);
+  ASSERT_EFI_ERROR(Status);
+
+  Link = GetFirstNode(PciDeviceList);
+  while (!IsNull(PciDeviceList, Link)) {
+CurrentPciDevice = PCI_DEVICE_INSTANCE_FROM_LINK(Link);
+
+if (CurrentPciDevice->PciSegment == PciSegment && CurrentPciDevice->PciBus 
== PciBus &&
+CurrentPciDevice->PciDevice == PciDevice && 
CurrentPciDevice->PciFunction == PciFunction) {
+  DEBUG((DEBUG_INFO, "PCI device duplicated (Loc - 
%04x:%02x:%02x:%02x)\n", PciSegment, PciBus, PciDevice, PciFunction));
+  return TRUE;
+}
+
+Link = GetNextNode(PciDeviceList, Link);
+  }
+
+  return FALSE;
+}
+
+/*
+  return Offset of the PCI

[edk2-devel] [PATCH V3 0/6] Add Device Security driver

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

=== V3 ===

The V3 version addresses the feedback below:

Liming Gao:
1. Add SPDM spec version and align to latest one 0.99a.

Rangasai Chaganty:
1. put a reference to the spec at the file header, for Intel PCI security spec.
2. add some high level description above the structure definition that
describes the structure.
3. on the services "GetDevicePolicy" and "SetDeviceState", Add more error
return states

Ray Ni:
1. add comments to each field of structures like EDKII_DEVICE_SECURITY_POLICY
and EDKII_DEVICE_SECURITY_STATE.
2. add comments to all the macros defined in this patch to explain the meaning
and more important how they are going to impact the logic.
3. make the macro short
EDKII_DEVICE_MEASUREMENT_POLICY_REQUIRED ->
EDKII_DEVICE_MEASUREMENT_REQUIRED
EDKII_DEVICE_AUTHENTICATION_POLICY_REQUIRED ->
EDKII_DEVICE_AUTHENTICATION_REQUIRED
4. rename the SetDeviceState to NotifyDeviceState.
5. add comments to explain clearly what SetDeviceState() needs to do.
6. change the prototype so that caller needs to pass in a policy structure and
GetDevicePolicy() fills the structure buffer using CopyMem.
7. add the version macro for EDKII_DEVICE_SECURITY_POLICY_PROTOCOL.Version,
securitypolicy.version and securitystate.version.
8. add clear debug information for DvSec capability header.

=== V2 ===

This patch series add support for device security based
upon the DMTF SPDM specification.
https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a.zip

We did design review at 18 Oct, 2019.
https://edk2.groups.io/g/devel/files/Designs/2019/1018
And the feedback from the meeting is addressed.
https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-Device%20Firmware%20Security%20v2.pdf

The Device security protocol is added in EDKII repo.
Here we add the producer what follows Intel PCI security spec
to do the device firmware measurement.
https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html

The EDKII repo update is at
https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
The EDKII platform repo update is at
https://github.com/jyao1/edk2-platforms/tree/DeviceSecurityMasterV2

The validation has been done on a Intel internal platform.
The device measurement can be shown in TCG event log.

signed-off-by: Jiewen Yao

Jiewen Yao (6):
IntelSiliconPkg/Include: Add Intel PciSecurity definition.
IntelSiliconPkg/Include: Add Platform Device Security Policy protocol
IntelSiliconPkg/dec: Add ProtocolGuid definition.
IntelSiliconPkg/IntelPciDeviceSecurityDxe: Add PciSecurity.
IntelSiliconPkg/SamplePlatformDevicePolicyDxe: Add sample policy.
IntelSiliconPkg/dsc: Add Device Security component.

.../IntelPciDeviceSecurityDxe.c | 697 ++
.../IntelPciDeviceSecurityDxe.inf | 45 ++
.../TcgDeviceEvent.h | 178 +
.../SamplePlatformDevicePolicyDxe.c | 204 +
.../SamplePlatformDevicePolicyDxe.inf | 40 +
.../IndustryStandard/IntelPciSecurity.h | 92 +++
.../Protocol/PlatformDeviceSecurityPolicy.h | 128
.../Intel/IntelSiliconPkg/IntelSiliconPkg.dec | 4 +
.../Intel/IntelSiliconPkg/IntelSiliconPkg.dsc | 3 +
9 files changed, 1391 insertions(+)
create mode 100644
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.c
create mode 100644
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.inf
create mode 100644
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/TcgDeviceEvent.h
create mode 100644
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.c
create mode 100644
Silicon/Intel/IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.inf
create mode 100644
Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
create mode 100644
Silicon/Intel/IntelSiliconPkg/Include/Protocol/PlatformDeviceSecurityPolicy.h

--
2.19.2.windows.1

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50219): https://edk2.groups.io/g/devel/message/50219
Mute This Topic: https://groups.io/mt/46027839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 3/6] IntelSiliconPkg/dec: Add ProtocolGuid definition.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec | 4 
 1 file changed, 4 insertions(+)

diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
index 3079fc2869..22ebf19c4e 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
@@ -54,6 +54,10 @@
 [Protocols]
   gEdkiiPlatformVTdPolicyProtocolGuid = { 0x3d17e448, 0x466, 0x4e20, { 0x99, 
0x9f, 0xb2, 0xe1, 0x34, 0x88, 0xee, 0x22 }}
 
+  ## Protocol for device security policy.
+  # Include/Protocol/PlatformDeviceSecurityPolicy.h
+  gEdkiiDeviceSecurityPolicyProtocolGuid = {0x7ea41a99, 0x5e32, 0x4c97, {0x88, 
0xc4, 0xd6, 0xe7, 0x46, 0x84, 0x9, 0xd4}}
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Error code for VTd error.
   #  EDKII_ERROR_CODE_VTD_ERROR = (EFI_IO_BUS_UNSPECIFIED | (EFI_OEM_SPECIFIC 
| 0x)) = 0x02008000
-- 
2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50222): https://edk2.groups.io/g/devel/message/50222
Mute This Topic: https://groups.io/mt/46027948/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 1/6] IntelSiliconPkg/Include: Add Intel PciSecurity definition.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 .../IndustryStandard/IntelPciSecurity.h   | 92 +++
 1 file changed, 92 insertions(+)
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
new file mode 100644
index 00..f2bdb7ee2d
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IntelPciSecurity.h
@@ -0,0 +1,92 @@
+/** @file
+  Intel PCI security data structure definition from
+  PCIe* Device Security Enhancements Specification.
+
+  
https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html
+
+  NOTE: The data structure is not fully match the current specification,
+  because it is aligned with the real hardware implementation with minor 
adjustment
+  on INTEL_PCI_DIGEST_CAPABILITY_STRUCTURE, INTEL_PCI_DIGEST_DATA_MODIFIED and
+  INTEL_PCI_DIGEST_DATA_VALID.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __INTEL_PCI_SECURITY_H__
+#define __INTEL_PCI_SECURITY_H__
+
+#pragma pack(1)
+
+///
+/// The PCIE capability structure header for Intel PCI DVSEC extension.
+///
+typedef struct {
+  UINT16  CapId;   // 0x23: DVSEC
+  UINT16  CapVersion:4;// 1
+  UINT16  NextOffset:12;
+  UINT16  DvSecVendorId;   // 0x8086
+  UINT16  DvSecRevision:4; // 1
+  UINT16  DvSecLength:12;
+  UINT16  DvSecId; // 0x3E: Measure
+} INTEL_PCI_DIGEST_CAPABILITY_HEADER;
+
+#define INTEL_PCI_CAPID_DVSEC0x23
+#define INTEL_PCI_DVSEC_VENDORID_INTEL   0x8086
+#define INTEL_PCI_DVSEC_DVSECID_MEASUREMENT  0x3E
+
+///
+/// The Intel PCI digest modified macro.
+///
+#define INTEL_PCI_DIGEST_MODIFIEDBIT0
+
+///
+/// The Intel PCI DVSEC digest data modified structure.
+///
+typedef union {
+  struct {
+UINT8   DigestModified:1; // RW1C
+UINT8   Reserved0:7;
+  } Bits;
+  UINT8 Data;
+} INTEL_PCI_DIGEST_DATA_MODIFIED;
+
+///
+/// The Intel PCI digest valid macro.
+///
+#define INTEL_PCI_DIGEST_0_VALID BIT0
+#define INTEL_PCI_DIGEST_0_LOCKEDBIT1
+#define INTEL_PCI_DIGEST_1_VALID BIT2
+#define INTEL_PCI_DIGEST_1_LOCKEDBIT3
+
+///
+/// The Intel PCI DVSEC digest data valid structure.
+///
+typedef union {
+  struct {
+UINT8   Digest0Valid:1;  // RO
+UINT8   Digest0Locked:1; // RO
+UINT8   Digest1Valid:1;  // RO
+UINT8   Digest1Locked:1; // RO
+UINT8   Reserved1:4;
+  } Bits;
+  UINT8 Data;
+} INTEL_PCI_DIGEST_DATA_VALID;
+
+///
+/// The PCIE capability structure for Intel PCI DVSEC extension with digest.
+///
+typedef struct {
+  INTEL_PCI_DIGEST_DATA_MODIFIED   Modified;   // RW1C
+  INTEL_PCI_DIGEST_DATA_VALID  Valid;  // RO
+  UINT16   TcgAlgId;   // RO
+  UINT8FirmwareID; // RO
+  UINT8Reserved;
+//UINT8Digest[];
+} INTEL_PCI_DIGEST_CAPABILITY_STRUCTURE;
+
+#pragma pack()
+
+#endif
+
-- 
2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50220): https://edk2.groups.io/g/devel/message/50220
Mute This Topic: https://groups.io/mt/46027867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 6/6] IntelSiliconPkg/dsc: Add Device Security component.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
index df8984a606..0a6509d8b3 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -35,6 +35,7 @@
   
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
   
MicrocodeFlashAccessLib|IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.inf
   
PeiGetVtdPmrAlignmentLib|IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
+  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
 
 [LibraryClasses.common.PEIM]
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
@@ -75,6 +76,8 @@
 
 [Components]
   IntelSiliconPkg/Library/DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.inf
+  
IntelSiliconPkg/Feature/PcieSecurity/IntelPciDeviceSecurityDxe/IntelPciDeviceSecurityDxe.inf
+  
IntelSiliconPkg/Feature/PcieSecurity/SamplePlatformDevicePolicyDxe/SamplePlatformDevicePolicyDxe.inf
   IntelSiliconPkg/Feature/VTd/IntelVTdDxe/IntelVTdDxe.inf
   IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
   IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf
-- 
2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50225): https://edk2.groups.io/g/devel/message/50225
Mute This Topic: https://groups.io/mt/46028079/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 0/4] Add SPDM device security

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

= v3 =

The patch addresses the feedback below:
Liming Gao:
1) specify the spec version in file header for SPDM.

Ray Ni:
1) create a standalone function like PciDeviceAuthenticate() and
move the new code to that function then call it from CreatePciIoDevice

= v2 =
This patch series add support for device security based
upon the DMTF SPDM specification.
https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_0.95a.zip

We did design review at 18 Oct, 2019.
https://edk2.groups.io/g/devel/files/Designs/2019/1018
And the feedback from the meeting is addressed.
https://edk2.groups.io/g/devel/files/Designs/2019/1018/EDKII-Device%20Firmware%20Security%20v2.pdf

We add the Device security protocol in EDKII repo.
PCI bus driver consumes the interface.
If there is no producer, the PCI bus driver keeps current behavior.

So far, we only provide the producer what follows Intel
PCI security spec.
https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html
The implementation is put to EDKII platform repo.

The EDKII repo update is at 
https://github.com/jyao1/edk2/tree/DeviceSecurityMasterV2
The EDKII platform repo update is at 
https://github.com/jyao1/edk2-platforms/tree/DeviceSecurityMasterV2

The validation has been done on a Intel internal platform.
The device measurement can be shown in TCG event log.

signed-off-by: Jiewen Yao 

Jiewen Yao (4):
  MdePkg/Include: Add DMTF SPDM definition.
  MdeModulePkg/Include: Add DeviceSecurity.h
  MdeModulePkg/dec: Add EdkiiDeviceSecurityProtocolGuid.
  MdeModulePkg/Pci: Add DeviceSecurity support.

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c   |  12 +-
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |   4 +-
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |  77 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |   4 +-
 .../Include/Protocol/DeviceSecurity.h | 162 +
 MdeModulePkg/MdeModulePkg.dec |   5 +
 MdePkg/Include/IndustryStandard/Spdm.h| 320 ++
 8 files changed, 581 insertions(+), 4 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/DeviceSecurity.h
 create mode 100644 MdePkg/Include/IndustryStandard/Spdm.h

-- 
2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50218): https://edk2.groups.io/g/devel/message/50218
Mute This Topic: https://groups.io/mt/46026514/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 2/4] MdeModulePkg/Include: Add DeviceSecurity.h

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

EDKII_DEVICE_SECURITY_PROTOCOL is used for device
measurement and/or authentication.
It is similar to EFI_SECURITY_ARCH_PROTOCOL.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 .../Include/Protocol/DeviceSecurity.h | 162 ++
 1 file changed, 162 insertions(+)
 create mode 100644 MdeModulePkg/Include/Protocol/DeviceSecurity.h

diff --git a/MdeModulePkg/Include/Protocol/DeviceSecurity.h 
b/MdeModulePkg/Include/Protocol/DeviceSecurity.h
new file mode 100644
index 00..c3bf624cac
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/DeviceSecurity.h
@@ -0,0 +1,162 @@
+/** @file
+  Device Security Protocol definition.
+
+  It is used to authenticate a device based upon the platform policy.
+  It is similar to the EFI_SECURITY_ARCH_PROTOCOL, which is used to verify a 
image.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+
+#ifndef __DEVICE_SECURITY_H__
+#define __DEVICE_SECURITY_H__
+
+//
+// Device Security Protocol GUID value
+//
+#define EDKII_DEVICE_SECURITY_PROTOCOL_GUID \
+{ \
+  0x5d6b38c8, 0x5510, 0x4458, { 0xb4, 0x8d, 0x95, 0x81, 0xcf, 0xa7, 0xb0, 
0xd } \
+}
+
+//
+// Forward reference for pure ANSI compatability
+//
+typedef struct _EDKII_DEVICE_SECURITY_PROTOCOL  EDKII_DEVICE_SECURITY_PROTOCOL;
+
+//
+// Revision The revision to which the DEVICE_SECURITY interface adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_DEVICE_SECURITY_PROTOCOL_REVISION 0x0001
+
+//
+// The device identifier.
+//
+typedef struct {
+  ///
+  /// Version of this data structure.
+  ///
+  UINT32Version;
+  ///
+  /// Type of the device.
+  /// This field is also served as a device Access protocol GUID.
+  /// The device access protocol is installed on the DeviceHandle.
+  /// The device access protocol is device specific.
+  ///   EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID means the device access protocol 
is PciIo.
+  ///   EDKII_DEVICE_IDENTIFIER_TYPE_USB_GUID means the device access protocol 
is UsbIo.
+  ///
+  EFI_GUID  DeviceType;
+  ///
+  /// The handle created for this device.
+  /// NOTE: This might be a temporary handle.
+  ///   If the device is not authenticated, this handle shall be 
uninstalled.
+  ///
+  /// As minimal requirement, there should be 2 protocols installed on the 
device handle.
+  /// 1) An EFI_DEVICE_PATH_PROTOCOL with EFI_DEVICE_PATH_PROTOCOL_GUID.
+  /// 2) A device access protocol with EDKII_DEVICE_IDENTIFIER_TYPE_xxx_GUID.
+  ///If the device is PCI device, the EFI_PCI_IO_PROTOCOL is installed with
+  ///EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID.
+  ///If the device is USB device, the EFI_USB_IO_PROTOCOL is installed with
+  ///EDKII_DEVICE_IDENTIFIER_TYPE_USB_GUID.
+  ///
+  ///The device access protocol is required, because the verifier need 
have a way
+  ///to communciate with the device hardware to get the measurement or do 
the
+  ///challenge/response for the device authentication.
+  ///
+  /// NOTE: We don't use EFI_PCI_IO_PROTOCOL_GUID or EFI_USB_IO_PROTOCOL_GUID 
here,
+  ///   because we don't want to expose a real protocol. A platform may 
have driver
+  ///   register a protocol notify function. Installing a real protocol 
may cause
+  ///   the callback function being executed before the device is 
authenticated.
+  ///
+  EFI_HANDLEDeviceHandle;
+} EDKII_DEVICE_IDENTIFIER;
+
+//
+// Revision The revision to which the DEVICE_IDENTIFIER interface adheres.
+//  All future revisions must be backwards compatible.
+//
+#define EDKII_DEVICE_IDENTIFIER_REVISION 0x0001
+
+//
+// Device Identifier GUID value
+//
+#define EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID \
+{ \
+  0x2509b2f1, 0xa022, 0x4cca, { 0xaf, 0x70, 0xf9, 0xd3, 0x21, 0xfb, 0x66, 
0x49 } \
+}
+
+#define EDKII_DEVICE_IDENTIFIER_TYPE_USB_GUID \
+{ \
+  0x7394f350, 0x394d, 0x488c, { 0xbb, 0x75, 0xc, 0xab, 0x7b, 0x12, 0xa, 
0xc5 } \
+}
+
+/**
+  The device driver uses this service to measure and/or verify a device.
+
+  The flow in device driver is:
+  1) Device driver discovers a new device.
+  2) Device driver creates an EFI_DEVICE_PATH_PROTOCOL.
+  3) Device driver creates a device access protocol. e.g.
+ EFI_PCI_IO_PROTOCOL for PCI device.
+ EFI_USB_IO_PROTOCOL for USB device.
+ EFI_EXT_SCSI_PASS_THRU_PROTOCOL for SCSI device.
+ EFI_ATA_PASS_THRU_PROTOCOL for ATA device.
+ EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL for NVMe device.
+ EFI_SD_MMC_PASS_THRU_PROTOCOL for SD/MMC device.
+  4) Device driver installs the EFI_DEVICE_PATH_PROTOCOL with 
EFI_DEVICE_PATH_PROTOCOL_GUID,
+ and the device access protocol with EDKII_DEVICE_IDENTIFIER_TYPE_xxx_GUID.
+ Once it is done,

[edk2-devel] [PATCH V3 3/4] MdeModulePkg/dec: Add EdkiiDeviceSecurityProtocolGuid.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/MdeModulePkg.dec | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index d6bac974da..b7356aa4ed 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -584,6 +584,11 @@
   ## Include/Protocol/IoMmu.h
   gEdkiiIoMmuProtocolGuid = { 0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 
0xe1, 0xce, 0x51, 0x7c, 0x1e } }
 
+  ## Include/Protocol/DeviceSecurity.h
+  gEdkiiDeviceSecurityProtocolGuid  = { 0x5d6b38c8, 0x5510, 0x4458, { 0xb4, 
0x8d, 0x95, 0x81, 0xcf, 0xa7, 0xb0, 0xd } }
+  gEdkiiDeviceIdentifierTypePciGuid = { 0x2509b2f1, 0xa022, 0x4cca, { 0xaf, 
0x70, 0xf9, 0xd3, 0x21, 0xfb, 0x66, 0x49 } }
+  gEdkiiDeviceIdentifierTypeUsbGuid = { 0x7394f350, 0x394d, 0x488c, { 0xbb, 
0x75, 0xc, 0xab, 0x7b, 0x12, 0xa, 0xc5 } }
+
   ## Include/Protocol/SmmMemoryAttribute.h
   gEdkiiSmmMemoryAttributeProtocolGuid = { 0x69b792ea, 0x39ce, 0x402d, { 0xa2, 
0xa6, 0xf7, 0x21, 0xde, 0x35, 0x1d, 0xfe } }
 
-- 
2.19.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50216): https://edk2.groups.io/g/devel/message/50216
Mute This Topic: https://groups.io/mt/46026440/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 4/4] MdeModulePkg/Pci: Add DeviceSecurity support.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303

Whenever a PCI device is discovered, PCI bus calls the
EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it.
If the function returns success, the PCI bus allocates
the resource and installs the PCI_IO for the device.
If the function returns fail, the PCI bus skips the device.

It is similar to EFI_SECURITY_ARCH_PROTOCOL, which
is used to verify an EFI image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Yun Lou 
Signed-off-by: Jiewen Yao 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c   | 12 ++-
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |  1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  4 +-
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  | 77 +++
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |  4 +-
 5 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
index b020ce50ce..64284ac825 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
@@ -8,7 +8,7 @@
   PCI Root Bridges. So it means platform needs install PCI Root Bridge IO 
protocol for each
   PCI Root Bus and install PCI Host Bridge Resource Allocation Protocol.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -37,7 +37,7 @@ UINT64gAllZero
 = 0;
 EFI_PCI_PLATFORM_PROTOCOL *gPciPlatformProtocol;
 EFI_PCI_OVERRIDE_PROTOCOL *gPciOverrideProtocol;
 EDKII_IOMMU_PROTOCOL  *mIoMmuProtocol;
-
+EDKII_DEVICE_SECURITY_PROTOCOL*mDeviceSecurityProtocol;
 
 GLOBAL_REMOVE_IF_UNREFERENCED EFI_PCI_HOTPLUG_REQUEST_PROTOCOL 
mPciHotPlugRequest = {
   PciHotPlugRequestNotify
@@ -293,6 +293,14 @@ PciBusDriverBindingStart (
   );
   }
 
+  if (mDeviceSecurityProtocol == NULL) {
+gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **) 
+  );
+  }
+
   if (PcdGetBool (PcdPciDisableBusEnumeration)) {
 gFullEnumeration = FALSE;
   } else {
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
index 504a1b1c12..d4113993c8 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
@@ -27,6 +27,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
index 05c22025b8..9284998f36 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
@@ -2,7 +2,7 @@
 #  The PCI bus driver will probe all PCI devices and allocate MMIO and IO 
space for these devices.
 #  Please use PCD feature flag PcdPciBusHotplugDeviceSupport to enable hot 
plug supporting.
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -90,6 +90,8 @@
   gEfiIncompatiblePciDeviceSupportProtocolGuid## SOMETIMES_CONSUMES
   gEfiLoadFile2ProtocolGuid   ## SOMETIMES_PRODUCES
   gEdkiiIoMmuProtocolGuid ## SOMETIMES_CONSUMES
+  gEdkiiDeviceSecurityProtocolGuid## SOMETIMES_CONSUMES
+  gEdkiiDeviceIdentifierTypePciGuid   ## SOMETIMES_CONSUMES
   gEfiLoadedImageDevicePathProtocolGuid   ## CONSUMES
 
 [FeaturePcd]
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index c7eafff593..f8020f4e72 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -10,6 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include "PciBus.h"
 
 extern CHAR16  *mBarTypeStr[];
+extern EDKII_DEVICE_SECURITY_PROTOCOL  
*mDeviceSecurityProtocol;
 
 #define OLD_ALIGN   0xULL
 #define EVEN_ALIGN  0xFFFEULL
@@ -2070,6 +2071,67 @@ InitializeP2C (
   PciIo->Pci.Write (PciIo, EfiPciIoWidthUint8, 0x3C, 1, );
 }
 
+/*
+  Authenticate the PCI device by using DeviceSecurityProtocol.
+
+  @param PciIoDevice  PCI device.
+
+  @retval EFI_SUCCESS The device passes the authentication.
+  @return not EFI_SUCCESS The device failes the authentication or
+  unexpected error happen during authentication.
+*/
+EFI_STATUS
+AuthenticatePciDevice (
+  IN PCI_IO_DEVICE*PciIoDevice
+  )
+{
+  EDKII_DEVICE_IDENTIFIER  DeviceIdentifier;
+  EFI_STATUS   Status;
+
+  if (mDeviceSecurityProtocol != NULL) {
+//
+// Prepare the parameter
+//
+

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 13:50, Paolo Bonzini wrote:
> On 07/11/19 12:55, Daniel P. Berrangé wrote:
>>> Yes, I would make SMM use a cryptographic pseudo-random number generator 
>>> and seed it from virtio-rng from DXE, way before the OS starts and can 
>>> "attack" it.
>>>
>>> Once you've gotten a seed, you can create a CSPRNG with a stream cipher 
>>> such as ChaCha20, which is literally 30 lines of code.
>> If all we need is a one-time seed then virtio-rng is possibly overkill as
>> that provides a continuous stream. Instead could QEMU read a few bytes
>> from the host's /dev/urandom and pass it to EDK via fw_cfg, which can
>> use it for the CSPRNG seed. EDK would have to erase the fw_cfg field
>> to prevent the seed value leaking to the guest OS, but other than that
>> its quite straightforward.
> 
> That would need anyway a change to the emulated hardware.  If the guest
> is able to use virtio-rng after the firmware exits (which is the case is
> all the firmware needs is a one-time seed), then using virtio-rng is the
> simplest alternative as it needs no change at all outside the firmware.

This is a really good point!

I'll think more about using virtio-rng, hopefully without horribly
hacking OVMF's BDS code.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50213): https://edk2.groups.io/g/devel/message/50213
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 12:37, Paolo Bonzini wrote:
> On 07/11/19 11:25, Ard Biesheuvel wrote:
>>> This looks problematic on QEMU. Entropy is a valuable resource, and
>>> whatever resource SMM drivers depend on, should not be possible for e.g.
>>> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
>>> Therefore, it's not *only* the case that SMM drivers must not consume
>>> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
>>> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
>>> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
>>>
>> The typical model is to seed a DRBG [deterministic pseudorandom
>> sequence generator] using a sufficient amount of high quality entropy.
>> Once you have done that, it is rather hard to exhaust a DRBG - it is a
>> mathematical construction that is designed to last for a long time (<=
>> 2^48 invocations [not bytes] according to the NIST spec), after which
>> it does not degrade although it may have generated so much output that
>> its internal state may be inferred if you have captured enough of it
>> (which is a rather theoretical issue IMHO)
>>
>> The problem is that using the output of a DRBG as a seed is
>> non-trivial - the spec describes ways to do this, but wiring
>> virtio-rng to a DRBG in the host and using its output to seed a DRBG
>> in the guest is slighly problematic.
>>
>> So it seems to me that the correct way to model this is to make the
>> host's true entropy source a shared resource like any other.
>>
> 
> Yes, I would make SMM use a cryptographic pseudo-random number generator 
> and seed it from virtio-rng from DXE,

The VirtioRngDxe driver is a UEFI driver that follows the UEFI driver
model. Meaning (in this context), it is connected to the virtio-rng
device in the BDS phase, by platform BDS code.

The variable SMM driver is necessary for producing the UEFI Variable and
Variable Write architectural protocols. BDS can only be entered when all
the architectural protocols have been installed.

Therefore we have a circular dependency with the above -- assuming we
intend to delay the *startup* of the variable SMM driver until after
EFI_RNG_PROTOCOL is available.

But, perhaps, could the variable SMM driver start up anyway, and consume
EFI_RNG_PROTOCOL just when it really needs the random seed? I doubt it:
other EFI_RNG_PROTOCOL instances could be produced by other (3rd party)
UEFI drivers. Or other (3rd party) modules could "attack" VirtioRngDxe.
A privileged (SMM) driver should not consume such sensitive data from a
non-privileged driver, unless the latter was built into the platform
firmware, and the consumption occurred before the End-of-Dxe event
(which is signaled by platform BDS, early in the BDS phase).

Put differently, the non-privileged driver that's the source of the
sensitive data would have to be a "platform DXE driver". The virtio
drivers are not such drivers however.

I can imagine a roundabout way to hack this around in OVMF's platform
BDS, quite horribly, but I'd like to consider other approaches first.

Thank you!
Laszlo

> way before the OS starts and can 
> "attack" it.
> 
> Once you've gotten a seed, you can create a CSPRNG with a stream cipher 
> such as ChaCha20, which is literally 30 lines of code.
> 
> Paolo
> 
> #define ROTL(a,b) (((a) << (b)) | ((a) >> (32 - (b
> #define QR(a, b, c, d) (  \
>   a += b,  d ^= a,  d = ROTL(d,16),   \
>   c += d,  b ^= c,  b = ROTL(b,12),   \
>   a += b,  d ^= a,  d = ROTL(d, 8),   \
>   c += d,  b ^= c,  b = ROTL(b, 7))
> #define ROUNDS 20
> 
> // initial state:
> // in[0] = 0x65787061
> // in[1] = 0x6e642033
> // in[2] = 0x322d6279
> // in[3] = 0x7465206b
> // in[4]..in[11] = key (seed)
> // in[12]..in[13] = 0
> // in[14]..in[15] = nonce, can probably use RDTSC?
> static uint32_t in[16];
> 
> uint32_t chacha_rng(void)
> {
>   int i;
>   static uint32_t x[16], p;
>   if (p < 16)
>   return in[p++] + x[p++];
> 
>   if (++in[12] == 0)
>   ++in[13];
> 
>   for (i = 0; i < 16; ++i)
>   x[i] = in[i];
> 
>   // 10 loops × 2 rounds/loop = 20 rounds
>   for (i = 0; i < ROUNDS; i += 2) {
>   // Odd round
>   QR(x[0], x[4], x[ 8], x[12]); // column 0
>   QR(x[1], x[5], x[ 9], x[13]); // column 1
>   QR(x[2], x[6], x[10], x[14]); // column 2
>   QR(x[3], x[7], x[11], x[15]); // column 3
>   // Even round
>   QR(x[0], x[5], x[10], x[15]); // diagonal 1 (main diagonal)
>   QR(x[1], x[6], x[11], x[12]); // diagonal 2
>   QR(x[2], x[7], x[ 8], x[13]); // diagonal 3
>   QR(x[3], x[4], x[ 9], x[14]); // diagonal 4
>   }
>   p = 1;
>   return in[0] + x[0];
> }
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50212): https://edk2.groups.io/g/devel/message/50212

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 07/11/19 12:55, Daniel P. Berrangé wrote:
>> Yes, I would make SMM use a cryptographic pseudo-random number generator 
>> and seed it from virtio-rng from DXE, way before the OS starts and can 
>> "attack" it.
>>
>> Once you've gotten a seed, you can create a CSPRNG with a stream cipher 
>> such as ChaCha20, which is literally 30 lines of code.
> If all we need is a one-time seed then virtio-rng is possibly overkill as
> that provides a continuous stream. Instead could QEMU read a few bytes
> from the host's /dev/urandom and pass it to EDK via fw_cfg, which can
> use it for the CSPRNG seed. EDK would have to erase the fw_cfg field
> to prevent the seed value leaking to the guest OS, but other than that
> its quite straightforward.

That would need anyway a change to the emulated hardware.  If the guest
is able to use virtio-rng after the firmware exits (which is the case is
all the firmware needs is a one-time seed), then using virtio-rng is the
simplest alternative as it needs no change at all outside the firmware.

Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50211): https://edk2.groups.io/g/devel/message/50211
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 07/11/19 12:52, Daniel P. Berrangé wrote:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013
> 
> Is it practical to provide a jitter entropy source for EDK2
> too ?

The hard part is not collecting jitter (though the firmware might be too
deterministic for that), but rather turning it into a random number seed
(mixing data from various sources, crediting entropy, etc.).

Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50210): https://edk2.groups.io/g/devel/message/50210
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP instructions that are patched already

2019-11-07 Thread Cohen, Eugene

Ard,

Fantastic discovery tracking this down to the toolchain.

Tested-by: Eugene Cohen 

Thanks,

Eugene

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, November 07, 2019 2:09 AM
> To: edk2-devel-groups-io ; Leif Lindholm
> ; Gao, Liming 
> Cc: Cohen, Eugene 
> Subject: Re: [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP
> instructions that are patched already
> 
> (+ Leif, Liming)
> 
> On Thu, 7 Nov 2019 at 10:06, Ard Biesheuvel 
> wrote:
> >
> > In order to permit the use of compilers that only implement the small
> > code model [which involves the use of ADRP instructions that require
> > 4 KB segment alignment] for generating PE/COFF binaries with a small
> > footprint, we patch ADRP instructions into ADR instructions while
> > doing the ELF to PE/COFF conversion.
> >
> > As it turns out, the linker may be doing the same, but for different
> > reasons: there is a silicon erratum #843419 for ARM Cortex-A53 which
> > affects ADRP instructions appearing at a certain offset in memory, and
> > one of the mitigations for this erratum is to patch them into ADR
> > instructions at link time if the symbol reference is within -/+ 1 MB.
> > However, the LD linker fails to update the static relocation tables,
> > and so we end up with an ADR instruction in the fully linked binary,
> > but with a relocation entry in the RELA section identifying it as an
> > ADRP instruction.
> >
> > Since the linker has already updated the symbol reference, there is no
> > handling needed in GenFw for such instructions, and we can simply
> > treat it as an ordinary ADR. However, since it is guaranteed to be
> > accompanied by an add or load instruction with a LO12 relocation
> > referencing the same symbol, the section offset check we apply to ADR
> > instructions is going to take place anyway, so we can just disregard the ADR
> instruction entirely.
> >
> > Reported-by: Eugene Cohen 
> > Suggested-by: Eugene Cohen 
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > index d574300ac4fe..d623dce1f9da 100644
> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > @@ -1044,6 +1044,19 @@ WriteSections64 (
> >  /* fall through */
> >
> >case R_AARCH64_ADR_PREL_PG_HI21:
> > +//
> > +// In order to handle Cortex-A53 erratum #843419, the LD 
> > linker may
> > +// convert ADRP instructions into ADR instructions, but without
> > +// updating the static relocation type, and so we may end up 
> > here
> > +// while the instruction in question is actually ADR. So let's
> > +// just disregard it: the section offset check we apply below 
> > to
> > +// ADR instructions will trigger for its
> R_AARCH64_xxx_ABS_LO12_NC
> > +// companion instruction as well, so it is safe to omit it 
> > here.
> > +//
> > +if ((*(UINT32 *)Targ & BIT31) == 0) {
> > +  break;
> > +}
> > +
> >  //
> >  // AArch64 PG_H21 relocations are typically paired with 
> > ABS_LO12
> >  // relocations, where a PC-relative reference with +/- 4
> > GB range is
> > --
> > 2.17.1
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50209): https://edk2.groups.io/g/devel/message/50209
Mute This Topic: https://groups.io/mt/45528390/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Daniel P . Berrangé

On Thu, Nov 07, 2019 at 12:37:11PM +0100, Paolo Bonzini wrote:
> On 07/11/19 11:25, Ard Biesheuvel wrote:
> >> This looks problematic on QEMU. Entropy is a valuable resource, and
> >> whatever resource SMM drivers depend on, should not be possible for e.g.
> >> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
> >> Therefore, it's not *only* the case that SMM drivers must not consume
> >> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
> >> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
> >> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
> >>
> > The typical model is to seed a DRBG [deterministic pseudorandom
> > sequence generator] using a sufficient amount of high quality entropy.
> > Once you have done that, it is rather hard to exhaust a DRBG - it is a
> > mathematical construction that is designed to last for a long time (<=
> > 2^48 invocations [not bytes] according to the NIST spec), after which
> > it does not degrade although it may have generated so much output that
> > its internal state may be inferred if you have captured enough of it
> > (which is a rather theoretical issue IMHO)
> > 
> > The problem is that using the output of a DRBG as a seed is
> > non-trivial - the spec describes ways to do this, but wiring
> > virtio-rng to a DRBG in the host and using its output to seed a DRBG
> > in the guest is slighly problematic.
> > 
> > So it seems to me that the correct way to model this is to make the
> > host's true entropy source a shared resource like any other.
> > 
> 
> Yes, I would make SMM use a cryptographic pseudo-random number generator 
> and seed it from virtio-rng from DXE, way before the OS starts and can 
> "attack" it.
> 
> Once you've gotten a seed, you can create a CSPRNG with a stream cipher 
> such as ChaCha20, which is literally 30 lines of code.

If all we need is a one-time seed then virtio-rng is possibly overkill as
that provides a continuous stream. Instead could QEMU read a few bytes
from the host's /dev/urandom and pass it to EDK via fw_cfg, which can
use it for the CSPRNG seed. EDK would have to erase the fw_cfg field
to prevent the seed value leaking to the guest OS, but other than that
its quite straightforward.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50208): https://edk2.groups.io/g/devel/message/50208
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Daniel P . Berrangé

On Thu, Nov 07, 2019 at 11:10:57AM +0100, Laszlo Ersek wrote:
> Hi,
> 
> related TianoCore BZ:
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=1871
> 
> (I'm starting this thread separately because at least some of the topics
> are specific to QEMU, and I didn't want to litter the BZ with a
> discussion that may not be interesting to all participants CC'd on the
> BZ. I am keeping people CC'd on this initial posting; please speak up if
> you'd like to be dropped from the email thread.)
> 
> QEMU provides guests with the virtio-rng device, and the OVMF and
> ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that
> device. But, that doesn't seem enough for all edk2 use cases.
> 
> Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its
> absence may affect some other use cases.

The optional nature of virtio-rng is something that results in the
the same problems for Linux.

If virtio-rng is absent, then Linux now has a general purpose fallback
via the CPU timing jitter entropy source:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013

Is it practical to provide a jitter entropy source for EDK2
too ?

> (1) For UEFI HTTPS boot, TLS would likely benefit from good quality
> entropy. If the VM config includes virtio-rng (hence the guest firmware
> has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.
> 
> However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
> UEFI HTTPS boot be disabled completely (or prevented / rejected
> somehow), blaming lack of good entropy? Or should TLS silently fall back
> to "mixing some counters [such as TSC] together and applying a
> deterministic cryptographic transformation"?
> 
> IOW, knowing that the TLS setup may not be based on good quality
> entropy, should we allow related firmware services to "degrade silently"
> (not functionally, but potentially in security), or should we deny the
> services altogether?

If we can guarantee we always present fallback like jitterentropy
then the problem with TLS init goes away IIUC.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50207): https://edk2.groups.io/g/devel/message/50207
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 11:25, Ard Biesheuvel wrote:
> On Thu, 7 Nov 2019 at 11:11, Laszlo Ersek  wrote:

>> (1) For UEFI HTTPS boot, TLS would likely benefit from good quality
>> entropy. If the VM config includes virtio-rng (hence the guest firmware
>> has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.
>>
>> However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
>> UEFI HTTPS boot be disabled completely (or prevented / rejected
>> somehow), blaming lack of good entropy? Or should TLS silently fall back
>> to "mixing some counters [such as TSC] together and applying a
>> deterministic cryptographic transformation"?
>>
>> IOW, knowing that the TLS setup may not be based on good quality
>> entropy, should we allow related firmware services to "degrade silently"
>> (not functionally, but potentially in security), or should we deny the
>> services altogether?
>>
> 
> TLS uses a source of randomness to establish symmetric session keys
> for encryption. So it really depends on the use case whether HTTPS is
> used for authentication or for confidentiality, and it seems to me
> that it would typically be the former. So disabling HTTPS boot in this
> case seems counterproductive to me.

OK. So this might be an argument for an RngLib instance that tries to
consume EFI_RNG_PROTOCOL, and if the protocol is absent, the lib
instance falls back to a TSC-seeded PRNG.

We'd have to make sure (or prove) that the protocol lookup in the lib
occurs *after* BDS made an attempt to connect the virtio-rng device(s).

>> (2) It looks like the SMM driver implementing the privileged part of the
>> UEFI variable runtime service could need access to good quality entropy,
>> while running in SMM; in the future.
>>
>> This looks problematic on QEMU. Entropy is a valuable resource, and
>> whatever resource SMM drivers depend on, should not be possible for e.g.
>> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
>> Therefore, it's not *only* the case that SMM drivers must not consume
>> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
>> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
>> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
>>
> 
> The typical model is to seed a DRBG [deterministic pseudorandom
> sequence generator] using a sufficient amount of high quality entropy.
> Once you have done that, it is rather hard to exhaust a DRBG - it is a
> mathematical construction that is designed to last for a long time (<=
> 2^48 invocations [not bytes] according to the NIST spec), after which
> it does not degrade although it may have generated so much output that
> its internal state may be inferred if you have captured enough of it
> (which is a rather theoretical issue IMHO)

Thanks! I think this helps.

Because then the guest SMM code could read the seed from (for example) a
well-known PCI BDF (such as 0/0/0), at either a fixed config space
offset, or from a vendor capability. This doesn't depend on PCI
enumeration, and it also cannot be interfered with by 3rd party UEFI
code or OS code, because the only such reads would occur in the subject
SMM drivers' entry point functions.

On the Q35 board in QEMU, we already use some config space registers
that are left unspecified in Intel datasheet 316966-002, Table 5-1 "DRAM
Controller Register Address Map (D0:F0)", for various paravirt purposes.
We haven't run out of such "free for the taking" config space registers
yet, and for this particular purpose we only need a single byte
register. (The first read would expose whether the feature were
supported, the other reads would provide bytes for the seed.)

> 
> The problem is that using the output of a DRBG as a seed is
> non-trivial - the spec describes ways to do this, but wiring
> virtio-rng to a DRBG in the host and using its output to seed a DRBG
> in the guest is slighly problematic.

Can we forward /dev/urandom from the host to the guest through an
interface like described above? (Single byte config space register.)

> So it seems to me that the correct way to model this is to make the
> host's true entropy source a shared resource like any other.

I don't know enough to agree or disagree. I guess this might require
additional permission management on the host side.

(NB my only purpose with this thread is to ensure that the internal edk2
interfaces, such as lib class APIs and possible SMM protocols, will
offer the dynamism that's necessary when running on QEMU.)

Thanks!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50206): https://edk2.groups.io/g/devel/message/50206
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] EmbeddedPkg/DtPlatformDxe: Add DT/ACPI Default Flexibility

2019-11-07 Thread Ard Biesheuvel

On Mon, 4 Nov 2019 at 18:49, Ashish Singhal  wrote:
>
> Add a PCD to govern whether to use DT or ACPI in case the
> variable governing this is not found or is not valid.
>
> Signed-off-by: Ashish Singhal 

Reviewed-by: Ard Biesheuvel 

Pushed as 3a63c17ebc85..601a18bf08ca

Thanks!

> ---
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c   | 16 ++--
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf |  3 +++
>  EmbeddedPkg/EmbeddedPkg.dec |  5 +
>  3 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c 
> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c
> index 907d46a..e35ca33 100644
> --- a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c
> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c
> @@ -124,18 +124,22 @@ DtPlatformDxeEntryPoint (
>  Status = gRT->GetVariable(DT_ACPI_VARIABLE_NAME, ,
>  NULL, , );
>  if (EFI_ERROR (Status)) {
> -  DEBUG ((DEBUG_WARN, "%a: no DT/ACPI preference found, defaulting to 
> DT\n",
> -__FUNCTION__));
> -  DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
> +  DEBUG ((DEBUG_WARN, "%a: no DT/ACPI preference found, defaulting to 
> %s\n",
> +__FUNCTION__, PcdGetBool (PcdDefaultDtPref) ? L"DT" : L"ACPI"));
> +  DtAcpiPref.Pref = PcdGetBool (PcdDefaultDtPref) ?
> +  DT_ACPI_SELECT_DT :
> +  DT_ACPI_SELECT_ACPI;
>  }
>}
>
>if (!EFI_ERROR (Status) &&
>DtAcpiPref.Pref != DT_ACPI_SELECT_ACPI &&
>DtAcpiPref.Pref != DT_ACPI_SELECT_DT) {
> -DEBUG ((DEBUG_WARN, "%a: invalid value for %s, defaulting to DT\n",
> -  __FUNCTION__, DT_ACPI_VARIABLE_NAME));
> -DtAcpiPref.Pref = DT_ACPI_SELECT_DT;
> +DEBUG ((DEBUG_WARN, "%a: invalid value for %s, defaulting to %s\n",
> +  __FUNCTION__, DT_ACPI_VARIABLE_NAME, PcdGetBool (PcdDefaultDtPref) ? 
> L"DT" : L"ACPI"));
> +DtAcpiPref.Pref = PcdGetBool (PcdDefaultDtPref) ?
> +DT_ACPI_SELECT_DT :
> +DT_ACPI_SELECT_ACPI;
>  Status = EFI_INVALID_PARAMETER; // trigger setvar below
>}
>
> diff --git a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf 
> b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
> index b68f154..450ea29 100644
> --- a/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
> +++ b/EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf
> @@ -46,6 +46,9 @@
>gEdkiiPlatformHasAcpiGuid
>gFdtTableGuid
>
> +[Pcd]
> +  gEmbeddedTokenSpaceGuid.PcdDefaultDtPref
> +
>  [Depex]
>gEfiVariableArchProtocolGuidAND
>gEfiVariableWriteArchProtocolGuid
> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index bbaadc5..8812a6d 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -185,3 +185,8 @@
># truncation on overflow to specify negative offsets.
>#
>gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x0|UINT64|0x058
> +
> +  #
> +  # Selection between DT and ACPI as a default
> +  #
> +  gEmbeddedTokenSpaceGuid.PcdDefaultDtPref|TRUE|BOOLEAN|0x059
> --
> 2.7.4
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50205): https://edk2.groups.io/g/devel/message/50205
Mute This Topic: https://groups.io/mt/41355681/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Dr. David Alan Gilbert

* Laszlo Ersek (ler...@redhat.com) wrote:
> On 11/07/19 11:18, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> Hi,
> >>
> >> related TianoCore BZ:
> >>
> >>   https://bugzilla.tianocore.org/show_bug.cgi?id=1871
> >>
> >> (I'm starting this thread separately because at least some of the topics
> >> are specific to QEMU, and I didn't want to litter the BZ with a
> >> discussion that may not be interesting to all participants CC'd on the
> >> BZ. I am keeping people CC'd on this initial posting; please speak up if
> >> you'd like to be dropped from the email thread.)
> >>
> >> QEMU provides guests with the virtio-rng device, and the OVMF and
> >> ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that
> >> device. But, that doesn't seem enough for all edk2 use cases.
> >>
> >> Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its
> >> absence may affect some other use cases.
> >>
> >>
> >> (1) For UEFI HTTPS boot, TLS would likely benefit from good quality
> >> entropy. If the VM config includes virtio-rng (hence the guest firmware
> >> has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.
> >>
> >> However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
> >> UEFI HTTPS boot be disabled completely (or prevented / rejected
> >> somehow), blaming lack of good entropy? Or should TLS silently fall back
> >> to "mixing some counters [such as TSC] together and applying a
> >> deterministic cryptographic transformation"?
> >>
> >> IOW, knowing that the TLS setup may not be based on good quality
> >> entropy, should we allow related firmware services to "degrade silently"
> >> (not functionally, but potentially in security), or should we deny the
> >> services altogether?
> > 
> > I don't see a downside to insisting that if you want to use https then
> > you must provide an entropy source; they're easy enough to add using
> > virtio-rng if the CPU doesn't provide it.
> 
> Possibly true; however it could be considered a usability regression by
> end-users. ("UEFI HTTPS boot used to work, now it breaks with the same
> VM config". Unless we can respond, "UEFI HTTPS boot's TLS init has never
> been secure enough", they'll have a point. See also Ard's followup.)

You could turn it into a scary warning for a few releases first.

> > 
> >>
> >> (2) It looks like the SMM driver implementing the privileged part of the
> >> UEFI variable runtime service could need access to good quality entropy,
> >> while running in SMM; in the future.
> >>
> >> This looks problematic on QEMU. Entropy is a valuable resource, and
> >> whatever resource SMM drivers depend on, should not be possible for e.g.
> >> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
> >> Therefore, it's not *only* the case that SMM drivers must not consume
> >> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
> >> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
> >> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
> >>
> >> Furthermore, assuming we dedicate a hardware entropy device specifically
> >> to SMM drivers, such a device cannot be PCI(e). It would have to be a
> >> platform device at a fixed location (IO port or MMIO) that is only
> >> accessible to such guest code that executes in SMM. IOW, device access
> >> would have to be restricted similarly to pflash. (In fact the variable
> >> SMM driver will need, AIUI, the entropy for encrypting various variable
> >> contents, which are then written into pflash.)
> > 
> > Ewww.  I guess a virtio-rng instance wired to virtio-mmio could do that.
> > It's a bit grim though.
> 
> *shudder* please let's keep virtio-mmio (or any remotely enumerable /
> complex "bus" thingy) out of this :( I'm all for extensible hardware
> interfaces, but cramming more and more infrastructure code into SMM
> looks very questionable to me.

The reason I suggested virtio-mmio was because it's not enumerable; it's
a fixed location; so you just check that the device you have there is
what you expect.
It means not inventing a new qemu device (although you would have to
make it addable on x86, and you would have to make it hideable in SMM).
(pci with preallocated addresses is similar).

> My main concern here is that most physical platform vendors will just
> solder some physical entropy-gen chip onto their boards, and then
> hard-code the MMIO base address of that as a build-time constant in
> their firmware blobs. This obviously won't work for QEMU, where the hw
> can change from boot to boot; so the generic edk2 solution (regardless
> of the actual chip) need to allow for that kind of dynamism. This is a
> recurrent problem between QEMU and edk2, alas. The answer is of course
> dynamic detection, but I *still* like to keep the enumeration logic to
> the absolute minimum in SMM.

While the hw can change from boot to boot on qemu, there's no
requirement that as a bios you respect that;

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 07/11/19 11:25, Ard Biesheuvel wrote:
>> This looks problematic on QEMU. Entropy is a valuable resource, and
>> whatever resource SMM drivers depend on, should not be possible for e.g.
>> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
>> Therefore, it's not *only* the case that SMM drivers must not consume
>> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
>> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
>> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
>>
> The typical model is to seed a DRBG [deterministic pseudorandom
> sequence generator] using a sufficient amount of high quality entropy.
> Once you have done that, it is rather hard to exhaust a DRBG - it is a
> mathematical construction that is designed to last for a long time (<=
> 2^48 invocations [not bytes] according to the NIST spec), after which
> it does not degrade although it may have generated so much output that
> its internal state may be inferred if you have captured enough of it
> (which is a rather theoretical issue IMHO)
> 
> The problem is that using the output of a DRBG as a seed is
> non-trivial - the spec describes ways to do this, but wiring
> virtio-rng to a DRBG in the host and using its output to seed a DRBG
> in the guest is slighly problematic.
> 
> So it seems to me that the correct way to model this is to make the
> host's true entropy source a shared resource like any other.
> 

Yes, I would make SMM use a cryptographic pseudo-random number generator 
and seed it from virtio-rng from DXE, way before the OS starts and can 
"attack" it.

Once you've gotten a seed, you can create a CSPRNG with a stream cipher 
such as ChaCha20, which is literally 30 lines of code.

Paolo

#define ROTL(a,b) (((a) << (b)) | ((a) >> (32 - (b
#define QR(a, b, c, d) (\
a += b,  d ^= a,  d = ROTL(d,16),   \
c += d,  b ^= c,  b = ROTL(b,12),   \
a += b,  d ^= a,  d = ROTL(d, 8),   \
c += d,  b ^= c,  b = ROTL(b, 7))
#define ROUNDS 20

// initial state:
// in[0] = 0x65787061
// in[1] = 0x6e642033
// in[2] = 0x322d6279
// in[3] = 0x7465206b
// in[4]..in[11] = key (seed)
// in[12]..in[13] = 0
// in[14]..in[15] = nonce, can probably use RDTSC?
static uint32_t in[16];

uint32_t chacha_rng(void)
{
int i;
static uint32_t x[16], p;
if (p < 16)
return in[p++] + x[p++];

if (++in[12] == 0)
++in[13];

for (i = 0; i < 16; ++i)
x[i] = in[i];

// 10 loops × 2 rounds/loop = 20 rounds
for (i = 0; i < ROUNDS; i += 2) {
// Odd round
QR(x[0], x[4], x[ 8], x[12]); // column 0
QR(x[1], x[5], x[ 9], x[13]); // column 1
QR(x[2], x[6], x[10], x[14]); // column 2
QR(x[3], x[7], x[11], x[15]); // column 3
// Even round
QR(x[0], x[5], x[10], x[15]); // diagonal 1 (main diagonal)
QR(x[1], x[6], x[11], x[12]); // diagonal 2
QR(x[2], x[7], x[ 8], x[13]); // diagonal 3
QR(x[3], x[4], x[ 9], x[14]); // diagonal 4
}
p = 1;
return in[0] + x[0];
}

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50203): https://edk2.groups.io/g/devel/message/50203
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

On 11/07/19 11:18, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> Hi,
>>
>> related TianoCore BZ:
>>
>>   https://bugzilla.tianocore.org/show_bug.cgi?id=1871
>>
>> (I'm starting this thread separately because at least some of the topics
>> are specific to QEMU, and I didn't want to litter the BZ with a
>> discussion that may not be interesting to all participants CC'd on the
>> BZ. I am keeping people CC'd on this initial posting; please speak up if
>> you'd like to be dropped from the email thread.)
>>
>> QEMU provides guests with the virtio-rng device, and the OVMF and
>> ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that
>> device. But, that doesn't seem enough for all edk2 use cases.
>>
>> Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its
>> absence may affect some other use cases.
>>
>>
>> (1) For UEFI HTTPS boot, TLS would likely benefit from good quality
>> entropy. If the VM config includes virtio-rng (hence the guest firmware
>> has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.
>>
>> However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
>> UEFI HTTPS boot be disabled completely (or prevented / rejected
>> somehow), blaming lack of good entropy? Or should TLS silently fall back
>> to "mixing some counters [such as TSC] together and applying a
>> deterministic cryptographic transformation"?
>>
>> IOW, knowing that the TLS setup may not be based on good quality
>> entropy, should we allow related firmware services to "degrade silently"
>> (not functionally, but potentially in security), or should we deny the
>> services altogether?
> 
> I don't see a downside to insisting that if you want to use https then
> you must provide an entropy source; they're easy enough to add using
> virtio-rng if the CPU doesn't provide it.

Possibly true; however it could be considered a usability regression by
end-users. ("UEFI HTTPS boot used to work, now it breaks with the same
VM config". Unless we can respond, "UEFI HTTPS boot's TLS init has never
been secure enough", they'll have a point. See also Ard's followup.)

> 
>>
>> (2) It looks like the SMM driver implementing the privileged part of the
>> UEFI variable runtime service could need access to good quality entropy,
>> while running in SMM; in the future.
>>
>> This looks problematic on QEMU. Entropy is a valuable resource, and
>> whatever resource SMM drivers depend on, should not be possible for e.g.
>> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
>> Therefore, it's not *only* the case that SMM drivers must not consume
>> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
>> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
>> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
>>
>> Furthermore, assuming we dedicate a hardware entropy device specifically
>> to SMM drivers, such a device cannot be PCI(e). It would have to be a
>> platform device at a fixed location (IO port or MMIO) that is only
>> accessible to such guest code that executes in SMM. IOW, device access
>> would have to be restricted similarly to pflash. (In fact the variable
>> SMM driver will need, AIUI, the entropy for encrypting various variable
>> contents, which are then written into pflash.)
> 
> Ewww.  I guess a virtio-rng instance wired to virtio-mmio could do that.
> It's a bit grim though.

*shudder* please let's keep virtio-mmio (or any remotely enumerable /
complex "bus" thingy) out of this :( I'm all for extensible hardware
interfaces, but cramming more and more infrastructure code into SMM
looks very questionable to me.

My main concern here is that most physical platform vendors will just
solder some physical entropy-gen chip onto their boards, and then
hard-code the MMIO base address of that as a build-time constant in
their firmware blobs. This obviously won't work for QEMU, where the hw
can change from boot to boot; so the generic edk2 solution (regardless
of the actual chip) need to allow for that kind of dynamism. This is a
recurrent problem between QEMU and edk2, alas. The answer is of course
dynamic detection, but I *still* like to keep the enumeration logic to
the absolute minimum in SMM.

Thanks!
Laszlo

> 
> Dave
> 
>> Alternatively, CPU instructions could exist that return entropy, and are
>> executable only inside SMM. It seems that e.g. RDRAND can be trapped in
>> guests ("A VMEXIT due to RDRAND will have exit reason 57 (decimal)").
>> Then KVM / QEMU could provide any particular implementation we wanted --
>> for example an exception could be injected unless RDRAND had been
>> executed from within SMM. Unfortunately, such an arbitrary restriction
>> (of RDRAND to SMM) would diverge from the Intel SDM, and would likely
>> break other (non-SMM) guest code.
>>
>> Does a platform device that is dynamically detectable and usable in SMM
>> only seem like an acceptable design for QEMU?
>>
>> Thanks,
>>

Re: [edk2-devel] privileged entropy sources in QEMU/KVM guests

2019-11-07 Thread Dr. David Alan Gilbert

* Laszlo Ersek (ler...@redhat.com) wrote:
> Hi,
> 
> related TianoCore BZ:
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=1871
> 
> (I'm starting this thread separately because at least some of the topics
> are specific to QEMU, and I didn't want to litter the BZ with a
> discussion that may not be interesting to all participants CC'd on the
> BZ. I am keeping people CC'd on this initial posting; please speak up if
> you'd like to be dropped from the email thread.)
> 
> QEMU provides guests with the virtio-rng device, and the OVMF and
> ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that
> device. But, that doesn't seem enough for all edk2 use cases.
> 
> Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its
> absence may affect some other use cases.
> 
> 
> (1) For UEFI HTTPS boot, TLS would likely benefit from good quality
> entropy. If the VM config includes virtio-rng (hence the guest firmware
> has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot.
> 
> However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should
> UEFI HTTPS boot be disabled completely (or prevented / rejected
> somehow), blaming lack of good entropy? Or should TLS silently fall back
> to "mixing some counters [such as TSC] together and applying a
> deterministic cryptographic transformation"?
> 
> IOW, knowing that the TLS setup may not be based on good quality
> entropy, should we allow related firmware services to "degrade silently"
> (not functionally, but potentially in security), or should we deny the
> services altogether?

I don't see a downside to insisting that if you want to use https then
you must provide an entropy source; they're easy enough to add using
virtio-rng if the CPU doesn't provide it.

> 
> (2) It looks like the SMM driver implementing the privileged part of the
> UEFI variable runtime service could need access to good quality entropy,
> while running in SMM; in the future.
> 
> This looks problematic on QEMU. Entropy is a valuable resource, and
> whatever resource SMM drivers depend on, should not be possible for e.g.
> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
> Therefore, it's not *only* the case that SMM drivers must not consume
> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e.
> outside of SMM/SMRAM), but also that SMM drivers must not depend on the
> same piece of *hardware* that feeds EFI_RNG_PROTOCOL.
> 
> Furthermore, assuming we dedicate a hardware entropy device specifically
> to SMM drivers, such a device cannot be PCI(e). It would have to be a
> platform device at a fixed location (IO port or MMIO) that is only
> accessible to such guest code that executes in SMM. IOW, device access
> would have to be restricted similarly to pflash. (In fact the variable
> SMM driver will need, AIUI, the entropy for encrypting various variable
> contents, which are then written into pflash.)

Ewww.  I guess a virtio-rng instance wired to virtio-mmio could do that.
It's a bit grim though.

Dave

> Alternatively, CPU instructions could exist that return entropy, and are
> executable only inside SMM. It seems that e.g. RDRAND can be trapped in
> guests ("A VMEXIT due to RDRAND will have exit reason 57 (decimal)").
> Then KVM / QEMU could provide any particular implementation we wanted --
> for example an exception could be injected unless RDRAND had been
> executed from within SMM. Unfortunately, such an arbitrary restriction
> (of RDRAND to SMM) would diverge from the Intel SDM, and would likely
> break other (non-SMM) guest code.
> 
> Does a platform device that is dynamically detectable and usable in SMM
> only seem like an acceptable design for QEMU?
> 
> Thanks,
> Laszlo
> 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50201): https://edk2.groups.io/g/devel/message/50201
Mute This Topic: https://groups.io/mt/45640732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] EDK II Maintainers please test the pull request commit gate

On 11/07/19 03:24, Michael D Kinney wrote:
> EDK II Maintainers,
> 
> Please take a few minutes to test the GitHub pull
> request commit gate feature under review in the
> edk2-staging/edk2-ci branch.  This will be the only
> method to push patches to the edk2 repo in the near
> future, and we want all current EDK II Maintainers to
> make sure they know how to use this new process on
> the edk2-staging repo before it is activated on the
> edk2 repo.
> 
> Please perform the following steps:
> * Create a personal fork of the edk2-staging repo.

Slight but relevant clarification: please create a personal fork of the
edk2-staging repo *on GitHub.com*.

> * Check out the edk2-ci branch from your personal
>   fork of the edk2-staging repo
> * Create a new branch based on the edk2-ci branch
> * Edit the file SampleFile.txt in the root of this
>   branch and add an Acked-by:  tag to 
>   the end of this file.
> * Submit a pull request against the Tianocore 
>   edk2-staging/edk2-ci.  Set the 'push' label so
>   the change to SampleFile.txt will be committed
>   if all checks pass.
> 
>   NOTE: Make sure you select the 'edk2-ci' branch.
>   The default branch for the edk2-staging repo is
>   the 'about' branch and the pull request will not
>   work against the 'about' branch.
> 
> * Verify that all checks pass and your change to
>   SampleFile.txt was merged into the 
>   edk2-staging/edk2-ci branch.
> 
> For those that prefer command line tools over a WebUI,
> the command line utility called 'hub' can be used to
> submit a pull request and check the status of a pull
> request.
> 
> * https://github.com/github/hub
> * https://github.com/github/hub/releases
> * https://hub.github.com/hub.1.html

I've gone through the above (except the personal Acked-by tag) earlier,
successfully:

https://github.com/tianocore/edk2-staging/pull/99

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50200): https://edk2.groups.io/g/devel/message/50200
Mute This Topic: https://groups.io/mt/44980130/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] DSC file : override FILE_GUID rule

On 11/07/19 05:51, Tiger Liu(BJ-RD) wrote:
> Dear All:
> I have a question about FILE_GUID override rule in dsc file.
> For example:
>   ..
>   UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> 
>   FILE_GUID = D1D74FE9-7A4E-41D3-A0B3-67F13AD34D94
> ..
>   }
> 
> Usually, will define FILE_GUID in PiSmmCpuDxeSmm.inf .
> 
> Why override it in dsc file?

IIRC, such overrides allow the platform DSC file to build the same
module multiple times, most likely with other overrides too (such as PCD
and lib class resolution). The resultant binaries will not conflict in
any firmware volume / firmware file-system, by FILE_GUID.

I don't remember the syntax, to be used in the FDF file, for refering to
all of the builds of the same module INF file.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50199): https://edk2.groups.io/g/devel/message/50199
Mute This Topic: https://groups.io/mt/45221205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 03/22] requirements.txt: Add python pip requirements file

On 11/07/19 02:13, Michael D Kinney wrote:
> From: Sean Brogan 
> 
> Add pip requirements file that is used to install the
> python pip modules build from the edk2-pytool-library and
> edk2-pytool-extensions repositories.
> 
> These python modules provide the extensions required to
> perform EDK II Continuous Integration(CI) builds.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  requirements.txt | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 requirements.txt
> 
> diff --git a/requirements.txt b/requirements.txt
> new file mode 100644
> index 00..4ad72cfc98
> --- /dev/null
> +++ b/requirements.txt
> @@ -0,0 +1,17 @@
> +## @file
> +# EDK II Python PIP requirements file
> +#
> +# This file provides the list of python components to install using PIP.
> +#
> +# Copyright (c) Microsoft Corporation. All rights reserved.

The year seems to be missing from this copyright notice too.

Thanks
Laszlo

> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +# https://pypi.org/project/pip/
> +# https://pip.pypa.io/en/stable/user_guide/#requirements-files
> +# 
> https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format
> +#
> +##
> +
> +edk2-pytool-library==0.10.*
> +edk2-pytool-extensions==0.12.*
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50198): https://edk2.groups.io/g/devel/message/50198
Mute This Topic: https://groups.io/mt/44874051/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg: Add YAML file for CI builds

On 11/07/19 11:42, Laszlo Ersek wrote:
> On 11/07/19 02:13, Michael D Kinney wrote:
>> Add YAML file to the package directory with the
>> configuration of the checks to perform during a
>> CI build.
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Laszlo Ersek 
>> Signed-off-by: Michael D Kinney 
>> Acked-by: Laszlo Ersek 
>> ---
>>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 51 +++
>>  1 file changed, 51 insertions(+)
>>  create mode 100644 UefiCpuPkg/UefiCpuPkg.ci.yaml
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml b/UefiCpuPkg/UefiCpuPkg.ci.yaml
>> new file mode 100644
>> index 00..81da29b878
>> --- /dev/null
>> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
>> @@ -0,0 +1,51 @@
>> +##
>> +# CI configuration for UefiCpuPkg
>> +#
>> +# Copyright (c) Microsoft Corporation
>> +# SPDX-License-Identifier: BSD-2-Clause-Patent
>> +##
>> +{
>> +"CompilerPlugin": {
>> +"DscPath": "UefiCpuPkg.dsc"
>> +},
>> +"CharEncodingCheck": {
>> +"IgnoreFiles": []
>> +},
>> +"DependencyCheck": {
>> +"AcceptableDependencies": [
>> +"MdePkg/MdePkg.dec",
>> +"MdeModulePkg/MdeModulePkg.dec",
>> +"UefiCpuPkg/UefiCpuPkg.dec"
>> +],
>> +# For host based unit tests
>> +"AcceptableDependencies-HOST_APPLICATION":[],
>> +# For UEFI shell based apps
>> +"AcceptableDependencies-UEFI_APPLICATION":[],
>> +"IgnoreInf": []
>> +},
>> +"DscCompleteCheck": {
>> +"DscPath": "UefiCpuPkg.dsc",
>> +"IgnoreInf": [
>> +"UefiCpuPkg/ResetVector/FixupVtf/Vtf.inf",
>> +"UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf"
>> +]
>> +},
>> +"GuidCheck": {
>> +"IgnoreGuidName": ["SecCore", "ResetVector"], # Expected 
>> duplication for gEfiFirmwareVolumeTopFileGuid
>> +"IgnoreGuidValue": [],
>> +"IgnoreFoldersAndFiles": [],
>> +"IgnoreDuplicates": []
>> +},
>> +"LibraryClassCheck": {
>> +"IgnoreHeaderFile": []
>> +},
>> +
>> +## options defined ci/Plugin/SpellCheck
>> +"SpellCheck": {
>> +"AuditOnly": True,   # Fails test but run in AuditOnly mode 
>> to collect log
>> +"IgnoreFiles": [],   # use gitignore syntax to ignore 
>> errors in matching files
>> +"ExtendWords": [],   # words to extend to the dictionary 
>> for this package
>> +"IgnoreStandardPaths": [],   # Standard Plugin defined paths that 
>> should be ignore
>> +"AdditionalIncludePaths": [] # Additional paths to spell check 
>> (wildcards supported)
>> +}
>> +}
>>
> 
> This is a very nice patch: good commit message (subjet and body both),
> and good file comment.
> 
> One suggestion: I'd recommend adding "@file" to the comment block at the
> top.
> 
> With that:
> 
> Acked-by: Laszlo Ersek 
> 
> (Of course, should "@file" confuse the YAML parser, then I won't insist,
> and my ACK still applies.)

Ah, another remark: I believe the copyright notice should state a year.
(Most likely "2019".)

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50197): https://edk2.groups.io/g/devel/message/50197
Mute This Topic: https://groups.io/mt/44874095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 22/22] Readme.md: Add CI build status badges

On 11/07/19 02:13, Michael D Kinney wrote:
> Update Readme.md with status badges from the most recent
> EDK II Continuous Integration(CI) build.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  Readme.md | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Readme.md b/Readme.md
> index 27e4ce0771..0207923763 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -3,6 +3,17 @@
>  A modern, feature-rich, cross-platform firmware development environment
>  for the UEFI and PI specifications from www.uefi.org.
>
> +# Build Status
> +
> +| Host Type | Toolchain | Branch  | Build Status | Test Status | Code 
> Coverage |
> +| : | : | :-- | :--- | :-- | 
> : |
> +| Windows   | VS2019| master  | [![Build 
> Status](https://dev.azure.com/tianocore/edk2-ci-play/_apis/build/status/edk2-staging/Windows%20VS2019%20CI?branchName=master)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  | [![Azure DevOps 
> tests](https://img.shields.io/azure-devops/tests/tianocore/edk2-ci-play/14.svg)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  | [![Code 
> Coverage](https://img.shields.io/badge/coverage-coming_soon-blue)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=27=master)
>  |
> +| Ubuntu| GCC   | master  | [![Build 
> Status](https://dev.azure.com/tianocore/edk2-ci-play/_apis/build/status/edk2-staging/Ubuntu%20GCC5%20CI?branchName=master)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
> | [![Azure DevOps 
> tests](https://img.shields.io/azure-devops/tests/tianocore/edk2-ci-play/15.svg)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
>  | [![Code 
> Coverage](https://img.shields.io/badge/coverage-coming_soon-blue)](https://dev.azure.com/tianocore/edk2-ci-play/_build/latest?definitionId=26=master)
>  |
> +
> +[More CI Build information](.pytool/Readme.md)
> +
> +# License Details
> +
>  The majority of the content in the EDK II open source project uses a
>  [BSD-2-Clause Plus Patent License](License.txt).  The EDK II open source 
> project
>  contains the following components that are covered by additional licenses:
> 

I'll defer to Leif on the source-level review of this change. :)

I did check out the "live" version, at:

https://github.com/tianocore/edk2-staging/tree/edk2-ci_V4#build-status

It looks nice to me.

Acked-by: Laszlo Ersek 

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50196): https://edk2.groups.io/g/devel/message/50196
Mute This Topic: https://groups.io/mt/44874114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 17/22] UefiCpuPkg: Add YAML file for CI builds

On 11/07/19 02:13, Michael D Kinney wrote:
> Add YAML file to the package directory with the
> configuration of the checks to perform during a
> CI build.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Michael D Kinney 
> Acked-by: Laszlo Ersek 
> ---
>  UefiCpuPkg/UefiCpuPkg.ci.yaml | 51 +++
>  1 file changed, 51 insertions(+)
>  create mode 100644 UefiCpuPkg/UefiCpuPkg.ci.yaml
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> new file mode 100644
> index 00..81da29b878
> --- /dev/null
> +++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
> @@ -0,0 +1,51 @@
> +##
> +# CI configuration for UefiCpuPkg
> +#
> +# Copyright (c) Microsoft Corporation
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +##
> +{
> +"CompilerPlugin": {
> +"DscPath": "UefiCpuPkg.dsc"
> +},
> +"CharEncodingCheck": {
> +"IgnoreFiles": []
> +},
> +"DependencyCheck": {
> +"AcceptableDependencies": [
> +"MdePkg/MdePkg.dec",
> +"MdeModulePkg/MdeModulePkg.dec",
> +"UefiCpuPkg/UefiCpuPkg.dec"
> +],
> +# For host based unit tests
> +"AcceptableDependencies-HOST_APPLICATION":[],
> +# For UEFI shell based apps
> +"AcceptableDependencies-UEFI_APPLICATION":[],
> +"IgnoreInf": []
> +},
> +"DscCompleteCheck": {
> +"DscPath": "UefiCpuPkg.dsc",
> +"IgnoreInf": [
> +"UefiCpuPkg/ResetVector/FixupVtf/Vtf.inf",
> +"UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf"
> +]
> +},
> +"GuidCheck": {
> +"IgnoreGuidName": ["SecCore", "ResetVector"], # Expected duplication 
> for gEfiFirmwareVolumeTopFileGuid
> +"IgnoreGuidValue": [],
> +"IgnoreFoldersAndFiles": [],
> +"IgnoreDuplicates": []
> +},
> +"LibraryClassCheck": {
> +"IgnoreHeaderFile": []
> +},
> +
> +## options defined ci/Plugin/SpellCheck
> +"SpellCheck": {
> +"AuditOnly": True,   # Fails test but run in AuditOnly mode 
> to collect log
> +"IgnoreFiles": [],   # use gitignore syntax to ignore errors 
> in matching files
> +"ExtendWords": [],   # words to extend to the dictionary for 
> this package
> +"IgnoreStandardPaths": [],   # Standard Plugin defined paths that 
> should be ignore
> +"AdditionalIncludePaths": [] # Additional paths to spell check 
> (wildcards supported)
> +}
> +}
> 

This is a very nice patch: good commit message (subjet and body both),
and good file comment.

One suggestion: I'd recommend adding "@file" to the comment block at the
top.

With that:

Acked-by: Laszlo Ersek 

(Of course, should "@file" confuse the YAML parser, then I won't insist,
and my ACK still applies.)

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50195): https://edk2.groups.io/g/devel/message/50195
Mute This Topic: https://groups.io/mt/44874095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 03/22] requirements.txt: Add python pip requirements file

On 11/07/19 02:13, Michael D Kinney wrote:
> From: Sean Brogan 
> 
> Add pip requirements file that is used to install the
> python pip modules build from the edk2-pytool-library and
> edk2-pytool-extensions repositories.
> 
> These python modules provide the extensions required to
> perform EDK II Continuous Integration(CI) builds.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  requirements.txt | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 requirements.txt
> 
> diff --git a/requirements.txt b/requirements.txt
> new file mode 100644
> index 00..4ad72cfc98
> --- /dev/null
> +++ b/requirements.txt
> @@ -0,0 +1,17 @@
> +## @file
> +# EDK II Python PIP requirements file
> +#
> +# This file provides the list of python components to install using PIP.
> +#
> +# Copyright (c) Microsoft Corporation. All rights reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +# https://pypi.org/project/pip/
> +# https://pip.pypa.io/en/stable/user_guide/#requirements-files
> +# 
> https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format
> +#
> +##
> +
> +edk2-pytool-library==0.10.*
> +edk2-pytool-extensions==0.12.*
> 

This is better, but I still find the plain "requirements.txt" filename
in the root directory of the project very confusing. What component
*exactly* insists on this file path and file name?

I've checked

  https://pip.pypa.io/en/stable/user_guide/#requirements-files

and it seems like "pip" can take any pathname as an argument to option "-r".

There must be a component in the CI environment that invokes "pip". Can
we file a feature request for that component, that it try
"pip-requirements.txt" first?

Hmmm... I just googled "github pip requirements.txt", assuming that
"github" was the component calling "pip". In the result list, I've found:

https://github.com/ClearingHouse/clearinghoused/blob/master/pip-requirements.txt

Is it possible that github already knows to look for
"pip-requirements.txt"? (Honestly I only suggested
"pip-requirements.txt" above because it seemed sensible.) If that's the
case, we should use it.

Furthermore, my understanding is that "the list of python components to
install using PIP" is only there for CI purposes. Can we please state
that explicitly in the comment block? (The commit message already does
that, and that's great.)

Basically when someone clones edk2 and runs "ls -l" for the first time,
there's a good chance "requirements.txt" will be among the few files
they open right after.

Thanks!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50194): https://edk2.groups.io/g/devel/message/50194
Mute This Topic: https://groups.io/mt/44874051/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v4 02/22] .gitignore: Ignore python compiled files, extdeps, and vscode