Re: [edk2] Does edk2 still support python 2?

[Laszlo Ersek]

On 10/13/18 15:17, Chen, Farrah wrote:
> Hello,
> 
> When we make edk2 "OvmfPkg/build.sh -a X64 -n 16", we met below error:
> 
> [vmm@vmm-build edk2]$ OvmfPkg/build.sh -a X64 -n 16
> Initializing workspace
> /home/fan/edk2/BaseTools
> Loading previous configuration from /home/fan/edk2/Conf/BuildEnv.sh
> WORKSPACE: /home/fan/edk2
> EDK_TOOLS_PATH: /home/fan/edk2/BaseTools
> CONF_PATH: /home/fan/edk2/Conf
> 
> ERROR!!!, python version should greater than or equal to version 3.6.
> 
> Does edk2 still support python 2? How can we make edk2 with python 2? Or we 
> must update the python version to python 3.6?

[edk2] [Patch] BaseTools Python: Migrate Python27 to Python36
B9726D6DCCFB8B4CA276A9169B02216D52123AAB@SHSMSX103.ccr.corp.intel.com">http://mid.mail-archive.com/B9726D6DCCFB8B4CA276A9169B02216D52123AAB@SHSMSX103.ccr.corp.intel.com

[edk2] BaseTools/ build broken due to unreviewed patch - PLEASE FIX
https://lists.01.org/pipermail/edk2-devel/2018-October/030723.html
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 3/6] MdeModulePkg: Map persistent (NV) memory

[Laszlo Ersek]

(+Grant)

On 10/12/18 16:40, Sami Mujawar wrote:
> Some platforms are able to preserve a memory range across
> system resets. This memory can be used for the Non-Volatile
> variables storage. The PcdEmuVariableNvStoreReserved is
> used to specify this option.

This is the wrong approach, for two reasons.

(1) At a technical level, suck hacks are usually implemented by provding
a platform-specific FVB (firmware volume block) protocol / driver,
underneath the normal FTW and Variable drivers. The FVB implementation
can (technically) fake a "persistent" flash device in RAM that is
actually volatile.

(2) At a design level, this is an extremely bad idea though. Such
variables are only halfway non-volatile, and that fact always comes back
to bite users, sooner or later. I speak from experience with OVMF, but
more recently, there has been discussion on the USWG list too, about
platforms that can only fake non-volatility. I can't provide more
details on this open list about that, so I'll just give you a
Message-Id, and a Mantis ticket.



https://mantis.uefi.org/mantis/view.php?id=1961

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

Re: [edk2] TianoCore Community Meeting Minutes

[Laszlo Ersek]

On 10/12/18 15:27, Leif Lindholm wrote:
> On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano wrote:

>> Switching to Standard C Types
>> -
>> Both Shawn and Nate mentioned that the current system has been in place for
>> a long time and some people prefer the current setup. I can start an email
>> discussion around this issue specifically if anyone feels strongly that we
>> should be using standard types.
> 
> So, I don't think we made it this far down the agenda on the US-EU
> call.
> 
> One way would be to simply explicitly permit it, possibly with the
> constraint that every module needs to pick one and stick with it,
> unless people object.
> 
> I think we'll want to discuss this in a US-EU call as well.

I'm playing devil's advocate here -- because, in general, I'm a fan of
sticking with standard C as much as possible --, but I see a big
obstacle in the way.

That obstacle is "Table 5. Common UEFI Data Types", in the UEFI spec.
Until a good portion of that table is expressed in terms of standard C
types as well (expanding upon the current definitions), possibly in an
edk2-level spec (i.e. not necessarily in the UEFI spec itself), I think
there's no chance to enable standard C types in edk2 *meaningfully*.

Because, as soon as you have to call a PI or UEFI interface, you'll have
to stick with the PI/UEFI spec types anyway.


>> Using Git Submodules (like we do with OpenSSL)
>> 
> 
> We didn't make it here either. What would we use it _for_?
> I think the openssl case makes a lot of sense, but what else?

We embed a bunch of other projects (libraries, mainly):
- Oniguruma
- Brotli
- fdt
- LZMA SDK
- ...

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

Re: [edk2] [PATCH edk2-platforms v5 21/28] Platform/Hisilicon/D06: Add PciHostBridgeLib

[Laszlo Ersek]

On 10/12/18 09:29, Ard Biesheuvel wrote:
> Hello all,
>
> While grepping through the code in edk2-platforms, I noticed an issue
> with this commit. Apologies for not spotting it earlier.
>
> On 31 August 2018 at 15:27, Ming Huang  wrote:
>> PciHostBridgeLib which is need by PciHostBridgeDxe, provide
>> root bridges and deal with resource conflict.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> Reviewed-by: Leif Lindholm 
>> ---
>>  Platform/Hisilicon/D06/D06.dsc   |   2 
>> +-
>>  Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  36 
>> ++
>>  Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 635 
>> 
>>  3 files changed, 672 insertions(+), 1 deletion(-)
>>
>> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
>> index 2659cb7e37..83dcbab6c4 100644
>> --- a/Platform/Hisilicon/D06/D06.dsc
>> +++ b/Platform/Hisilicon/D06/D06.dsc
>> @@ -419,7 +419,7 @@
>>  
>>
>> PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
>>PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
>> -  
>> PciHostBridgeLib|MdeModulePkg/Library/PciHostBridgeLibNull/PciHostBridgeLibNull.inf
>> +  
>> PciHostBridgeLib|Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>>}
>>
>>MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
>> diff --git 
>> a/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.inf 
>> b/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>> new file mode 100644
>> index 00..8a998681a3
>> --- /dev/null
>> +++ b/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>> @@ -0,0 +1,36 @@
>> +## @file
>> +#
>> +#  Copyright (c) 2018, Hisilicon Limited. All rights reserved.
>> +#  Copyright (c) 2018, Linaro Limited. All rights reserved.
>> +#
>> +#  This program and the accompanying materials
>> +#  are licensed and made available under the terms and conditions of the 
>> BSD License
>> +#  which accompanies this distribution. The full text of the license may be 
>> found at
>> +#  http://opensource.org/licenses/bsd-license.php
>> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> +#
>> +#
>> +##
>> +
>> +[Defines]
>> +  INF_VERSION= 0x0001001A
>> +  BASE_NAME  = PciHostBridgeLib
>> +  FILE_GUID  = 61b7276a-fc67-11e5-82fd-47ea9896dd5d
>> +  MODULE_TYPE= DXE_DRIVER
>> +  VERSION_STRING = 1.0
>> +  LIBRARY_CLASS  = PciHostBridgeLib|DXE_DRIVER
>> +
>> +[Sources]
>> +  PciHostBridgeLib.c
>> +
>> +[Packages]
>> +  MdeModulePkg/MdeModulePkg.dec
>> +  MdePkg/MdePkg.dec
>> +
>> +[LibraryClasses]
>> +  BaseLib
>> +  DebugLib
>> +  DevicePathLib
>> +  MemoryAllocationLib
>> +  UefiBootServicesTableLib
>> diff --git 
>> a/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.c 
>> b/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.c
>> new file mode 100644
>> index 00..d1a436d9bc
>> --- /dev/null
>> +++ b/Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.c
>> @@ -0,0 +1,635 @@
>> +/** @file
>> +
>> +  Copyright (c) 2018, Hisilicon Limited. All rights reserved.
>> +  Copyright (c) 2018, Linaro Limited. All rights reserved.
>> +
>> +  This program and the accompanying materials
>> +  are licensed and made available under the terms and conditions of the BSD 
>> License
>> +  which accompanies this distribution.  The full text of the license may be 
>> found at
>> +  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> +
>> +**/
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define ENUM_HB_NUM 8
>> +
>> +#define EFI_PCI_SUPPORT   (EFI_PCI_ATTRIBUTE_ISA_MOTHERBOARD_IO | \
>> +   EFI_PCI_ATTRIBUTE_IDE_SECONDARY_IO | \
>> +   EFI_PCI_ATTRIBUTE_IDE_PRIMARY_IO | \
>> +   EFI_PCI_ATTRIBUTE_ISA_IO_16  | \
>> +   EFI_PCI_ATTRIBUTE_VGA_MEMORY | \
>> +   EFI_PCI_ATTRIBUTE_VGA_IO_16  | \
>> +   EFI_PCI_ATTRIBUTE_VGA_PALETTE_IO_16)
>> +
>> +#define EFI_PCI_ATTRIBUTE  EFI_PCI_SUPPORT
>> +
>> +#pragma pack(1)
>> +typedef struct {
>> +  ACPI_HID_DEVICE_PATH AcpiDevicePath;
>> +  EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
>> +} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
>> +#pragma pack ()
>> +
>> +STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath 
>> [ENUM_HB_NUM] = {
>> +//Host Bridge 0
>> +  {
>> +{

Re: [edk2] [Patch v5] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/11/18 09:05, Eric Dong wrote:
> V5:
> 1. Add ASSERT to indicate this assumption that environment is 32 bit mode.
> 2. Add description in INF about this driver's expected result
>in different environment.
>
> V4:
> Only disable paging when it is enabled.
>
> V3 changes:
> No need to change inf file.
>
> V2 changes:
> Only disable paging in 32 bit mode, no matter it is enable or not.
>
> V1 changes:
> PEI Stack Guard needs to enable paging. This might cause #GP if code
> trying to write CR3 register with PML4 page table while the processor
> is enabled with PAE paging.
>
> Simply disabling paging before updating CR3 can solve this conflict.
>
> It's an regression caused by change: 0a0d5296e448fc350de1594c49b9c0deff7fad60
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1232
>
> Cc: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Cc: Jian J Wang 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 17 
> +
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 10 ++
>  2 files changed, 27 insertions(+)
>
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index f164c1713b..8415ab1583 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -964,6 +964,7 @@ S3RestoreConfig2 (
>VOID  *GuidHob;
>BOOLEAN   Build4GPageTableOnly;
>BOOLEAN   InterruptStatus;
> +  IA32_CR0  CR0Reg;
>
>TempAcpiS3Context = 0;
>TempEfiBootScriptExecutorVariable = 0;
> @@ -1045,6 +1046,13 @@ S3RestoreConfig2 (
>//
>GuidHob = GetFirstGuidHob ();
>if (GuidHob != NULL) {
> +//
> +// Below SwitchStack/AsmEnablePaging64 function has

(1) please strip the trailing space character here

> +// assumption that it's in 32 bits mode now.
> +// Add ASSERT code to indicate this assumption.
> +//
> +ASSERT(sizeof (UINTN) == sizeof (UINT32));
> +
>  Status = PeiServicesLocatePpi (
>,
>0,
> @@ -1105,6 +1113,15 @@ S3RestoreConfig2 (
>//
>SetInterruptState (InterruptStatus);
>
> +  CR0Reg.UintN = AsmReadCr0 ();
> +  if (CR0Reg.Bits.PG != 0) {
> +//
> +// We're in 32-bit mode, with paging enabled. We can't set CR3 to
> +// the 64-bit page tables without first disabling paging.
> +//
> +CR0Reg.Bits.PG = 0;
> +AsmWriteCr0 (CR0Reg.UintN);
> +  }
>AsmWriteCr3 ((UINTN)SmmS3ResumeState->SmmS3Cr3);
>
>//
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> index 6ce1bf944c..1d0740526f 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> @@ -33,6 +33,16 @@
>  #  VALID_ARCHITECTURES   = IA32 X64
>  #
>
> +#
> +# This module is not always workable in IA32 and X64 mode. It has below 
> result:

(2) please strip the trailing space character here


> +# when it works with SMM mode:
> +# =======
> +#   SMM:used  SMM:unused
> +# PEI:IA32   works  works
> +# PEI:X64fails  works
> +# ===
> +#
> +
>  [Sources]
>S3Resume.c
>
>

With the whitespace changes above (no need to repost just because of
them):

Reviewed-by: Laszlo Ersek 

I also regression-tested this patch on top of commit 8122c6bc8b6f, with
OVMF, in the following configurations:

- IA32,SMM,S3 enabled:  boot & suspend/resume PASS
- IA32X64, SMM,S3 enabled:  boot & suspend/resume PASS
- X64, SMM,S3 enabled:  boot failure, due to S3Verification().
This is by design, see commit
5133d1f1d297. Therefore this test case
is also PASS.
- X64, SMM,S3 disabled: boot PASS
- IA32,no SMM, S3 enabled:  boot & suspend/resume PASS
- IA32X64, no SMM, S3 enabled:  boot & suspend/resume PASS
- X64, no SMM, S3 enabled:  boot & suspend/resume PASS

Regression-tested-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v5] MdeModulePkg/RegularExpressionDxe:disable wraning to pass gcc4.8 build

[Laszlo Ersek]

On 10/10/18 09:39, Dongao Guo wrote:
> There are three warnings reported by GCC 4.8 and the later GCC release
> are workaround with them.
> And all the three warnings are invalid,so I just disable warnings rather
> than fix them at now.
> 
> Following is the analysis from Laszlo Ersek.
> (1)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c: In
>> function 'compile_length_tree':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c:1516:7:
>> warning: 'len' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>int len;
>>^
> 
> I think this is an invalid warning; the type of the controlling expression
> (node->type) is enum GimmickType, and the case labels cover all values of
> the enum. An assert(0) could be added, I guess, but again, upstream
> Oniguruma would be justified to reject the idea.
> 
> (2)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
>> function 'parse_callout_args.isra.10.constprop.30':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6753:25:
>> warning: 'rl' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>   vals[n].l = rl;
>>   ^
> 
> This warning is invalid, given:
> 
>   6749if (cn > 0) {
>   6750  long rl;
>   6751  r = parse_long(enc, buf, bufend, 1, LONG_MAX, );
>   6752  if (r == ONIG_NORMAL) {
>   6753vals[n].l = rl;
> 
> Because parse_long() only returns ONIG_NORMAL after it sets (*rl).
> 
> (3)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
>> function 'parse_callout_of_name.constprop.29':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6861:38:
>> warning: 'tag_end' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
> 
> This warning is also invalid, given:
> 
>   6852if (c == '[') {
>   6853  if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
>   6854  tag_start = p;
>   6855  while (! PEND) {
>   6856if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
>   6857tag_end = p;
>   6858PFETCH_S(c);
>   6859if (c == ']') break;
>   6860  }
>   6861  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
>   6862return ONIGERR_INVALID_CALLOUT_TAG_NAME;
>   6863
> 
> To see that, first we should note:
>  #define PEND (p < end ?  0 : 1)
> 
> therefore PEND doesn't change if neither "p" nor "end" change.
> 
> Second, when we reach line 6855 (the "while") for the very first time,
> (!PEND) is certainly true (i.e., PEND is false), because otherwise we
> would have bailed at line 6853. Therefore we reach line 6857, and assign
> "tag_end". Regardless of whether we iterate zero or more *additional*
> times around the loop, "tag_end" will have been set, whenever we reach
> line 6861.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dongao Guo 
> ---
>  MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> index 16e91bd..07bc02e 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> @@ -109,3 +109,6 @@
>  
># Oniguruma: error: variable 'fp' set but not used
>GCC:*_*_*_CC_FLAGS = -Wno-error=unused-but-set-variable
> +
> +  # Oniguruma: tag_end in parse_callout_of_name
> +  GCC:*_*_*_CC_FLAGS = -Wno-error=maybe-uninitialized
> 

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

Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/10/18 15:30, Yao, Jiewen wrote:
> OK. I forget that OVMF uses a different lock box implementation.
> 
> If so, how about below:
> ==
>   GuidHob = GetFirstGuidHob ();
>   if (GuidHob != NULL) {
> +ASSERT(sizeof(UINTN) == sizeof(UINT32));
> ==

Looks good!

> 
> I also think we need add your table to INF.
> ==
>  SMM:used  SMM:unused
> PEI:IA32  works  works
> PEI:X64   fails   works
> ==

Ditto. :)

Thanks!
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, October 10, 2018 9:19 PM
>> To: Yao, Jiewen ; Dong, Eric ;
>> edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu 
>> Subject: Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging
>> before creating new page table.
>>
>> On 10/10/18 15:14, Yao, Jiewen wrote:
>>> Good idea, Laszlo.
>>>
>>> If we know something will fail, we had better make it fail as early as
>> possible, and as obvious as possible.
>>>
>>> I think we can do sth in INF:
>>> 1) Change #  VALID_ARCHITECTURES   = IA32
>>> 2) Change:
>>> [Sources.IA32]
>>>   S3Resume.c
>>> and remove [Sources.X64]
>>>
>>>
>>> If we decide to enable X64 S3Resume, we can go back and add such
>> support.
>>
>> This would be a bit heavy-handed however, as S3Resume2Pei works fine
>> with X64 PEI, but only without SMM.
>>
>> There are four cases:
>>
>>   SMM:used  SMM:unused
>> PEI:IA32  works works
>> PEI:X64   fails works
>>
>> Only the X64+SMM case fails.
>>
>> Thanks
>> Laszlo
>>
>>
>>>> -Original Message-
>>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>>> Sent: Wednesday, October 10, 2018 9:04 PM
>>>> To: Yao, Jiewen ; Dong, Eric
>> ;
>>>> edk2-devel@lists.01.org
>>>> Cc: Ni, Ruiyu 
>>>> Subject: Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging
>>>> before creating new page table.
>>>>
>>>> On 10/10/18 09:58, Yao, Jiewen wrote:
>>>>> Hey
>>>>> I do not think we need add if (sizeof (UINTN) == sizeof (UINT32))
>>>>>
>>>>> This piece of code assume PEI is 32 bit.
>>>>> The following code AsmEnablePaging64() does not work for X64.
>>>>
>>>> I don't feel strongly about this particular question. Any decent
>>>> compiler will optimize away the UINTN size check, and IIRC Ray
>> suggested
>>>> under v1 to explicitly restrict the new code to 32-bit. (Although, we
>>>> both confirmed that this PEIM only supported 32-bit PEI with SMM.)
>>>>
>>>> Now, if the code is *clearly* restricted to 32-bit already -- do we
>>>> *declare* that fact somewhere? in the code or in the INF file? --, then
>>>> I agree we might not need the UINTN size check.
>>>>
>>>> ... Maybe we should split this driver into [Sources.IA32] and
>>>> [Sources.X64] more extensively that we currently do, and make the
>>>> X64+SMM case fail more *obviously* than it currently does.
>>>>
>>>> I'll leave it up to you guys to decide if the UINTN size check should be
>>>> preserved in this patch. Once you have an agreement, I'd like to
>>>> regression-test the resultant version of the patch.
>>>>
>>>> FWIW, this version (v4) does look good to me. Should Jiewen think the
>>>> UINTN size check is acceptable after all, I'd be ready to give my R-b
>>>> (and to regression-test the patch as well).
>>>>
>>>> Thanks!
>>>> Laszlo
>>>>
>>>>>
>>>>> Thank you
>>>>> Yao Jiewen
>>>>>
>>>>>> -Original Message-
>>>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of
>>>>>> Eric Dong
>>>>>> Sent: Wednesday, October 10, 2018 3:44 PM
>>>>>> To: edk2-devel@lists.01.org
>>>>>> Cc: Ni, Ruiyu ; Laszlo Ersek 
>>>>>> Subject: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging
>> before
>>>>>> creating new page table.
>>>>>>
>>>>>> V4:
>>>>>> Only disable paging when it is enabled.
>>>>>>
>>>>>&g

Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/10/18 15:14, Yao, Jiewen wrote:
> Good idea, Laszlo.
> 
> If we know something will fail, we had better make it fail as early as 
> possible, and as obvious as possible.
> 
> I think we can do sth in INF:
> 1) Change #  VALID_ARCHITECTURES   = IA32
> 2) Change:
> [Sources.IA32]
>   S3Resume.c
> and remove [Sources.X64]
> 
> 
> If we decide to enable X64 S3Resume, we can go back and add such support.

This would be a bit heavy-handed however, as S3Resume2Pei works fine
with X64 PEI, but only without SMM.

There are four cases:

  SMM:used  SMM:unused
PEI:IA32  works works
PEI:X64   fails works

Only the X64+SMM case fails.

Thanks
Laszlo


>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, October 10, 2018 9:04 PM
>> To: Yao, Jiewen ; Dong, Eric ;
>> edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu 
>> Subject: Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging
>> before creating new page table.
>>
>> On 10/10/18 09:58, Yao, Jiewen wrote:
>>> Hey
>>> I do not think we need add if (sizeof (UINTN) == sizeof (UINT32))
>>>
>>> This piece of code assume PEI is 32 bit.
>>> The following code AsmEnablePaging64() does not work for X64.
>>
>> I don't feel strongly about this particular question. Any decent
>> compiler will optimize away the UINTN size check, and IIRC Ray suggested
>> under v1 to explicitly restrict the new code to 32-bit. (Although, we
>> both confirmed that this PEIM only supported 32-bit PEI with SMM.)
>>
>> Now, if the code is *clearly* restricted to 32-bit already -- do we
>> *declare* that fact somewhere? in the code or in the INF file? --, then
>> I agree we might not need the UINTN size check.
>>
>> ... Maybe we should split this driver into [Sources.IA32] and
>> [Sources.X64] more extensively that we currently do, and make the
>> X64+SMM case fail more *obviously* than it currently does.
>>
>> I'll leave it up to you guys to decide if the UINTN size check should be
>> preserved in this patch. Once you have an agreement, I'd like to
>> regression-test the resultant version of the patch.
>>
>> FWIW, this version (v4) does look good to me. Should Jiewen think the
>> UINTN size check is acceptable after all, I'd be ready to give my R-b
>> (and to regression-test the patch as well).
>>
>> Thanks!
>> Laszlo
>>
>>>
>>> Thank you
>>> Yao Jiewen
>>>
>>>> -Original Message-
>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>>> Eric Dong
>>>> Sent: Wednesday, October 10, 2018 3:44 PM
>>>> To: edk2-devel@lists.01.org
>>>> Cc: Ni, Ruiyu ; Laszlo Ersek 
>>>> Subject: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before
>>>> creating new page table.
>>>>
>>>> V4:
>>>> Only disable paging when it is enabled.
>>>>
>>>> V3 changes:
>>>> No need to change inf file.
>>>>
>>>> V2 changes:
>>>> Only disable paging in 32 bit mode, no matter it is enable or not.
>>>>
>>>> V1 changes:
>>>> PEI Stack Guard needs to enable paging. This might cause #GP if code
>>>> trying to write CR3 register with PML4 page table while the processor
>>>> is enabled with PAE paging.
>>>>
>>>> Simply disabling paging before updating CR3 can solve this conflict.
>>>>
>>>> It's an regression caused by change:
>>>> 0a0d5296e448fc350de1594c49b9c0deff7fad60
>>>>
>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1232
>>>>
>>>> Change-Id: I99bfdba5daa48a95a4c4ef97eeca1af086558957
>>>> Cc: Ruiyu Ni 
>>>> Cc: Laszlo Ersek 
>>>> Cc: Jian J Wang 
>>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>> Signed-off-by:Eric Dong 
>>>> Signed-off-by: Eric Dong 
>>>> ---
>>>>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 12
>> 
>>>>  1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>>> index f164c1713b..c059c42db5 100644
>>>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>>> @@ -964,6 +964,7 @@ S3RestoreConfig2 (
>>>

Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/10/18 09:58, Yao, Jiewen wrote:
> Hey
> I do not think we need add if (sizeof (UINTN) == sizeof (UINT32))
> 
> This piece of code assume PEI is 32 bit.
> The following code AsmEnablePaging64() does not work for X64.

I don't feel strongly about this particular question. Any decent
compiler will optimize away the UINTN size check, and IIRC Ray suggested
under v1 to explicitly restrict the new code to 32-bit. (Although, we
both confirmed that this PEIM only supported 32-bit PEI with SMM.)

Now, if the code is *clearly* restricted to 32-bit already -- do we
*declare* that fact somewhere? in the code or in the INF file? --, then
I agree we might not need the UINTN size check.

... Maybe we should split this driver into [Sources.IA32] and
[Sources.X64] more extensively that we currently do, and make the
X64+SMM case fail more *obviously* than it currently does.

I'll leave it up to you guys to decide if the UINTN size check should be
preserved in this patch. Once you have an agreement, I'd like to
regression-test the resultant version of the patch.

FWIW, this version (v4) does look good to me. Should Jiewen think the
UINTN size check is acceptable after all, I'd be ready to give my R-b
(and to regression-test the patch as well).

Thanks!
Laszlo

> 
> Thank you
> Yao Jiewen
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Eric Dong
>> Sent: Wednesday, October 10, 2018 3:44 PM
>> To: edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu ; Laszlo Ersek 
>> Subject: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before
>> creating new page table.
>>
>> V4:
>> Only disable paging when it is enabled.
>>
>> V3 changes:
>> No need to change inf file.
>>
>> V2 changes:
>> Only disable paging in 32 bit mode, no matter it is enable or not.
>>
>> V1 changes:
>> PEI Stack Guard needs to enable paging. This might cause #GP if code
>> trying to write CR3 register with PML4 page table while the processor
>> is enabled with PAE paging.
>>
>> Simply disabling paging before updating CR3 can solve this conflict.
>>
>> It's an regression caused by change:
>> 0a0d5296e448fc350de1594c49b9c0deff7fad60
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1232
>>
>> Change-Id: I99bfdba5daa48a95a4c4ef97eeca1af086558957
>> Cc: Ruiyu Ni 
>> Cc: Laszlo Ersek 
>> Cc: Jian J Wang 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by:Eric Dong 
>> Signed-off-by: Eric Dong 
>> ---
>>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> index f164c1713b..c059c42db5 100644
>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> @@ -964,6 +964,7 @@ S3RestoreConfig2 (
>>VOID  *GuidHob;
>>BOOLEAN
>> Build4GPageTableOnly;
>>BOOLEAN
>> InterruptStatus;
>> +  IA32_CR0  CR0Reg;
>>
>>TempAcpiS3Context = 0;
>>TempEfiBootScriptExecutorVariable = 0;
>> @@ -1105,6 +1106,17 @@ S3RestoreConfig2 (
>>//
>>SetInterruptState (InterruptStatus);
>>
>> +  if (sizeof (UINTN) == sizeof (UINT32)) {
>> +CR0Reg.UintN = AsmReadCr0 ();
>> +if (CR0Reg.Bits.PG != 0) {
>> +  //
>> +  // We're in 32-bit mode, with paging enabled. We can't set CR3
>> to
>> +  // the 64-bit page tables without first disabling paging.
>> +  //
>> +  CR0Reg.Bits.PG = 0;
>> +  AsmWriteCr0 (CR0Reg.UintN);
>> +}
>> +  }
>>AsmWriteCr3 ((UINTN)SmmS3ResumeState->SmmS3Cr3);
>>
>>//
>> --
>> 2.15.0.windows.1
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v4] MdeModulePkg/RegularExpressionDxe:disable wraning to pass gcc4.8 build

[Laszlo Ersek]

Hi Dongao,

On 10/10/18 04:42, Dongao Guo wrote:
> There are three warnings reported by GCC 4.8 and the later GCC release
> are workaround with them.
> And all the three warnings are invalid,so I just disable warnings rather
> than fix them at now.
> 
> Following is the analysis from Laszlo Ersek.
> (1)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c: In
>> function 'compile_length_tree':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c:1516:7:
>> warning: 'len' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>int len;
>>^
> 
> I think this is an invalid warning; the type of the controlling expression
> (node->type) is enum GimmickType, and the case labels cover all values of
> the enum. An assert(0) could be added, I guess, but again, upstream
> Oniguruma would be justified to reject the idea.
> 
> (2)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
>> function 'parse_callout_args.isra.10.constprop.30':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6753:25:
>> warning: 'rl' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>   vals[n].l = rl;
>>   ^
> 
> This warning is invalid, given:
> 
>   6749if (cn > 0) {
>   6750  long rl;
>   6751  r = parse_long(enc, buf, bufend, 1, LONG_MAX, );
>   6752  if (r == ONIG_NORMAL) {
>   6753vals[n].l = rl;
> 
> Because parse_long() only returns ONIG_NORMAL after it sets (*rl).
> 
> (3)
> 
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
>> function 'parse_callout_of_name.constprop.29':
>> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6861:38:
>> warning: 'tag_end' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
> 
> This warning is also invalid, given:
> 
>   6852if (c == '[') {
>   6853  if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
>   6854  tag_start = p;
>   6855  while (! PEND) {
>   6856if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
>   6857tag_end = p;
>   6858PFETCH_S(c);
>   6859if (c == ']') break;
>   6860  }
>   6861  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
>   6862return ONIGERR_INVALID_CALLOUT_TAG_NAME;
>   6863
> 
> To see that, first we should note:

(1) Here, my original email at
<e4131806-14d5-b11b-5b68-2c552fcadf0c@redhat.com">http://mid.mail-archive.com/e4131806-14d5-b11b-5b68-2c552fcadf0c@redhat.com>,
contained another line:

#define PEND (p < end ?  0 : 1)

This line is not part of your commit message, because "git commit"
considers all lines that start with "#" a comment, and they are removed
from the final commit message.

When quoting content that may contain such lines, it is usually best to
either indent the quote by a few space characters, or else prefix each
line with the string "> ", or something similar.

> 
> therefore PEND doesn't change if neither "p" nor "end" change.
> 
> Second, when we reach line 6855 (the "while") for the very first time,
> (!PEND) is certainly true (i.e., PEND is false), because otherwise we
> would have bailed at line 6853. Therefore we reach line 6857, and assign
> "tag_end". Regardless of whether we iterate zero or more *additional*
> times around the loop, "tag_end" will have been set, whenever we reach
> line 6861.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dongao Guo 
> ---
>  MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> index 16e91bd..07bc02e 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
> @@ -109,3 +109,6 @@
>  
># Oniguruma: error: variable 'fp' set but not used
>GCC:*_*_*_CC_FLAGS = -Wno-error=unused-but-set-variable
> +
> +  # Oniguruma: tag_end in parse_callout_of_name

(2) Based on the analysis now included in the commit message, I suggest:
- either dropping this comment (because it is incomplete),
- or including all three cases briefly.

> +  GCC:*_*_*_CC_FLAGS = -Wno-error=maybe-uninitialized
> 

In my opinion, (1) should be fixed, because otherwise the commit message
is confusing.

Regarding (2), I don't feel strongly, so if you disagree, I don't mind.

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

Re: [edk2] RuntimeDXE unable to save variables to flash

[Laszlo Ersek]

On 10/09/18 12:25, Hristo Mihaylov wrote:
> Thanks Laszlo,
> 
>> Accessing invalid MSRs may raise injections. How do you know the MSR 0x1FE 
>> is valid (and the Data32 value is valid)?
> 
> I'll investigate this further.
> 
>> That's an Fvb->Write() call. Do you have access to the source of the flash 
>> driver (which produces the FVB protocol instance)?
> 
> Yes, I found that the writing is done in a function called SendSpiCmd, here's 
> the signature (I can't disclose the full source).
> 
> ```
> /**
>   This function sends the programmed SPI command to the slave device.
> 
>   @param[in] This Pointer to the PCH_SPI_PROTOCOL instance.
>   @param[in] SpiRegionTypeThe SPI Region type for flash cycle which 
> is listed in the Descriptor
>   @param[in] FlashCycleType   The Flash SPI cycle type list in HSFC 
> (Hardware Sequencing Flash Control Register) register
>   @param[in] Address  The Flash Linear Address must fall within a 
> region for which BIOS has access permissions.
>   @param[in] ByteCountNumber of bytes in the data portion of the 
> SPI cycle.
>   @param[in,out] Buffer   Pointer to caller-allocated buffer 
> containing the dada received or sent during the SPI cycle.
> 
>   @retval EFI_SUCCESS SPI command completes successfully.
>   @retval EFI_DEVICE_ERRORDevice error, the command aborts abnormally.
>   @retval EFI_ACCESS_DENIED   Some unrecognized command encountered in 
> hardware sequencing mode
>   @retval EFI_INVALID_PARAMETER   The parameters specified are not valid.
> **/
> EFI_STATUS
> SendSpiCmd (
>   IN EFI_SPI_PROTOCOL   *This,
>   IN FLASH_REGION_TYPE  FlashRegionType,
>   IN FLASH_CYCLE_TYPE   FlashCycleType,
>   IN UINT32 Address,
>   IN UINT32 ByteCount,
>   IN OUT UINT8  *Buffer
>   )
> ```
> 
> It fails when it does a sanity check. It checks `if (Address + ByteCount) > 
> FlashRegionSize`. The FlashRegionSize 
> seems to be estimated correctly, because it's used to write other values to 
> that region, which succeed.
> 
> When I log the sanity check like for the incorrect value I see: `SendSpiCmd: 
> (46334052 + 60 = 46334112) > 20971520` 
> the address seems to be way off.
> 
> The Address is calculated in FvbGetLbaAddress. Almost a 1 to 1 copy of 
> https://github.com/tianocore/edk2/blob/75b7aa9528bdd05a7ecf4e64a6beb478d31b402c/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c#L237
> 
> I thought that the issue is either because of invalid FV block or the size of 
> the flash region is calculated
>  incorrectly, but this only happens in SMM. Now I'm leaning more towards 
> permissions.
> 
> Any advice?

Hmm, not much. Either the blockmap is wrong, as you suggest, or else the
Lba input param to FvbGetLbaAddress() is bogus, and FvbGetLbaAddress()
returns EFI_INVALID_PARAMETER, when it reaches the terminator blockmap
entry (without finding Lba).

Does the caller of FvbGetLbaAddress() check the return value?

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

Re: [edk2] [Patch] BaseTools LzmaCompress: Fix GCC warning misleading-indentation

[Laszlo Ersek]

On 10/09/18 10:24, Zeng, Star wrote:
> Reviewed-by: Star Zeng 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Tuesday, October 9, 2018 3:13 PM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch] BaseTools LzmaCompress: Fix GCC warning 
> misleading-indentation
> 
> On 9 October 2018 at 09:11, Gao, Liming  wrote:
>> This issue in LzmaEnc.c is for encode. The copy SDK in MdeModulePkg and 
>> IntelFrameworkModulepkg is for decode. So, other copy SDK has no this issue.
>>
> 
> I understand.
> 
> Thanks for the fix
> 
> Acked-by: Ard Biesheuvel 

In the commit message, I referenced
, which got
reported meanwhile.

Pushed as commit 50431b9cc70c.

Thanks
Laszlo

>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
>>> Biesheuvel
>>> Sent: Tuesday, October 9, 2018 3:08 PM
>>> To: Gao, Liming 
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] [Patch] BaseTools LzmaCompress: Fix GCC warning 
>>> misleading-indentation
>>>
>>> On 9 October 2018 at 09:06, Liming Gao  wrote:
 GCC 6 or above reports the warning misleading-indentation.
 This patch fixes it.

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Liming Gao 
 Cc: Ard Biesheuvel 
 ---
  BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
 b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
 index bebe664..e281716 100644
 --- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
 +++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
 @@ -1464,7 +1464,9 @@ static unsigned GetOptimum(CLzmaEnc *p, UInt32 
 position)
  unsigned limit = p->numFastBytes + 1;
  if (limit > numAvailFull)
limit = numAvailFull;
 -for (len = 3; len < limit && data[len] == data2[len]; len++);
 +for (len = 3; len < limit && data[len] == data2[len]; len++)
 +{
 +}

  {
unsigned state2 = kLiteralNextStates[state];
>>>
>>> Thanks Liming.
>>>
>>> Don't we need this change in all copies of the LZMA SDK?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage()

[Laszlo Ersek]

Hi,

On 10/09/18 11:07, Varun Kumar wrote:
> I need clarification on ImageUpdatable field in
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage(). ImageUpdatable is of 32
> bit wide

That seems to be the case, yes. (OUT UINT32 *).

> but ImageUpdatable Definitions for this field is of 64 bit wide.

That's not the case; the macros
- IMAGE_UPDATABLE_VALID,
- IMAGE_UPDATABLE_INVALID,
- IMAGE_UPDATABLE_INVALID_TYPE,
- IMAGE_UPDATABLE_INVALID_OLD,
- IMAGE_UPDATABLE_VALID_WITH_VENDOR_CODE
all have type INT32.

(Using the last one as an example, the integer constant
0x0010 has type INT32.)

I agree that the large number of leading zeroes is confusing. Please
consider filing a Mantis ticket for the UEFI spec, for cleaning those
up.

> I hope it's not defined intentionally if so, please clarify me on
> this. Please find the attached screenshot for reference.

Two comments on the screenshot:

- Currently the edk2-devel list strips attachments (most types, if not
  all). That's a bug, but it's very hard to fix. Either way, the image
  you may have attached hasn't reached the list.

- Sending a screenshot (I assume: from the UEFI spec) is not a bad idea
  (assuming you use a lossless compression format, like PNG). It can be
  improved further if you also provide textual pointers, such as: spec
  release (e.g. "2.7"), and page number or section number.

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

Re: [edk2] [Patch v3] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/09/18 10:59, Ni, Ruiyu wrote:
> On 10/9/2018 4:25 PM, Laszlo Ersek wrote:

>> - for clarity, please use ~(UINTN)BIT31 as mask (even though it makes no
>>    practical difference).
> Actually we could use IA32_CR0 structure to avoid BIT31 usage.

That's a great idea.

I wish I had known about IA32_CR0 (and IA32_CR4) earlier! Now we have a
bunch of ad-hoc bitmask macros around the tree, e.g. CR0_WP, CR0_PG,
CR4_PSE, CR4_PAE in "UefiCpuPkg/CpuDxe/CpuPageTable.c".

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

Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/09/18 10:26, Ni, Ruiyu wrote:
> On 10/9/2018 4:09 PM, Laszlo Ersek wrote:
>>>
>>> Two comments:
>>> 1. We'd better not map the PcdCpuStackGuard to paging-enable. Maybe some
>>> other feature also enables the paging in PEI phase but the
>>> PcdCpuStackGuard is FALSE.
>>
>> I think I agree.
>>
>>> 2. When PEI is in 64bit mode, disabling paging may not work because
>>> paging-enable is a must in 64bit mode.
>>
>> I think this case is academic. S3Resume2Pei does not support 64-bit PEI
>> with SMM enabled. This is why we have commit 5133d1f1d297 ("OvmfPkg:
>> replace README fine print about X64 SMM S3 with PlatformPei check",
>> 2015-11-30) in OVMF.
> 
> I found that commit. I just checked S3Resume2Pei module. It does assumes
> it's running in 32bit mode. And CpuS3.c also assumes S3Resume2Pei is
> running in 32bit mode.
> 
>>
>> Anyway, I'm making this comment in the general sense only. I'm not
>> suggesting that we disable paging unconditionally. Actually, I believe,
>> I will suggest (under the v3 posting) restricting the write to CR0 even
>> more.
> Why?

I explained under v3.

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

Re: [edk2] [Patch v3] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/09/18 08:01, Eric Dong wrote:
> V3 changes:
> No need to change inf file. Also update commit message to include regression 
> info.
> 
> V2 changes:
> Only disable paging in 32 bit mode, no matter it is enable or not.
> 
> V1 changes:
> PEI Stack Guard needs to enable paging. This might cause #GP if code
> trying to write CR3 register with PML4 page table while the processor
> is enabled with PAE paging.
> 
> Simply disabling paging before updating CR3 can solve this conflict.
> 
> It's an regression caused by change: 0a0d5296e448fc350de1594c49b9c0deff7fad60
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1232
> 
> Cc: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Cc: Jian J Wang 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by:Eric Dong 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index f164c1713b..53ed76c6e6 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -1105,6 +1105,14 @@ S3RestoreConfig2 (
>//
>SetInterruptState (InterruptStatus);
>  
> +  if (sizeof(UINTN) == sizeof(UINT32)) {

I think we usually insert a space character after the "sizeof" operator
in such cases.

> +//
> +// Paging maybe enabled. If current mode is 32 bit mode and code try 
> to
> +// enable 64 bit mode page table, it will cause GP fault.
> +// To avoid conflict configuration, disable paging first anyway.
> +//
> +AsmWriteCr0 (AsmReadCr0 () & (~BIT31));

The bit-manipulation is valid, but only because this code is restricted
to 32-bit mode, where UINTN is UINT32. For clarity, I think
~(UINTN)BIT31 would be better. (The AsmWriteCr0() and AsmReadCr0()
BaseLib functions work with UINTN, but the type of BIT31 is UINT32.)

> +  }
>AsmWriteCr3 ((UINTN)SmmS3ResumeState->SmmS3Cr3);
>  
>//
> 

So, my main point:

Would it make sense to avoid a write to CR0 if paging is disabled? Such as:

  UINTN Cr0;

  if (sizeof (UINTN) == sizeof (UINT32)) {
Cr0 = AsmReadCr0 ();
if ((Cr0 & BIT31) != 0) {
  //
  // We're in 32-bit mode, with paging enabled. We can't set CR3 to
  // the 64-bit page tables without first disabling paging.
  //
  Cr0 &= ~(UINTN)BIT31;
  AsmWriteCr0 (Cr0);
}
  }

I haven't tested this patch yet, it's just that I'm generally concerned
about CR *writes* under KVM that aren't absolutely necessary. OVMF does
not enable the PEI Stack Guard, so in practice, disabling paging is not
necessary (because it is never enabled anyway, for now). Therefore I
would like to save the CR0 write, in the IA32X64 build of OVMF.

Of course, I don't insist on the exact code example that I wrote above;
it's just illustration.

In summary, I suggest:

- please consider making the CR0 write conditional on *both* being in
  32-bit mode *and* BIT31 being set in CR0,

- for clarity, please use ~(UINTN)BIT31 as mask (even though it makes no
  practical difference).

What do you think?

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

Re: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.

[Laszlo Ersek]

On 10/09/18 04:15, Ni, Ruiyu wrote:
> On 10/9/2018 10:05 AM, Dong, Eric wrote:
>> Add BZ link for this issue:
>> https://bugzilla.tianocore.org/show_bug.cgi?id=1232
>>
>> Thanks,
>> Eric
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Eric Dong
>>> Sent: Tuesday, October 9, 2018 9:51 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Ni, Ruiyu ; Laszlo Ersek 
>>> Subject: [edk2] [Patch] UefiCpuPkg/S3Resume2Pei: disable paging before
>>> creating new page table.
>>>
>>> PEI Stack Guard needs to enable paging. This might cause #GP in the
>>> transition from 32-bit PEI to 64-bit SMM due to the code trying to
>>> write CR3
>>> register with PML4 page table while the processor is enabled with PAE
>>> paging.
>>>
>>> Simply disabling paging before updating CR3 can solve this conflict.
>>>
>>> Change-Id: I99bfdba5daa48a95a4c4ef97eeca1af086558957
>>> Cc: Ruiyu Ni 
>>> Cc: Laszlo Ersek 
>>> Cc: Jian J Wang 
>>> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-
>>> by:Eric Dong 
>>> Signed-off-by: Eric Dong 
>>> ---
>>>   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 7 +++
>>>   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 1 +
>>>   2 files changed, 8 insertions(+)
>>>
>>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> index f164c1713b..b3bf56e13d 100644
>>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> @@ -1105,6 +1105,13 @@ S3RestoreConfig2 (
>>>     //
>>>     SetInterruptState (InterruptStatus);
>>>
>>> +  if (PcdGetBool (PcdCpuStackGuard)) {
>>> +    //
>>> +    // Paging already been enabled, to avoid conflict
>>> configuration,
>>> +    // disable paging first anyway.
>>> +    //
>>> +    AsmWriteCr0 (AsmReadCr0 () & (~BIT31));
>>> +  }
> 
> Two comments:
> 1. We'd better not map the PcdCpuStackGuard to paging-enable. Maybe some
> other feature also enables the paging in PEI phase but the
> PcdCpuStackGuard is FALSE.

I think I agree.

> 2. When PEI is in 64bit mode, disabling paging may not work because
> paging-enable is a must in 64bit mode.

I think this case is academic. S3Resume2Pei does not support 64-bit PEI
with SMM enabled. This is why we have commit 5133d1f1d297 ("OvmfPkg:
replace README fine print about X64 SMM S3 with PlatformPei check",
2015-11-30) in OVMF.

Anyway, I'm making this comment in the general sense only. I'm not
suggesting that we disable paging unconditionally. Actually, I believe,
I will suggest (under the v3 posting) restricting the write to CR0 even
more.

Thanks!
Laszlo

> 
>>>     AsmWriteCr3 ((UINTN)SmmS3ResumeState->SmmS3Cr3);
>>>
>>>     //
>>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>>> index 6ce1bf944c..0f131d19df 100644
>>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>>> @@ -90,6 +90,7 @@
>>>   [Pcd]
>>>     gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ##
>>> SOMETIMES_CONSUMES
>>>
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrM
>>> ask    ## CONSUMES
>>> + 
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ##
>>> CONSUMES
>>>
>>>   [Depex]
>>>     TRUE
>>> -- 
>>> 2.15.0.windows.1
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 

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

Re: [edk2] [PATCH] MdePkg-BaseLib: Fix PathCleanUpDirectories() error involving "\..\.."

[Laszlo Ersek]

(meta)

On 10/08/18 17:26, jim.dai...@dell.com wrote:
> Resending, as I never saw this email on the mailing list.

I did -- here's a link to the original in one of the archives too:

c8ccaad1befc4db4bcd3f835930c2508@ausx13mps335.AMER.DELL.COM">http://mid.mail-archive.com/c8ccaad1befc4db4bcd3f835930c2508@ausx13mps335.AMER.DELL.COM

(You were right to re-send, just confirming.)

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

Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure convention for checkbox

[Laszlo Ersek]

On 10/08/18 16:32, Bi, Dandan wrote:
> Hi Laszlo,
> 
>> -Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, October 08, 2018 8:19 PM
>> To: Bi, Dandan ; edk2-devel@lists.01.org
>> Cc: Zeng, Star ; Gao, Liming 
>> Subject: Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure
>> convention for checkbox
>>
>> Hi Dandan,
>>
>> On 10/08/18 03:29, Dandan Bi wrote:
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1224
>>>
>>> When covert IFR binary to EFI_IFR_CHECKBOX structure, Current code has
>>> following incorrect code logic:
>>> IfrCheckBox = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1); The correct one
>>> should be:
>>> IfrCheckBox = (EFI_IFR_CHECKBOX *) IfrOpHdr;
>>>
>>> This patch is to fix this bug.
>>>
>>> Cc: Liming Gao 
>>> Cc: Star Zeng 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Dandan Bi 
>>> ---
>>>  MdeModulePkg/Universal/HiiDatabaseDxe/Database.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
>>> b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
>>> index 45448c5198..664687796f 100644
>>> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
>>> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
>>> @@ -896,11 +896,11 @@ UpdateDefaultSettingInFormPackage (
>>>break;
>>>  case EFI_IFR_CHECKBOX_OP:
>>>IfrScope = IfrOpHdr->Scope;
>>>IfrQuestionType  = IfrOpHdr->OpCode;
>>>IfrQuestionHdr   = (EFI_IFR_QUESTION_HEADER *) (IfrOpHdr + 1);
>>> -  IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);
>>> +  IfrCheckBox  = (EFI_IFR_CHECKBOX *) IfrOpHdr;
>>>EfiVarStoreIndex = IsEfiVarStoreQuestion (IfrQuestionHdr,
>> EfiVarStoreList, EfiVarStoreNumber);
>>>Width= sizeof (BOOLEAN);
>>>if (EfiVarStoreIndex < EfiVarStoreNumber) {
>>>  for (Index = 0; Index < DefaultIdNumber; Index ++) {
>>>if (DefaultIdList[Index] == EFI_HII_DEFAULT_CLASS_STANDARD)
>>> {
>>>
>>
>> what were the practical consequences (symptoms) of this issue? Did some
>> checkboxes not work? (I'm asking because SecureBootConfigDxe uses some
>> checkboxes.)
> 
> 1.  The bug is in function "UpdateDefaultSettingInFormPackage()" which is to 
> update the default setting of some HII Questions in the IFR binary data. So 
> it only has impact when platform overrides default setting in HII VarStore 
> through DynamicHii PCD setting in Platform DSC file. If platform doesn't 
> override default setting, it has no impact.
> 
> 2. The implementation updates the "Flags" filed in the EFI_IFR_CHECKBOX 
> structure to update the default setting of checkbox.
> If using "IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);" when wants 
> to update the " Flags" filed in checkbox, but in fact it will update the 
> opcode binary data(opcode binary length) behind checkbox binary. 
> And then it will cause Browser can't parse the IFR binary data correctly. And 
> then the possible symptom is that some HII Question and forms may be not 
> parsed and then cannot be shown.

Thanks! I've copied this into the BZ.

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

Re: [edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

[Laszlo Ersek]

On 09/30/18 00:23, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: inline_asm_rw_ops_1208
> 
> This series mainly fixes the operand constraints (missing input-output
> qualifications) in "BaseSynchronizationLib/*/GccInline.c".
> 
> (It would be better to remove these files altogether in favor of the
> already existing NASM implementation, but due to
> <https://bugzilla.tianocore.org/show_bug.cgi?id=881>, we can't generally
> do that in libraries yet.)
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (5):
>   MdePkg/BaseSynchronizationLib GCC: fix whitespace and comments
>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange16()
>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange32()
>   MdePkg/BaseSynchronizationLib GCC: fix X64
> InternalSyncCompareExchange64()
>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
> InternalSyncCompareExchange64()
> 
>  MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 +++--
>  MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 47 
> +++-
>  2 files changed, 34 insertions(+), 55 deletions(-)
> 

Ping :)

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

Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure convention for checkbox

[Laszlo Ersek]

Hi Dandan,

On 10/08/18 03:29, Dandan Bi wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1224
> 
> When covert IFR binary to EFI_IFR_CHECKBOX structure,
> Current code has following incorrect code logic:
> IfrCheckBox = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);
> The correct one should be:
> IfrCheckBox = (EFI_IFR_CHECKBOX *) IfrOpHdr;
> 
> This patch is to fix this bug.
> 
> Cc: Liming Gao 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Universal/HiiDatabaseDxe/Database.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c 
> b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> index 45448c5198..664687796f 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> @@ -896,11 +896,11 @@ UpdateDefaultSettingInFormPackage (
>break;
>  case EFI_IFR_CHECKBOX_OP:
>IfrScope = IfrOpHdr->Scope;
>IfrQuestionType  = IfrOpHdr->OpCode;
>IfrQuestionHdr   = (EFI_IFR_QUESTION_HEADER *) (IfrOpHdr + 1);
> -  IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);
> +  IfrCheckBox  = (EFI_IFR_CHECKBOX *) IfrOpHdr;
>EfiVarStoreIndex = IsEfiVarStoreQuestion (IfrQuestionHdr, 
> EfiVarStoreList, EfiVarStoreNumber);
>Width= sizeof (BOOLEAN);
>if (EfiVarStoreIndex < EfiVarStoreNumber) {
>  for (Index = 0; Index < DefaultIdNumber; Index ++) {
>if (DefaultIdList[Index] == EFI_HII_DEFAULT_CLASS_STANDARD) {
> 

what were the practical consequences (symptoms) of this issue? Did some
checkboxes not work? (I'm asking because SecureBootConfigDxe uses some
checkboxes.)

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

Re: [edk2] [RFC MdeModulePkg/UefiBootManagerLib v1 1/1] MdeModulePkg/UefiBootManagerLib: Fix raid card repair fail issue

[Laszlo Ersek]

On 10/08/18 08:39, Ni, Ruiyu wrote:
> On 9/28/2018 2:18 PM, Ming Huang wrote:
>>
>>
>> On 9/26/2018 1:00 PM, Ni, Ruiyu wrote:
 @@ -507,12 +552,13 @@ BmRepairAllControllers (
  FormBrowser2,
  [Index],
  1,
 -   PcdGetPtr
 (PcdDriverHealthConfigureForm),
 +   ,
>>>
>>> I still don't quite understand the changes.
>>> But the above specific change removes the
>>> PcdDriverHealthConfigureForm form pop up.
>>> Instead it pops up each driver health form one by one.
>>> Why?
>>
>> This change is refer to the below function:
>> ProcessSingleControllerHealth
>> (IntelFrameworkModulePkg/Universal/Bdsdxe/DeviceMngr/DeviceManager.c).
>> I don't real understand it also, but it works.
>>
> 
> I am sorry. I cannot review the changes if you cannot explain it:)
> Fix should be based on the thoroughly understanding to the issue.

Could it be that the RAID card driver is buggy?

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

Re: [edk2] [PATCH v3 00/16] Removed unused PCDs

[Laszlo Ersek]

Hi Ray,

On 10/08/18 05:07, Ni, Ruiyu wrote:
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Tuesday, October 2, 2018 6:14 PM
>> To: Ni, Ruiyu ; Zhang, Chao B 
>> Cc: Zhang, Shenglei ; edk2-devel@lists.01.org;
>> Kinney, Michael D 
>> Subject: Re: [edk2] [PATCH v3 00/16] Removed unused PCDs
>>
>> Ray, Chao,
>>
>> guys, you keep breaking the development process. Please fix your email
>> clients *now*.
>>
>> This is not the first time it has happened. If I remember correctly, Ray 
>> blamed
>> his email client last time (not showing message threads correctly, or
>> something similar).
>>
>> I'm sorry, but this is unacceptable. This is on-going, systemic disregard 
>> for the
>> project's other participants.
>>
>> Please fix your mail user agents *now*.
>>
>> Here's my promise. Next time, I'm going to revert such commits (assuming I
>> manage to catch them again). They do not represent the facts from the
>> mailing list.
> 
> Sorry about that. I can understand it.
> So this is the first mail I choose to reply after a long holiday.
> I am now using Mozilla Thunderbird to only receive mails from this mailing 
> list.
> This mail client can group the mails correctly so if I missed any R-b that's 
> absolutely
> my fault
> 
> There is a difference between help-to-push for Intel developers and non-Intel 
> developers.
> As the Intel developer, Shenglei is very kind to prepare the patch files with 
> R-b and
> send to me internally as attachments. All I need to do is pushing the patches.
> Before the pushing, I will check whether there is R-b but won't check whether 
> all R-bs
> are there.
> 
> For non-Intel developers, I will edit the patch to list all R-bs before 
> pushing.
> 
> Again, thanks for enforcing the process. We will follow the process more 
> strictly in future.

Thank you for following up.

Traditionally, going through the review feedback, and picking up R-b /
T-b and similar tags, are the maintainer's task, involving a git-rebase
with "reword" operations, and the final push. I'm not sure how it helps
to split this work, for any given /single/ series, between multiple
people. To me it seems difficult to coordinate.

It definitely makes sense to distribute /multiple/ series over a pool of
maintainers. I think it's the sub-series granularity that is difficult.

In edk2's case, if I remember correctly, there have been some series
even that modified multiple Packages, and were finally pushed by a
single maintainer (after everything had been fully reviewed). That's a
good approach.

If I can help with pushing a patch set at any time (because it is fully
reviewed, but it's hard to find the time to wrangle the patches), please
ping me, on-list or off-list, as you prefer.

(We might also end up updating the workflow so that it become less
error-prone when not using the git command line.)

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

Re: [edk2] [patch 1/5] MdePkg: Correct the string expression of UTF8 vendor device path

[Laszlo Ersek]

Hi Dandan,

On 10/08/18 05:31, Dandan Bi wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1225
> 
> According to UEFI spec, the string expression of UTF8 vendor
> device node should be displayed as: VenUtf8(). Current code
> display it as: VenUft8() by mistake when convert device
> path node to text.
> 
> This commit is to fix this bug.
> 
> Cc: Ruiyu Ni 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  MdePkg/Library/UefiDevicePathLib/DevicePathToText.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c 
> b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> index 7d8d304f6f..85f5e97131 100644
> --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> @@ -193,11 +193,11 @@ DevPathToTextVendor (
>  return ;
>} else if (CompareGuid (>Guid, )) {
>  UefiDevicePathLibCatPrint (Str, L"VenVt100Plus()");
>  return ;
>} else if (CompareGuid (>Guid, )) {
> -UefiDevicePathLibCatPrint (Str, L"VenUft8()");
> +UefiDevicePathLibCatPrint (Str, L"VenUtf8()");
>  return ;
>} else if (CompareGuid (>Guid, )) {
>  FlowControlMap = (((UART_FLOW_CONTROL_DEVICE_PATH *) 
> Vendor)->FlowControlMap);
>  switch (FlowControlMap & 0x0003) {
>  case 0:
> 

it makes sense to send a set of patches that are correlated in some
fashion, even if they individually address different BZs and don't form
a coherent "feature" or larger "bugfix". However, even in such cases,
please send a common cover letter (0/5 in this case). Seeing a unified
diffstat, and a few intro words (about the common theme of the patch
set) is helpful.

(no need to repost, just for the future)

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

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

[Laszlo Ersek]

On 10/05/18 22:43, Rebecca Cran wrote:
> I don't see any information about time/place/etc. - should there be an
> attachment?

There is an attachment on the original invite email, called "invite.cs".
I see it on the instance of the invite that I got in my inbox directly,
not reflected from the list (because I was named personally on the
invite). However, the attachment is missing from the email reflected by
the list software.

This is not surprising: the edk2-devel list configuration strips all (or
most) attachments. If I remember correctly, I've complained about this
earlier -- such a list config is broken. It prevents people from sending
screenshots (well-compressed PNG screenshots of virtual machines are a
few tens of KB, they are perfectly suitable for mailing lists). It also
prevents people from sending compressed log files in attachments. IIRC
at one point I also had to base64-encode some binary file manually, and
embed it in the normal body of the email, because I wanted the mailing
list *archive* to preserve it.

At least with the TianoCore Bugzilla, we have another option for saving
binary artifacts necessary for debugging / bug reporting. The mailing
list config remains broken however.

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

Re: [edk2] [PATCH] MdeModulePkg:disable wraning to pass gcc4.8 build

[Laszlo Ersek]

On 10/08/18 05:04, Gao, Liming wrote:
> Laszlo:
>We meet with this failure in GCC4.8 and GCC4.9, but not in GCC5.  We don't 
> verify earlier version than GCC4.8. 
>GCC48 is the specific tool chain for GCC4.8. But, GCC49 is the general 
> tool chain that can be used with GCC4.9 or the above GCC version for LTO 
> disable. So, even if we specify this warning for GCC48 and GCC49, it may be 
> applied for GCC5 version. To be simplified, I suggest to disable this warning 
> in the general style. I suggest to add more comments here to describe this 
> warning for GCC4.8, GCC4.9 version. Not for GCC5. 

OK, thank you.
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Openssl submodule

[Laszlo Ersek]

On 10/05/18 23:02, Laszlo Ersek wrote:
> On 10/05/18 17:53, Knop, Ryszard wrote:
>> Hi,
>> Git submodules generally point at a specific commit, so if you go to 
>> https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/OpensslLib 
>> and click on the openssl submodule, you'll go to the exact referenced commit 
>> (currently d4e4bd2, pointing at the 1.1.0h release). It doesn't point at any 
>> specific branch because it's a moving target.
> 
> Right.
> 
> See the "OpenSSL-Version" section in the file
> "CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt". It explains how
> CryptoPkg maintainers advance edk2's reference inside OpenSSL's git history.

Apologies, I forgot to mention:

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

Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of TVKR
>> Sent: Friday, October 5, 2018 16:55
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Openssl submodule
>>
>> Hi,
>>
>> It is not clear if the recent change to add OpenSSL as a submodule will pull 
>> the code from the master branch of "https://github.com/openssl/openssl;
>> or any other branch like "OpenSSL_1_1_0-stable" or "OpenSSL_1_1_1-stable".
>> Can some one please clarify?
>>
>> Thanks
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
>>
>> Intel Technology Poland sp. z o.o.
>> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII 
>> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 
>> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>>
>> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata 
>> i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
>> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
>> jakiekolwiek
>> przegladanie lub rozpowszechnianie jest zabronione.
>> This e-mail and any attachments may contain confidential material for the 
>> sole use of the intended recipient(s). If you are not the intended 
>> recipient, please contact the sender and delete all copies; any review or 
>> distribution by
>> others is strictly prohibited.
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
> 

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

Re: [edk2] Openssl submodule

[Laszlo Ersek]

On 10/05/18 17:53, Knop, Ryszard wrote:
> Hi,
> Git submodules generally point at a specific commit, so if you go to 
> https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/OpensslLib 
> and click on the openssl submodule, you'll go to the exact referenced commit 
> (currently d4e4bd2, pointing at the 1.1.0h release). It doesn't point at any 
> specific branch because it's a moving target.

Right.

See the "OpenSSL-Version" section in the file
"CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt". It explains how
CryptoPkg maintainers advance edk2's reference inside OpenSSL's git history.

Thanks
Laszlo

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of TVKR
> Sent: Friday, October 5, 2018 16:55
> To: edk2-devel@lists.01.org
> Subject: [edk2] Openssl submodule
> 
> Hi,
> 
> It is not clear if the recent change to add OpenSSL as a submodule will pull 
> the code from the master branch of "https://github.com/openssl/openssl;
> or any other branch like "OpenSSL_1_1_0-stable" or "OpenSSL_1_1_1-stable".
> Can some one please clarify?
> 
> Thanks
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII 
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
> 
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
> moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
> jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the 
> sole use of the intended recipient(s). If you are not the intended recipient, 
> please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/05/18 18:49, Kinney, Michael D wrote:
> Reviewed-by: Michael D Kinney 

Great, thank you :)

Patch pushed as commit d20ae95a13e8.

Thanks!
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-
>> boun...@lists.01.org] On Behalf Of
>> marcandre.lur...@redhat.com
>> Sent: Tuesday, October 2, 2018 5:17 AM
>> To: edk2-devel@lists.01.org
>> Cc: Justen, Jordan L ;
>> Anthony Perard ; Laszlo Ersek
>> 
>> Subject: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei:
>> clear CPU caches
>>
>> From: Marc-André Lureau 
>>
>> This is for conformance with the TCG "Platform Reset
>> Attack Mitigation
>> Specification". Because clearing the CPU caches at boot
>> doesn't impact
>> performance significantly, do it unconditionally, for
>> simplicity's
>> sake.
>>
>> Flush the cache on all logical processors, thanks to
>> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Anthony Perard 
>> Cc: Julien Grall 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marc-André Lureau
>> 
>> Message-Id: <20181002120730.13013-1-
>> marcandre.lur...@redhat.com>
>> ---
>>
>> v3:
>>   - update top comment with notes about TCG spec
>>   - sort headers inclusion
>>
>>  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
>>  OvmfPkg/PlatformPei/Platform.h  |   5 +
>>  OvmfPkg/PlatformPei/ClearCache.c| 117
>> 
>>  OvmfPkg/PlatformPei/Platform.c  |   1 +
>>  4 files changed, 125 insertions(+)
>>
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index 9c5ad9961c4a..5c8dd0fe6d72 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -30,6 +30,7 @@
>>
>>  [Sources]
>>AmdSev.c
>> +  ClearCache.c
>>Cmos.c
>>Cmos.h
>>FeatureControl.c
>> @@ -54,6 +55,7 @@
>>
>>  [LibraryClasses]
>>BaseLib
>> +  CacheMaintenanceLib
>>DebugLib
>>HobLib
>>IoLib
>> diff --git a/OvmfPkg/PlatformPei/Platform.h
>> b/OvmfPkg/PlatformPei/Platform.h
>> index f942e61bb4f9..b12a5c1f5f78 100644
>> --- a/OvmfPkg/PlatformPei/Platform.h
>> +++ b/OvmfPkg/PlatformPei/Platform.h
>> @@ -83,6 +83,11 @@ InstallFeatureControlCallback (
>>VOID
>>);
>>
>> +VOID
>> +InstallClearCacheCallback (
>> +  VOID
>> +  );
>> +
>>  EFI_STATUS
>>  InitializeXen (
>>VOID
>> diff --git a/OvmfPkg/PlatformPei/ClearCache.c
>> b/OvmfPkg/PlatformPei/ClearCache.c
>> new file mode 100644
>> index ..7d15fd925c3c
>> --- /dev/null
>> +++ b/OvmfPkg/PlatformPei/ClearCache.c
>> @@ -0,0 +1,117 @@
>> +/**@file
>> +  Install a callback to clear cache on all processors.
>> +  This is for conformance with the TCG "Platform Reset
>> Attack Mitigation
>> +  Specification". Because clearing the CPU caches at
>> boot doesn't impact
>> +  performance significantly, do it unconditionally, for
>> simplicity's
>> +  sake.
>> +
>> +  Copyright (C) 2018, Red Hat, Inc.
>> +
>> +  This program and the accompanying materials are
>> licensed and made available
>> +  under the terms and conditions of the BSD License
>> which accompanies this
>> +  distribution.  The full text of the license may be
>> found at
>> +  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON
>> AN "AS IS" BASIS, WITHOUT
>> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
>> EXPRESS OR IMPLIED.
>> +**/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "Platform.h"
>> +
>> +/**
>> +  Invalidate data & instruction caches.
>> +  All APs execute this function in parallel. The BSP
>> executes the function
>> +  separately.
>> +
>> +  @param[in,out] WorkSpace  Pointer to the input/output
>> argument workspace
>> +shared by all processors.
>> +**/
>> +STATIC
>> +VOID
>> +EFIAPI
>> +ClearCache (
>> +  IN OUT VOID *WorkSpace
>> +  )
>> +{
>> +  WriteBackInvalidateDataCache ();
>> +  InvalidateInstructionCache ();
>> +}
>> +
>> +/**
>&

Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable

[Laszlo Ersek]

On 10/05/18 17:00, Carsey, Jaben wrote:
> 
> 
>> -Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, October 05, 2018 4:33 AM
>> To: Carsey, Jaben ; Andrew Fish
>> 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment
>> variable
>> Importance: High
>>
>> On 10/04/18 22:54, Carsey, Jaben wrote:
>>> Laszlo,
>>>
>>> The leading "_" was required for out of spec, but built in, commands.  The
>> spec has no restrictions on environment variables except some have special
>> meaning and may be read only.
>>>
>>> I can certainly work on slowing down the process.  I have been complaining
>> about that same thing and should have been more aware.  I would like to
>> have a community minimum amount of time before commits are done that
>> we all agree to.  Something like 1 full day would be nice I think.
>>
>> Good idea! I believe 24 hours should be tolerable on all ends. It also
>> gives a chance to people in other time zones to comment.
> 
> So how do we proceed?  What's the "deciding method" to have a minimum time to 
> allow for reviews?

I think we can handle this as part of the following:

https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

Thanks
Laszlo

> 
>>
>> I think there should be one exception: grave regressions -- build
>> failures, or total boot failures -- should be possible to revert (or
>> fix) as soon as there's one review.
> 
> Agreed.  We need some way around when an error is made.
> 
>>
>> Thanks!
>> Laszlo

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

Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable

[Laszlo Ersek]

On 10/04/18 22:54, Carsey, Jaben wrote:
> Laszlo,
> 
> The leading "_" was required for out of spec, but built in, commands.  The 
> spec has no restrictions on environment variables except some have special 
> meaning and may be read only.
> 
> I can certainly work on slowing down the process.  I have been complaining 
> about that same thing and should have been more aware.  I would like to have 
> a community minimum amount of time before commits are done that we all agree 
> to.  Something like 1 full day would be nice I think.

Good idea! I believe 24 hours should be tolerable on all ends. It also
gives a chance to people in other time zones to comment.

I think there should be one exception: grave regressions -- build
failures, or total boot failures -- should be possible to revert (or
fix) as soon as there's one review.

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

Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable

[Laszlo Ersek]

On 10/04/18 21:05, jim.dai...@dell.com wrote:
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
> 
> I'll attempt answer some of your questions, but Jaben may have to
> answer some of them (like his commit speed :-) or questions about what
> the shell spec allows).
> 
>>
>> So my first question would have been, what if the shell is memory mapped
>> (from a firmware volume), but the platform doesn't expose firmware
>> filesystems (FFSs) as EFI simple file system protocol instances? In that
>> case, the "file system on which the executing shell is located" seems
>> ill-defined.
> 
> In such a case homefilesystem will not get defined, I think.

OK, thanks.

> 
>>>>> execute %homefilesystem% to set the cwd to the root of the file system
>>>>> where the shell is located.
>>
>> I think the commit message here misses a "CD" command.
> 
> The shell does not handle "cd fsN:".  But "fsN:" does work.  I suppose
> one could always add a "cd \" after "%hoemfilesystem%", but I think it
> will not have any effect in most (all?) cases where homefilesystem is
> defined.

My mistake.

>>>>> +InternalEfiShellSetEnv(L"homefilesystem", StartupScriptPath, TRUE);
>>>>> +
>>
>> Again, this refers to the startup script, not the shell itself.
> 
> The variable's name implies the startup script, but at the point it is
> used, it contains only the file system where the shell itself was found.
> Code following this continues to modify the variable's value until it
> eventually does point to where the startup script *might* be.

Thanks for explaining!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable

[Laszlo Ersek]

On 10/03/18 20:17, Carsey, Jaben wrote:
> Pushed.
> c0b1f749ef1304810ed4ea58ded65b7f41d79d3e

Please give other reviewers a bit more time than ~2 hours, to comment on
the patch. :)

I think I would have suggested an improvement (or a clarification about)
the commit message. It says:

>> -Original Message-
>> From: Carsey, Jaben
>> Sent: Wednesday, October 03, 2018 11:15 AM
>> To: 'jim.dai...@dell.com' ; edk2-devel@lists.01.org
>> Subject: RE: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment
>> variable
>>
>> Reviewed-by: Jaben Carsey 
>>
>>> -Original Message-
>>> From: jim.dai...@dell.com [mailto:jim.dai...@dell.com]
>>> Sent: Wednesday, October 03, 2018 9:02 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Carsey, Jaben ; Ni, Ruiyu
>> 
>>> Subject: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment
>>> variable
>>> Importance: High
>>>
>>> Create a homefilesystem environment variable whose value is the file
>>> system on which the executing shell is located. For example: "FS14:".

that the file system in question contains the *shell*.

So my first question would have been, what if the shell is memory mapped
(from a firmware volume), but the platform doesn't expose firmware
filesystems (FFSs) as EFI simple file system protocol instances? In that
case, the "file system on which the executing shell is located" seems
ill-defined.

>>>
>>> This eliminates the need for people to have to try and find the "boot"
>>> file system in their startup script.  After this change they can simply

Note, here the commit message refers to the startup script, not the
shell itself.

>>> execute %homefilesystem% to set the cwd to the root of the file system
>>> where the shell is located.

I think the commit message here misses a "CD" command.

>>>
>>> A future enhancement could be to add "homefilesystem" to the list of
>>> predefined, read-only variables listed in the EfiShellSetEnv function of
>>> file ShellProtocol.c

Is it OK with the UEFI shell spec to define a shell variable called
"homefilesystem"? I seem to remember that edk2-specific options for
standard UEFI shell commands generally start with an underscore, to
avoid clashing with the standard namespace. Does that apply to shell
variables perhaps? (This is mostly for my own education.)

>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Jim Dailey 
>>> ---
>>>  ShellPkg/Application/Shell/Shell.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/ShellPkg/Application/Shell/Shell.c
>>> b/ShellPkg/Application/Shell/Shell.c
>>> index 3f3bcbb4b0..6185b6ac80 100644
>>> --- a/ShellPkg/Application/Shell/Shell.c
>>> +++ b/ShellPkg/Application/Shell/Shell.c
>>> @@ -1169,6 +1169,8 @@ LocateStartupScript (
>>>*TempSpot = CHAR_NULL;
>>>  }
>>>
>>> +InternalEfiShellSetEnv(L"homefilesystem", StartupScriptPath, TRUE);
>>> +

Again, this refers to the startup script, not the shell itself.

>>>  StartupScriptPath = StrnCatGrow (, ,
>>> ((FILEPATH_DEVICE_PATH *)FileDevicePath)->PathName, 0);
>>>  PathRemoveLastItem (StartupScriptPath);
>>>  StartupScriptPath = StrnCatGrow (, ,
>>> mStartupScript, 0);
>>> --
>>> 2.17.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] RuntimeDXE unable to save variables to flash

[Laszlo Ersek]

On 10/04/18 12:56, Hristo Mihaylov wrote:
> Hello,
> 
> I have an issue that I don't know how to fix. I'm building a BIOS for a custom
> x86_64 platform.
> 
> The first part of the problem is: the BIOS boots to the end of DXE where
> it crashes with a General Protection exception.
> 
> ```
>  X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
> 0027 
> RIP  - 77ADE823, CS  - 0038, RFLAGS - 00010047
> ExceptionData - 
> RAX  - , RCX - 01FE, RDX - 
> RBX  - , RSP - 75B443C0, RBP - 800FD000
> RSI  - 0001, RDI - 77AFC520
> R8   - 77AFC618, R9  - 0001, R10 - 7000
> R11  - 758B7F10, R12 - 77AFC510, R13 - 0001
> R14  - 8000, R15 - 02C30064
> DS   - 0020, ES  - 0020, FS  - 0020
> GS   - 0020, SS  - 0020
> CR0  - 8033, CR2 - , CR3 - 75977000
> CR4  - 0668, CR8 - 
> DR0  - , DR1 - , DR2 - 
> DR3  - , DR6 - 0FF0, DR7 - 0400
> GDTR - 75986928 004F, LDTR - 
> IDTR - 77ACF400 01FF,   TR - 0040
> FXSAVE_STATE - 75B44020
> ```
> 
> This exception occurs when the BIOS is enabling or disabling the write
> protection of the SPI. It only crashes when it's doing the protection in SMM.
> The code responsible for that is:
> 
> ```
> EFI_STATUS
> EFIAPI
> DisableBiosWriteProtect (
>   VOID
>   )
> {
>   UINTN SpiBaseAddress;
>   UINT32Data32;
> 
>   SpiBaseAddress = MmPciBase (
>  DEFAULT_PCI_BUS_NUMBER_PCH,
>  PCI_DEVICE_NUMBER_PCH_SPI,
>  PCI_FUNCTION_NUMBER_PCH_SPI
>  );
>   // Write clear BC_SYNC_SS prior to change WPD from 0 to 1.
>   //
>   MmioOr8 (
>SpiBaseAddress + R_PCH_SPI_BC + 1,
> (B_PCH_SPI_BC_SYNC_SS >> 8)
> );
>   ///
>   /// Set BIOSWE bit (SPI PCI Offset DCh [0]) = 1b
>   /// Enable the access to the BIOS space for both read and write cycles
>   ///
>   MmioOr8 (
> SpiBaseAddress + R_PCH_SPI_BC,
> B_PCH_SPI_BC_WPD
> );
>   ///
>   /// PCH BIOS Spec Section 3.7 BIOS Region SMM Protection Enabling
>   /// If the following steps are implemented:
>   ///  - Set the EISS bit (SPI PCI Offset DCh [5]) = 1b
>   ///  - Follow the 1st recommendation in section 3.6
>   /// the BIOS Region can only be updated by following the steps bellow:
>   ///  - Once all threads enter SMM
>   ///  - Read memory location FED30880h OR with 0001h, place the result 
> in EAX,
>   ///and write data to lower 32 bits of MSR 1FEh (sample code available)
>   ///  - Set BIOSWE bit (SPI PCI Offset DCh [0]) = 1b
>   ///  - Modify BIOS Region
>   ///  - Clear BIOSWE bit (SPI PCI Offset DCh [0]) = 0b
>   ///
>   if ((MmioRead8 (SpiBaseAddress + R_PCH_SPI_BC) & B_PCH_SPI_BC_EISS) != 0) {
> ///
> /// Read memory location FED30880h OR with 0001h, place the result in 
> EAX,
> /// and write data to lower 32 bits of MSR 1FEh (sample code available)
> ///
> Data32 = MmioRead32 ((UINTN) (0xFED30880)) | BIT0;
> 
> // crash occurs here
> AsmWriteMsr32 (0x1FE, Data32);
>   }
> 
>   return EFI_SUCCESS;
> }
> 
> VOID
> EFIAPI
> EnableBiosWriteProtect (
>   VOID
>   )
> {
>   UINTN SpiBaseAddress;
>   UINT32Data32;
> 
>   SpiBaseAddress = MmPciBase (
>  DEFAULT_PCI_BUS_NUMBER_PCH,
>  PCI_DEVICE_NUMBER_PCH_SPI,
>  PCI_FUNCTION_NUMBER_PCH_SPI
>  );
>   ///
>   /// Clear BIOSWE bit (SPI PCI Offset DCh [0]) = 0b
>   /// Disable the access to the BIOS space for write cycles
>   ///
>   MmioAnd8 (
> SpiBaseAddress + R_PCH_SPI_BC,
> (UINT8) (~B_PCH_SPI_BC_WPD)
> );
> 
>   ///
>   /// Check if EISS bit is set
>   ///
>   if (((MmioRead8 (SpiBaseAddress + R_PCH_SPI_BC)) & B_PCH_SPI_BC_EISS) == 
> B_PCH_SPI_BC_EISS) {
> ///
> /// Read memory location FED30880h AND with FFFEh, place the result 
> in EAX,
> /// and write data to lower 32 bits of MSR 1FEh (sample code available)
> ///
> Data32 = MmioRead32 ((UINTN) (0xFED30880)) & (~BIT0);
> 
> // crash occurs here
> //AsmWriteMsr32 (0x1FE, Data32);
>   }
> }
> ```
> 
> I can work around the crash by hardcoding the values 0x0 and 0x1, or 
> commenting out the writes.

Accessing invalid MSRs may raise injections. How do you know the MSR
0x1FE is valid (and the Data32 value is valid)?

> 
> The second part is that variables cannot be saved or updated:
> 
> ```
> Variable driver flush the HOB variable to flash: {guid} TCG2_CONFIGURATION 
> Invalid Parameter
> Variable driver flush the HOB variable to flash: {guid} Setup 

Re: [edk2] Regression with PXE boot on OvmfPkg/VirtioNetDxe driver on aarch64 system

[Laszlo Ersek]

On 10/04/18 11:24, Leif Lindholm wrote:
> +Peter
> 
> On Wed, Oct 03, 2018 at 04:59:54PM -0700, aaron.yo...@oracle.com wrote:
>>  I am suspecting that this patch to GRUB is the cause of a Buffer being
>> re-transmitted before reaping the Buffer via SNP->GetStatus():
>>
>> https://git.centos.org/blob/rpms!grub2.git/1065bd29e776aef83f927747882140dcb6fd5cde/SOURCES!0183-efinet-retransmit-if-our-device-is-busy.patch
>>
>>  So, to reproduce the issue, the GRUB used via PXE boot needs to include
>> this patch.
> 
> So the issue cannot be reproduced with upstream GRUB?
> 
> Does Fedora/Red Hat include the same patch?

Here's what I can see.

(1) In upstream grub , at
commit 8ada906031d9 ("msdos: Fix overflow in converting partition start
and length into 512B blocks", 2018-09-27), on the master branch, the
patch is not present.

(2) In "rhboot" grub2 , where the
master branch seems to track upstream grub, the patch is present on at
least the "fedora-28" and "rhel-7.5" branches. Commit hashes,
respectively: c2b126f52143, 1b9767c136082.

(3) In the commit message, Josef wrote, "When I fixed the txbuf handling
I ripped out the retransmission code". I think he referred to his
earlier commit 4fe8e6d4a127 ("efinet: handle get_status() on buggy
firmware properly", 2015-08-09). That commit is upstream.

In my opinion, commit 4fe8e6d4a127, the chronologically first, and
upstream, tweak, was right (assuming the comment it added was true,
about grub).

On the other hand, the downstream-only (chronologically 2nd) commit was
wrong. Not only did it break the spec, it broke even grub's own internal
invariant, described in the comment that was added in upstream commit
4fe8e6d4a127. The comment states, "we only transmit one packet at a
time". With the downstream-only tweak applied, that's no longer true.
Namely, SNP.Transmit() is called while we know another transmission is
pending on the egress queue. That's the definition of sending more than
one packet at a time.

I'm curious why the patch in question is not upstream. Was it submitted
and rejected? Submitted and ignored? Not submitted at all?

I'm not a fan of the hard-liner "spec above everything" approach. In
this case though, after the downstream-only tweak, grub is inconsistent
not only with the spec, but with itself too.

IMO, downstream(s) should revert the downstream-only patch.

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

Re: [edk2] [PATCH] Maintainers.txt: add DynamicTablesPkg

[Laszlo Ersek]

On 10/02/18 18:03, Leif Lindholm wrote:
> DynamicTablesPkg has been in edk2-staging[1] for some time now, and it is
> time for it to move into the main tree.
> [1] https://github.com/tianocore/edk2-staging/tree/dynamictables
> 
> Add Evan and Sami as maintainers of the new package, and let them bring
> it in themselves.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> We'll need Reviewed-by: from both new maintainers.
> Github write permissions need to be added separately.
> 
> Please add some documentation at the specified URL before
> you import any code :)
> 
>  Maintainers.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7ebd53f662..072cf3ce8f 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -105,6 +105,11 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
>  M: Ruiyu Ni 
>  M: Hao Wu 
>  
> +DynamicTablesPkg
> +W: https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg
> +M: Evan Lloyd 
> +M: Sami Mujawar 
> +
>  EdkCompatibilityPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/EdkCompatibilityPkg
>  M: Liming Gao 
> 

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

Re: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 14:17, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> This is for conformance with the TCG "Platform Reset Attack Mitigation
> Specification". Because clearing the CPU caches at boot doesn't impact
> performance significantly, do it unconditionally, for simplicity's
> sake.
> 
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau 
> Message-Id: <20181002120730.13013-1-marcandre.lur...@redhat.com>

I'm going to remove the Message-Id line on push. I don't know why it's
there, but either way, it's not correct. (The msgid of your posting is
<20181002121725.17178-1-marcandre.lur...@redhat.com>.)

With that:

Reviewed-by: Laszlo Ersek 

Also,

Regression-tested-by: Laszlo Ersek 

I'm ready to push this, but I'd still like to get an A-b from Mike (CC'd).

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

Re: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 15:27, Anthony PERARD wrote:
> On Tue, Oct 02, 2018 at 04:17:25PM +0400, marcandre.lur...@redhat.com wrote:
>> From: Marc-André Lureau 
>>
>> This is for conformance with the TCG "Platform Reset Attack Mitigation
>> Specification". Because clearing the CPU caches at boot doesn't impact
>> performance significantly, do it unconditionally, for simplicity's
>> sake.
>>
>> Flush the cache on all logical processors, thanks to
>> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Anthony Perard 
>> Cc: Julien Grall 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marc-André Lureau 
> 
> That patch works for me on Xen. I can still boot guests with the patch
> applied, with either 1 or 4 vcpus assigned to the guest:
> 
> Tested-by: Anthony PERARD 

Thanks a lot!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: Allow multiple PciDeviceId in Fdf OptionROM override

[Laszlo Ersek]

+Yonghong, +Liming

On 10/02/18 16:46, Tomas Pilar (tpilar) wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Tomas Pilar 
> ---
>  BaseTools/Source/Python/GenFds/FdfParser.py | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
> b/BaseTools/Source/Python/GenFds/FdfParser.py
> index 63687e98bb..a65f2cfd2d 100644
> --- a/BaseTools/Source/Python/GenFds/FdfParser.py
> +++ b/BaseTools/Source/Python/GenFds/FdfParser.py
> @@ -4469,10 +4469,15 @@ class FdfParser:
>  if self.__IsKeyword( "PCI_DEVICE_ID"):
>  if not self.__IsToken( "="):
>  raise Warning("expected '='", self.FileName, 
> self.CurrentLineNumber)
> -if not self.__GetNextHexNumber():
> -raise Warning("expected Hex device id", 
> self.FileName, self.CurrentLineNumber)
>  
> -Overrides.PciDeviceId = self.__Token
> +# Get a list of PCI IDs
> +Overrides.PciDeviceId = ""
> +
> +while self.__GetNextHexNumber():
> +Overrides.PciDeviceId += " " + self.__Token
> +
> +if not Overrides.PciDeviceId:
> +raise Warning("expected one or more Hex device ids", 
> self.FileName, self.CurrentLineNumber)
>  continue
>  
>  if self.__IsKeyword( "PCI_REVISION"):
> 

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

Re: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 14:17, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> This is for conformance with the TCG "Platform Reset Attack Mitigation
> Specification". Because clearing the CPU caches at boot doesn't impact
> performance significantly, do it unconditionally, for simplicity's
> sake.
> 
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau 
> Message-Id: <20181002120730.13013-1-marcandre.lur...@redhat.com>
> ---
> 
> v3:
>   - update top comment with notes about TCG spec
>   - sort headers inclusion

So, meta comments first...

I got this patch (v3) in three variants:


(a) the one you sent me off-list, as quoted-printable:

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


(b) this message, reaching me directly from you:

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


(c) this message, reflected by the edk2-devel list software, from you to me:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64


Results:
- git-am fails with (a).
- git-am *also* fails with (c).
- git-am only works on (b).

Which means that your setup is now correct, but some mail server on path
(c) is broken, and corrupts your patch email when it transcodes the
email to base64. Yay!

I guess I'll work with copy (b), in my inbox.

Sigh, is the mailing list workflow actually *more* broken than github
pull requests? I thought that was impossible, but I guess I'm being
proven wrong.

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

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 14:10, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Oct 2, 2018 at 3:55 PM Laszlo Ersek  wrote:
>>
>> On 10/02/18 13:37, Marc-André Lureau wrote:
>>> On Tue, Oct 2, 2018 at 2:55 PM Laszlo Ersek  wrote:
>>
>>>> Please fix your git settings for your local edk2 clone. Your patch
>>>> contains context lines with LF (not CRLF) line endings, and that's not
>>>> correct for edk2.
>>>
>>> Shouldn't it be catched by: python BaseTools/Scripts/PatchCheck.py -1 ?
>>
>> Yes, it should be caught by "PatchCheck.py". The "force_crlf" member is
>> set iff the pathname doesn't end in ".sh", and then the
>> check_added_line() method verifies CRLF.
>>
>> I don't know why it doesn't work in practice. Can you submit a TianoCore
>> BZ about it?
>>
>> (Your patch uses LF on both context lines and new (added) lines, so the
>> current script logic should complain, yes.)
>>
>>> Hmm, this is weird, the original patch has crlf (see attach file).
>>> send-email or the mail server somehow stripped it?
>>>
>>> I use your recommend git settings, I don't know what I am missing here.
>>
>> You are right, the attachment looks fine.
>>
>> ... Can you resend the v2 patch (just to me directly, off-list) with
>>
>>   --transfer-encoding=quoted-printable
>>
>> ? My guess is that the base64 encoding in git-send-email includes an
>> automatic CR stripping phase.
> 
> Hmm, actually it's my emacs settings that stripped the crlf from the patch.
> 
> I edited the patch manually to add some notes...

Haha, serves you right then ;)

I suggest never editing patches after formatting them. In the first
place, there's no reason to: you can add, edit and remove notes on
commits with "git notes" (without changing the commit hashes / git
history). And "git-format-patch" takes a "--notes" option. (Same for
"git show".)

I do mention git-notes in the "unkempt guide":

git config notes.rewriteRef   refs/notes/commits

git format-patch   \
  --notes  \

git notes edit COMMIT_HASH_OF_THAT_PATCH


Thanks for tracking this down!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 13:55, Laszlo Ersek wrote:
> On 10/02/18 13:37, Marc-André Lureau wrote:
>> On Tue, Oct 2, 2018 at 2:55 PM Laszlo Ersek  wrote:
> 
>>> Please fix your git settings for your local edk2 clone. Your patch
>>> contains context lines with LF (not CRLF) line endings, and that's not
>>> correct for edk2.
>>
>> Shouldn't it be catched by: python BaseTools/Scripts/PatchCheck.py -1 ?
> 
> Yes, it should be caught by "PatchCheck.py". The "force_crlf" member is
> set iff the pathname doesn't end in ".sh", and then the
> check_added_line() method verifies CRLF.
> 
> I don't know why it doesn't work in practice. Can you submit a TianoCore
> BZ about it?

Nevermind:

> You are right, the attachment looks fine.

... so that's the reason "PatchCheck.py" does not complain.

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

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 13:37, Marc-André Lureau wrote:
> On Tue, Oct 2, 2018 at 2:55 PM Laszlo Ersek  wrote:

>> Please fix your git settings for your local edk2 clone. Your patch
>> contains context lines with LF (not CRLF) line endings, and that's not
>> correct for edk2.
> 
> Shouldn't it be catched by: python BaseTools/Scripts/PatchCheck.py -1 ?

Yes, it should be caught by "PatchCheck.py". The "force_crlf" member is
set iff the pathname doesn't end in ".sh", and then the
check_added_line() method verifies CRLF.

I don't know why it doesn't work in practice. Can you submit a TianoCore
BZ about it?

(Your patch uses LF on both context lines and new (added) lines, so the
current script logic should complain, yes.)

> Hmm, this is weird, the original patch has crlf (see attach file).
> send-email or the mail server somehow stripped it?
> 
> I use your recommend git settings, I don't know what I am missing here.

You are right, the attachment looks fine.

... Can you resend the v2 patch (just to me directly, off-list) with

  --transfer-encoding=quoted-printable

? My guess is that the base64 encoding in git-send-email includes an
automatic CR stripping phase.

If indeed bas64 is the culprit, I'll update the wiki article to specify
quoted-printable.

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

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

Anthony, Julien, Gary,

On 10/02/18 13:16, Laszlo Ersek wrote:
> On 10/02/18 10:36, marcandre.lur...@redhat.com wrote:

[...]

> The rest looks good, thanks. I'll regression-test the patch (with SMP
> and UP guests) once you post v3.

can one of you guys please regression-test v3 as well, in a Xen guest?
(UP and SMP.) This patch is different from the FeatureControl stuff in
that this one is not gated by fw_cfg. That implies CpuMpPei will be put
to use in Xen guests as well. We had better check whether it works
before we push the patch.

I'd also like to receive an ACK from Mike, for v3.

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

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/02/18 10:36, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> This is for conformance with the TCG "Platform Reset Attack Mitigation
> Specification". Because clearing the CPU caches at boot doesn't impact
> performance significantly, do it unconditionally, for simplicity's
> sake.
> 
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.

The commit message looks OK to me, thanks.

> 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Kinney Michael D 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau 
> ---
> 
> v2:
>   - use CacheMaintenanceLib, instead of WBINVD usage
>   - rename OnMpServicesAvailable->ClearCacheOnMpServicesAvailable
>   - commit message & comments update
> 
>  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
>  OvmfPkg/PlatformPei/Platform.h  |   5 +
>  OvmfPkg/PlatformPei/ClearCache.c| 113 
>  OvmfPkg/PlatformPei/Platform.c  |   1 +
>  4 files changed, 121 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 9c5ad9961c4a..5c8dd0fe6d72 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -30,6 +30,7 @@
>  
>  [Sources]
>AmdSev.c
> +  ClearCache.c
>Cmos.c
>Cmos.h
>FeatureControl.c
> @@ -54,6 +55,7 @@
>  
>  [LibraryClasses]
>BaseLib
> +  CacheMaintenanceLib
>DebugLib
>HobLib
>IoLib

OK.

> diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h
> index f942e61bb4f9..b12a5c1f5f78 100644
> --- a/OvmfPkg/PlatformPei/Platform.h
> +++ b/OvmfPkg/PlatformPei/Platform.h
> @@ -83,6 +83,11 @@ InstallFeatureControlCallback (
>VOID
>);
>  
> +VOID
> +InstallClearCacheCallback (
> +  VOID
> +  );
> +
>  EFI_STATUS
>  InitializeXen (
>VOID
> diff --git a/OvmfPkg/PlatformPei/ClearCache.c 
> b/OvmfPkg/PlatformPei/ClearCache.c
> new file mode 100644
> index ..d333b7dcdd88
> --- /dev/null
> +++ b/OvmfPkg/PlatformPei/ClearCache.c
> @@ -0,0 +1,113 @@
> +/**@file
> +  Install a callback to clear cache on all processors.

The short explanation I requested in my previous point (2) is still missing.

(I think you may have misunderstood my previous points (1) and (2). In
(1), I asked for addressing Mike's observation in the commit message.
That was basically about replacing WBINVD with a reference to
CacheMaintenanceLib. In (2), I asked for the commit message to be fused
into a short sentence *here*, in this source file. IOW, my point (2)
wasn't about modifying the commit message itself; it was about
distilling a file comment from the commit message.

Anyway, I'm fine with the new commit message too, but the file comment
is still missing.)

> +
> +  Copyright (C) 2018, Red Hat, Inc.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 

You've kept the INF file sections sorted, thanks a lot for that; please
keep this Library/* include list sorted as well.

The rest looks good, thanks. I'll regression-test the patch (with SMP
and UP guests) once you post v3.

Thanks,
Laszlo

> +
> +#include "Platform.h"
> +
> +/**
> +  Invalidate data & instruction caches.
> +  All APs execute this function in parallel. The BSP executes the function
> +  separately.
> +
> +  @param[in,out] WorkSpace  Pointer to the input/output argument workspace
> +shared by all processors.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ClearCache (
> +  IN OUT VOID *WorkSpace
> +  )
> +{
> +  WriteBackInvalidateDataCache ();
> +  InvalidateInstructionCache ();
> +}
> +
> +/**
> +  Notification function called when EFI_PEI_MP_SERVICES_PPI becomes 
> available.
> +
> +  @param[in] PeiServices  Indirect reference to the PEI Services Table.
> +  @param[in] NotifyDescriptor Address of the notification descriptor data
> +  structure.
> +  @param[in] Ppi  Address of the PPI that was installed.
> +
> +  @return  Status of the notification. Th

Re: [edk2] [PATCH v2 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

Hi Marc-André,

On 10/02/18 10:36, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
>
> This is for conformance with the TCG "Platform Reset Attack Mitigation
> Specification". Because clearing the CPU caches at boot doesn't impact
> performance significantly, do it unconditionally, for simplicity's
> sake.
>
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Kinney Michael D 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau 
> ---
>
> v2:
>   - use CacheMaintenanceLib, instead of WBINVD usage
>   - rename OnMpServicesAvailable->ClearCacheOnMpServicesAvailable
>   - commit message & comments update
>
>  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
>  OvmfPkg/PlatformPei/Platform.h  |   5 +
>  OvmfPkg/PlatformPei/ClearCache.c| 113 
>  OvmfPkg/PlatformPei/Platform.c  |   1 +
>  4 files changed, 121 insertions(+)

Please fix your git settings for your local edk2 clone. Your patch
contains context lines with LF (not CRLF) line endings, and that's not
correct for edk2.

I decoded your base64-encoded patch email manually, hence my statement
about the line endings. Here's a snippet from
"OvmfPkg/PlatformPei/PlatformPei.inf":

0d90  64 69 66 66 20 2d 2d 67  69 74 20 61 2f 4f 76 6d  |diff --git a/Ovm|
0da0  66 50 6b 67 2f 50 6c 61  74 66 6f 72 6d 50 65 69  |fPkg/PlatformPei|
0db0  2f 50 6c 61 74 66 6f 72  6d 50 65 69 2e 69 6e 66  |/PlatformPei.inf|
0dc0  20 62 2f 4f 76 6d 66 50  6b 67 2f 50 6c 61 74 66  | b/OvmfPkg/Platf|
0dd0  6f 72 6d 50 65 69 2f 50  6c 61 74 66 6f 72 6d 50  |ormPei/PlatformP|
0de0  65 69 2e 69 6e 66 0a 69  6e 64 65 78 20 39 63 35  |ei.inf.index 9c5|
0df0  61 64 39 39 36 31 63 34  61 2e 2e 35 63 38 64 64  |ad9961c4a..5c8dd|
0e00  30 66 65 36 64 37 32 20  31 30 30 36 34 34 0a 2d  |0fe6d72 100644.-|
0e10  2d 2d 20 61 2f 4f 76 6d  66 50 6b 67 2f 50 6c 61  |-- a/OvmfPkg/Pla|
0e20  74 66 6f 72 6d 50 65 69  2f 50 6c 61 74 66 6f 72  |tformPei/Platfor|
0e30  6d 50 65 69 2e 69 6e 66  0a 2b 2b 2b 20 62 2f 4f  |mPei.inf.+++ b/O|
0e40  76 6d 66 50 6b 67 2f 50  6c 61 74 66 6f 72 6d 50  |vmfPkg/PlatformP|
0e50  65 69 2f 50 6c 61 74 66  6f 72 6d 50 65 69 2e 69  |ei/PlatformPei.i|
0e60  6e 66 0a 40 40 20 2d 33  30 2c 36 20 2b 33 30 2c  |nf.@@ -30,6 +30,|
0e70  37 20 40 40 0a 20 0a 20  5b 53 6f 75 72 63 65 73  |7 @@. . [Sources|
0e80  5d 0a 20 20 20 41 6d 64  53 65 76 2e 63 0a 2b 20  |].   AmdSev.c.+ |
0e90  20 43 6c 65 61 72 43 61  63 68 65 2e 63 0a 20 20  | ClearCache.c.  |
0ea0  20 43 6d 6f 73 2e 63 0a  20 20 20 43 6d 6f 73 2e  | Cmos.c.   Cmos.|
0eb0  68 0a 20 20 20 46 65 61  74 75 72 65 43 6f 6e 74  |h.   FeatureCont|
0ec0  72 6f 6c 2e 63 0a 40 40  20 2d 35 34 2c 36 20 2b  |rol.c.@@ -54,6 +|
0ed0  35 35 2c 37 20 40 40 0a  20 0a 20 5b 4c 69 62 72  |55,7 @@. . [Libr|
0ee0  61 72 79 43 6c 61 73 73  65 73 5d 0a 20 20 20 42  |aryClasses].   B|
0ef0  61 73 65 4c 69 62 0a 2b  20 20 43 61 63 68 65 4d  |aseLib.+  CacheM|
0f00  61 69 6e 74 65 6e 61 6e  63 65 4c 69 62 0a 20 20  |aintenanceLib.  |

Due to this issue, git-am fails to apply the patch.

I mentioned this earlier (including a request to push your patches being
submitted to a personal repo/branch as well):

  http://mid.mail-archive.com/f5c15a1e-25c2-c2e4-e6db-374107e3b488@redhat.com

The wiki article at

  
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

explains the git settings in order for git not to hide the CRLFs in the
working tree. In particular, the git concept for (a) representing the
source code internally with LFs, and (b) converting to/from CRLF on
checkout/commit, is *not* to be used.

Is this edk2 peculiarity broken, considering git standards and other
open source repositories? It sure is.

Can we change it? No, we can't.

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

Re: [edk2] [PATCH v3 00/16] Removed unused PCDs

[Laszlo Ersek]

Ray, Chao,

guys, you keep breaking the development process. Please fix your email
clients *now*.


On 08/28/18 05:42, shenglei wrote:
> shenglei (16):
>   IntelFsp2Pkg FspSecCore: Remove unused PCDs
>   IntelFsp2Pkg/BaseFspCommonLib: Remove unused PCDs
>   IntelFsp2Pkg/BaseFspPlatformLib: Remove unused PCDs
>   IntelFsp2Pkg/BaseFspSwitchStackLib: Remove unused PCDs
>   IntelFsp2WrapperPkg/FspWrapperNotifyDxe: Remove an unused PCD
>   IntelFsp2WrapperPkg/BaseFspWrapperPlatformLibSample: Remove PCDs
>   SecurityPkg/Tcg2ConfigPei: Remove an unused PCD

This was patch #07 in this series. I had never reviewed it, yet Chao
pushed it with my R-b as commit

  https://github.com/tianocore/edk2/commit/3e11c27f67ea


>   SecurityPkg/Tcg2Dxe: Remove unused PCDs
>   UefiCpuPkg/CpuCommonFeaturesLib: Remove an unused PCD
>   MdePkg/BaseLib: Remove an unused PCD
>   MdeModulePkg/DxeCapsuleLibFmp: Remove unused PCDs
>   MdeModulePkg/FirmwarePerformanceDataTableDxe: Remove an unused PCD
>   ShellPkg/Shell: Remove unused PCDs

This was patch #13 in this series. I reviewed it:

  70dfa56d-6781-e8c0-f3f4-aa12558672b9@redhat.com">http://mid.mail-archive.com/70dfa56d-6781-e8c0-f3f4-aa12558672b9@redhat.com

but Ray pushed it as commit

  https://github.com/tianocore/edk2/commit/a9dfe53f56bb

without my R-b tag. (Note: there was 1 month between my feedback and the
push date.)

The commit message now suggests that I ignored the patch (because I was
on CC, but seemingly didn't respond). It mis-represents my acts.


>   ShellPkg/DpDynamicCommand: Remove unused PCDs
>   ShellPkg/UefiHandleParsingLib: Remove an unused PCD

Same here. Patch #15, pushed as commit

  https://github.com/tianocore/edk2/commit/42a7c2871a65

My review was at:

  a70f17d9-b937-2835-4d71-5464bad82219@redhat.com">http://mid.mail-archive.com/a70f17d9-b937-2835-4d71-5464bad82219@redhat.com

but it was dropped from the commit.


>   ShellPkg/UefiShellDebug1CommandsLib: Remove unused PCDs

Ditto. Patch #16. My review was at:

  d23e7c95-96e9-4088-4e95-5dbc0a331cb1@redhat.com">http://mid.mail-archive.com/d23e7c95-96e9-4088-4e95-5dbc0a331cb1@redhat.com

but the patch was pushed as commit

  https://github.com/tianocore/edk2/commit/aa9986651bfe

with my review lost.


This is not the first time it has happened. If I remember correctly, Ray
blamed his email client last time (not showing message threads
correctly, or something similar).

I'm sorry, but this is unacceptable. This is on-going, systemic
disregard for the project's other participants.

Please fix your mail user agents *now*.

Here's my promise. Next time, I'm going to revert such commits (assuming
I manage to catch them again). They do not represent the facts from the
mailing list.

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

Re: [edk2] [PATCH 5/5] MdePkg/BaseSynchronizationLib GCC: simplify IA32 InternalSyncCompareExchange64()

[Laszlo Ersek]

On 10/01/18 20:27, Philippe Mathieu-Daudé wrote:
> On 30/09/2018 00:23, Laszlo Ersek wrote:
>> The IA32 variant of InternalSyncCompareExchange64() is correct, but we can
>> simplify it. We don't need to load the lower 32 bits of ExchangeValue into
>> EBX in two steps (first into a general register, then into EBX); we can
>> ask GCC to populate EBX like that itself.
>>
>> Cc: Liming Gao 
>> Cc: Michael D Kinney 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek 
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> 
>> ---
>>  MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
>> b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
>> index 44188e265af2..af39bdeb516c 100644
>> --- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
>> +++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
>> @@ -193,14 +193,11 @@ InternalSyncCompareExchange64 (
>>)
>>  {
>>__asm__ __volatile__ (
>> -"push%%ebx  \n\t"
>> -"movl%2,%%ebx   \n\t"
>>  "lock   \n\t"
>>  "cmpxchg8b   (%1)   \n\t"
>> -"pop %%ebx  \n\t"
>>  : "+A"  (CompareValue)// %0
>>  : "S"   (Value),  // %1
>> -  "r"   ((UINT32) ExchangeValue), // %2
>> +  "b"   ((UINT32) ExchangeValue), // %2
>>"c"   ((UINT32) (ExchangeValue >> 32))  // %3
>>  : "memory",
>>"cc"
>>

Thank you for the review!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg:disable wraning to pass gcc4.8 build

[Laszlo Ersek]

Wait a sec:

On 10/01/18 19:48, Laszlo Ersek wrote:

> However, this (edk2) commit message seems to suggest that the warnings
> are only present with gcc-4.8 (and no later gcc releases). This in turn
> suggests that the warnings are spurious (presumably, later gcc releases
> recognize that none of the affected variables are actually read without
> a prior initialization or assignment.)
> 
> Hence, upstream Oniguruma might argue that we should fix our compiler --
> they might consider gcc-4.8 too old to care -- rather than litter their
> code with superfluous assignments, just to pacify gcc-4.8.

[...]

> So, I think I agree with this patch, but the commit message should be a
> *lot* more detailed. (Basically, include the analysis from above.)

In fact, another improvement is possible: if the issue only affects
gcc-4.8, then:

>> On 29/09/18 02:55, Dongao Guo wrote:
>>> Change-Id: I782962e4994a8edf14beb7ede8b1aabe233dc3a8
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> ---
>>>  MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 
>>> +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git 
>>> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
>>> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>>> index 16e91bd..07bc02e 100644
>>> --- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>>> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>>> @@ -109,3 +109,6 @@
>>>
>>># Oniguruma: error: variable 'fp' set but not used
>>>GCC:*_*_*_CC_FLAGS = -Wno-error=unused-but-set-variable
>>> +
>>> +  # Oniguruma: tag_end in parse_callout_of_name
>>> +  GCC:*_*_*_CC_FLAGS = -Wno-error=maybe-uninitialized

this toolchain glob pattern is too general. It should be:

  GCC:*_GCC48_*_CC_FLAGS

(or maybe spell it out for all GCC versions up to and including 4.8,
from the earliest we support, 4.4.)

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

Re: [edk2] [PATCH] MdeModulePkg:disable wraning to pass gcc4.8 build

[Laszlo Ersek]

On 10/01/18 11:23, Tomas Pilar (tpilar) wrote:
> Wouldn't it be better to fix the warnings in code rather than
> silencing them?

The same idea occurred to me, but it really depends on upstream
Oniguruma. The upstream project's issue tracker on github seems quite
active:

  https://github.com/kkos/oniguruma/issues

so we could reasonably file a bug report there (and/or submit a pull
request).

However, this (edk2) commit message seems to suggest that the warnings
are only present with gcc-4.8 (and no later gcc releases). This in turn
suggests that the warnings are spurious (presumably, later gcc releases
recognize that none of the affected variables are actually read without
a prior initialization or assignment.)

Hence, upstream Oniguruma might argue that we should fix our compiler --
they might consider gcc-4.8 too old to care -- rather than litter their
code with superfluous assignments, just to pacify gcc-4.8.

(Obviously, if any one of those warnings is valid, then we *must* fix it
in upstream Oniguruma first, and backport the fix.)


... For reference, I've now built RegularExpressionDxe as follows (using
gcc-4.8.5-28.el7_5.1.x86_64):

  build -t GCC48 -b DEBUG -a X64 \
-p MdeModulePkg/MdeModulePkg.dsc \
-m MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf

and I get the following 3 "maybe-uninitialized" warnings (currently:
errors):

(1)

> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c: In
> function 'compile_length_tree':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c:1516:7:
> warning: 'len' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>int len;
>^

I think this is an invalid warning; the type of the controlling
expression (node->type) is enum GimmickType, and the case labels cover
all values of the enum. An assert(0) could be added, I guess, but again,
upstream Oniguruma would be justified to reject the idea.

(2)

> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
> function 'parse_callout_args.isra.10.constprop.30':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6753:25:
> warning: 'rl' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>vals[n].l = rl;
>  ^

This warning is invalid, given:

  6749if (cn > 0) {
  6750  long rl;
  6751  r = parse_long(enc, buf, bufend, 1, LONG_MAX, );
  6752  if (r == ONIG_NORMAL) {
  6753vals[n].l = rl;

Because parse_long() only returns ONIG_NORMAL after it sets (*rl).

(3)

> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
> function 'parse_callout_of_name.constprop.29':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6861:38:
> warning: 'tag_end' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
  ^

This warning is also invalid, given:

  6852if (c == '[') {
  6853  if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
  6854  tag_start = p;
  6855  while (! PEND) {
  6856if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
  6857tag_end = p;
  6858PFETCH_S(c);
  6859if (c == ']') break;
  6860  }
  6861  if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
  6862return ONIGERR_INVALID_CALLOUT_TAG_NAME;
  6863

To see that, first we should note:

#define PEND (p < end ?  0 : 1)

therefore PEND doesn't change if neither "p" nor "end" change.

Second, when we reach line 6855 (the "while") for the very first time,
(!PEND) is certainly true (i.e., PEND is false), because otherwise we
would have bailed at line 6853. Therefore we reach line 6857, and assign
"tag_end". Regardless of whether we iterate zero or more *additional*
times around the loop, "tag_end" will have been set, whenever we reach
line 6861.

So, I think I agree with this patch, but the commit message should be a
*lot* more detailed. (Basically, include the analysis from above.)

Thanks
Laszlo


> On 29/09/18 02:55, Dongao Guo wrote:
>> Change-Id: I782962e4994a8edf14beb7ede8b1aabe233dc3a8
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> ---
>>  MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git 
>> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
>> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> index 16e91bd..07bc02e 100644
>> --- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> @@ -109,3 +109,6 @@
>>
>># Oniguruma: error: variable 'fp' set but not used
>>GCC:*_*_*_CC_FLAGS = -Wno-error=unused-but-set-variable
>> +
>> +  # Oniguruma: tag_end in parse_callout_of_name

Re: [edk2] [PATCH v1 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Laszlo Ersek]

On 10/01/18 13:45, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> The TCG "Platform Reset Attack Mitigation Specification" requires to
> clear the processor caches when the MOR bit is set at boot time.
> 
> According to Paolo Bonzini, clearing the CPU cache takes only a few
> hundred clock cycles, so it can be done unconditionally.
> 
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI, calling WBINVD "Write Back and Invalidate
> Cache" x86 instruction.

(1) Please update this paragraph (and the code, of course) as suggested
by Michael. (I guess I should have known better, and suggested
WriteBackInvalidateDataCache() myself. While in this particular case,
there's not a big difference, because this code is X86 only, I agree
it's better to call the more abstract interface.)

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau 
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf |   1 +
>  OvmfPkg/PlatformPei/Platform.h  |   5 +
>  OvmfPkg/PlatformPei/ClearCache.c| 110 
>  OvmfPkg/PlatformPei/Platform.c  |   1 +
>  4 files changed, 117 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 9c5ad9961c4a..9c9a95fb3fe5 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -30,6 +30,7 @@
>  
>  [Sources]
>AmdSev.c
> +  ClearCache.c
>Cmos.c
>Cmos.h
>FeatureControl.c
> diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h
> index f942e61bb4f9..b12a5c1f5f78 100644
> --- a/OvmfPkg/PlatformPei/Platform.h
> +++ b/OvmfPkg/PlatformPei/Platform.h
> @@ -83,6 +83,11 @@ InstallFeatureControlCallback (
>VOID
>);
>  
> +VOID
> +InstallClearCacheCallback (
> +  VOID
> +  );
> +
>  EFI_STATUS
>  InitializeXen (
>VOID
> diff --git a/OvmfPkg/PlatformPei/ClearCache.c 
> b/OvmfPkg/PlatformPei/ClearCache.c
> new file mode 100644
> index ..a1fff8446d13
> --- /dev/null
> +++ b/OvmfPkg/PlatformPei/ClearCache.c
> @@ -0,0 +1,110 @@
> +/**@file
> +  Install a callback to clear cache on all processors.

(2) Please fuse the first two paragraphs of the commit message into a
short additional sentence here, such as:

  This is for conformance with the TCG "Platform Reset Attack Mitigation
  Specification". Because clearing the CPU caches at boot doesn't impact
  performance significantly, do it unconditionally, for simplicity's
  sake.

> +
> +  Copyright (C) 2018, Red Hat, Inc.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "Platform.h"
> +
> +/**
> +  All APs execute this function in parallel. The BSP executes the function
> +  separately.
> +
> +  @param[in,out] WorkSpace  Pointer to the input/output argument workspace
> +shared by all processors.
> +**/

(3) Please prepend a short sentence to the top of the comment block,
stating what the callback does.

> +STATIC
> +VOID
> +EFIAPI
> +ClearCache (
> +  IN OUT VOID *WorkSpace
> +  )
> +{
> +  AsmWbinvd ();

(4) This is where Mike's comment applies.

> +}
> +
> +/**
> +  Notification function called when EFI_PEI_MP_SERVICES_PPI becomes 
> available.
> +
> +  @param[in] PeiServices  Indirect reference to the PEI Services Table.
> +  @param[in] NotifyDescriptor Address of the notification descriptor data
> +  structure.
> +  @param[in] Ppi  Address of the PPI that was installed.
> +
> +  @return  Status of the notification. The status code returned from this
> +   function is ignored.
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +OnMpServicesAvailable (

(5) Technically this is correct, but we should preferably avoid a
function name collision even for debug log purposes, between this file,
and "OvmfPkg/PlatformPei/FeatureControl.c".

We already disambiguate the log message quite well, because we log
gEfiCallerBaseName, not just __FUNCTION__; however, in this case,
gEfi

Re: [edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

[Laszlo Ersek]

On 09/30/18 00:23, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: inline_asm_rw_ops_1208
> 
> This series mainly fixes the operand constraints (missing input-output
> qualifications) in "BaseSynchronizationLib/*/GccInline.c".
> 
> (It would be better to remove these files altogether in favor of the
> already existing NASM implementation, but due to
> <https://bugzilla.tianocore.org/show_bug.cgi?id=881>, we can't generally
> do that in libraries yet.)
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (5):
>   MdePkg/BaseSynchronizationLib GCC: fix whitespace and comments
>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange16()
>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange32()
>   MdePkg/BaseSynchronizationLib GCC: fix X64
> InternalSyncCompareExchange64()
>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
> InternalSyncCompareExchange64()
> 
>  MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 +++--
>  MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 47 
> +++-
>  2 files changed, 34 insertions(+), 55 deletions(-)
> 

Forgot to mention the testing.

Ran my usual OVMF tests described at
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt>
on multi-VCPU guests. I tested the series against all my longterm guests
(including 32-bit and 64-bit Fedora, and 64-bit Windows 7 / Server 2008
r2, 8.1 / Server 2012 r2, 10 / Server 2016). Also covered an SMM-less
build on i440fx, with 64-bit Fedora.

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

[edk2] [PATCH 5/5] MdePkg/BaseSynchronizationLib GCC: simplify IA32 InternalSyncCompareExchange64()

[Laszlo Ersek]

The IA32 variant of InternalSyncCompareExchange64() is correct, but we can
simplify it. We don't need to load the lower 32 bits of ExchangeValue into
EBX in two steps (first into a general register, then into EBX); we can
ask GCC to populate EBX like that itself.

Cc: Liming Gao 
Cc: Michael D Kinney 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index 44188e265af2..af39bdeb516c 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -193,14 +193,11 @@ InternalSyncCompareExchange64 (
   )
 {
   __asm__ __volatile__ (
-"push%%ebx  \n\t"
-"movl%2,%%ebx   \n\t"
 "lock   \n\t"
 "cmpxchg8b   (%1)   \n\t"
-"pop %%ebx  \n\t"
 : "+A"  (CompareValue)// %0
 : "S"   (Value),  // %1
-  "r"   ((UINT32) ExchangeValue), // %2
+  "b"   ((UINT32) ExchangeValue), // %2
   "c"   ((UINT32) (ExchangeValue >> 32))  // %3
 : "memory",
   "cc"
-- 
2.14.1.3.gb7cf6e02401b

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

[edk2] [PATCH 3/5] MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange32()

[Laszlo Ersek]

(This patch is identical to the last one, except for the
InternalSyncCompareExchange16() -> InternalSyncCompareExchange32() and
"cmpxchgw" -> "cmpxchgl" replacements.)

The CMPXCHG instruction has the following operands:
- AX (implicit, CompareValue):input and output
- destination operand (*Value):   input and output
- source operand (ExchangeValue): input

The IA32 version of InternalSyncCompareExchange32() correctly marks
CompareValue as input/output, but it marks (*Value) only as input.

The X64 version of InternalSyncCompareExchange32() attempts to mark both
CompareValue and (*Value) as input/output, but it doesn't use the
appropriate constraints for either operand.

Fix these issues. Furthermore, prefer the short "+" constraint for I/O
operands over the  constraint that can be applied
to the input instances of I/O operands.

Cc: Liming Gao 
Cc: Michael D Kinney 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c |  9 -
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 10 --
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index bd98a5aebfe7..44188e265af2 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -155,11 +155,10 @@ InternalSyncCompareExchange32 (
 {
   __asm__ __volatile__ (
 "lock \n\t"
-"cmpxchgl%1, %2   \n\t"
-: "=a" (CompareValue)   // %0
-: "q"  (ExchangeValue), // %1
-  "m"  (*Value),// %2
-  "0"  (CompareValue)   // %3
+"cmpxchgl%2, %1   \n\t"
+: "+a" (CompareValue),  // %0
+  "+m" (*Value) // %1
+: "q"  (ExchangeValue)  // %2
 : "memory",
   "cc"
 );
diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
index 4338fb8e65e8..a85cf0265c8b 100644
--- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
@@ -155,12 +155,10 @@ InternalSyncCompareExchange32 (
 {
   __asm__ __volatile__ (
 "lock \n\t"
-"cmpxchgl%3, %1   \n\t"
-: "=a" (CompareValue),  // %0
-  "=m" (*Value) // %1
-: "a"  (CompareValue),  // %2
-  "r"  (ExchangeValue), // %3
-  "m"  (*Value) // %4
+"cmpxchgl%2, %1   \n\t"
+: "+a" (CompareValue),  // %0
+  "+m" (*Value) // %1
+: "r"  (ExchangeValue)  // %2
 : "memory",
   "cc"
 );
-- 
2.14.1.3.gb7cf6e02401b


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

[edk2] [PATCH 2/5] MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange16()

[Laszlo Ersek]

The CMPXCHG instruction has the following operands:
- AX (implicit, CompareValue):input and output
- destination operand (*Value):   input and output
- source operand (ExchangeValue): input

The IA32 version of InternalSyncCompareExchange16() correctly marks
CompareValue as input/output, but it marks (*Value) only as input.

The X64 version of InternalSyncCompareExchange16() attempts to mark both
CompareValue and (*Value) as input/output, but it doesn't use the
appropriate constraints for either operand.

Fix these issues. Furthermore, prefer the short "+" constraint for I/O
operands over the  constraint that can be applied
to the input instances of I/O operands.

Cc: Liming Gao 
Cc: Michael D Kinney 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c |  9 -
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 10 --
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index 1976720ac636..bd98a5aebfe7 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -115,11 +115,10 @@ InternalSyncCompareExchange16 (
 {
   __asm__ __volatile__ (
 "lock \n\t"
-"cmpxchgw%1, %2   \n\t"
-: "=a" (CompareValue)   // %0
-: "q"  (ExchangeValue), // %1
-  "m"  (*Value),// %2
-  "0"  (CompareValue)   // %3
+"cmpxchgw%2, %1   \n\t"
+: "+a" (CompareValue),  // %0
+  "+m" (*Value) // %1
+: "q"  (ExchangeValue)  // %2
 : "memory",
   "cc"
 );
diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
index 0212798d7a27..4338fb8e65e8 100644
--- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
@@ -115,12 +115,10 @@ InternalSyncCompareExchange16 (
 {
   __asm__ __volatile__ (
 "lock \n\t"
-"cmpxchgw%3, %1   \n\t"
-: "=a" (CompareValue),  // %0
-  "=m" (*Value) // %1
-: "a"  (CompareValue),  // %2
-  "r"  (ExchangeValue), // %3
-  "m"  (*Value) // %4
+"cmpxchgw%2, %1   \n\t"
+: "+a" (CompareValue),  // %0
+  "+m" (*Value) // %1
+: "r"  (ExchangeValue)  // %2
 : "memory",
   "cc"
 );
-- 
2.14.1.3.gb7cf6e02401b


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

[edk2] [PATCH 4/5] MdePkg/BaseSynchronizationLib GCC: fix X64 InternalSyncCompareExchange64()

[Laszlo Ersek]

(This patch is identical to the X64 half of the last one, except for the
InternalSyncCompareExchange32() -> InternalSyncCompareExchange64() and
"cmpxchgl" -> "cmpxchgq" replacements.)

The CMPXCHG instruction has the following operands:
- AX (implicit, CompareValue):input and output
- destination operand (*Value):   input and output
- source operand (ExchangeValue): input

The X64 version of InternalSyncCompareExchange64() attempts to mark both
CompareValue and (*Value) as input/output, but it doesn't use the
appropriate constraints for either operand.

Fix these issues. Furthermore, prefer the short "+" constraint for I/O
operands over the  constraint that can be applied
to the input instances of I/O operands.

Cc: Liming Gao 
Cc: Michael D Kinney 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
index a85cf0265c8b..edb904c00704 100644
--- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
@@ -194,12 +194,10 @@ InternalSyncCompareExchange64 (
 {
   __asm__ __volatile__ (
 "lock \n\t"
-"cmpxchgq%3, %1   \n\t"
-: "=a" (CompareValue),  // %0
-  "=m" (*Value) // %1
-: "a"  (CompareValue),  // %2
-  "r"  (ExchangeValue), // %3
-  "m"  (*Value) // %4
+"cmpxchgq%2, %1   \n\t"
+: "+a" (CompareValue),  // %0
+  "+m" (*Value) // %1
+: "r"  (ExchangeValue)  // %2
 : "memory",
   "cc"
 );
-- 
2.14.1.3.gb7cf6e02401b


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

[edk2] [PATCH 1/5] MdePkg/BaseSynchronizationLib GCC: fix whitespace and comments

[Laszlo Ersek]

The "GccInline.c" files have some inconsistent whitespace, and missing (or
incorrect) operand comments. Fix and unify them.

This patch doesn't change behavior.

Cc: Liming Gao 
Cc: Michael D Kinney 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1208
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 35 ++---
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 53 
+---
 2 files changed, 39 insertions(+), 49 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index fa2be7f4b35c..1976720ac636 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -39,7 +39,7 @@ InternalSyncIncrement (
 "movl$1, %%eax  \n\t"
 "lock   \n\t"
 "xadd%%eax, %1  \n\t"
-"inc %%eax  "
+"inc %%eax  \n\t"
 : "=a" (Result),  // %0
   "+m" (*Value)   // %1
 : // no inputs that aren't also outputs
@@ -48,7 +48,6 @@ InternalSyncIncrement (
 );
 
   return Result;
-
 }
 
 
@@ -76,10 +75,10 @@ InternalSyncDecrement (
 "movl$-1, %%eax  \n\t"
 "lock\n\t"
 "xadd%%eax, %1   \n\t"
-"dec %%eax  "
-: "=a" (Result),  // %0
-  "+m" (*Value)   // %1
-: // no inputs that aren't also outputs
+"dec %%eax   \n\t"
+: "=a" (Result),   // %0
+  "+m" (*Value)// %1
+:  // no inputs that aren't also outputs
 : "memory",
   "cc"
 );
@@ -87,6 +86,7 @@ InternalSyncDecrement (
   return Result;
 }
 
+
 /**
   Performs an atomic compare exchange operation on a 16-bit unsigned integer.
 
@@ -113,15 +113,13 @@ InternalSyncCompareExchange16 (
   IN  UINT16ExchangeValue
   )
 {
-
   __asm__ __volatile__ (
-" \n\t"
 "lock \n\t"
 "cmpxchgw%1, %2   \n\t"
-: "=a" (CompareValue)
-: "q"  (ExchangeValue),
-  "m"  (*Value),
-  "0"  (CompareValue)
+: "=a" (CompareValue)   // %0
+: "q"  (ExchangeValue), // %1
+  "m"  (*Value),// %2
+  "0"  (CompareValue)   // %3
 : "memory",
   "cc"
 );
@@ -129,6 +127,7 @@ InternalSyncCompareExchange16 (
   return CompareValue;
 }
 
+
 /**
   Performs an atomic compare exchange operation on a 32-bit unsigned integer.
 
@@ -155,15 +154,13 @@ InternalSyncCompareExchange32 (
   IN  UINT32ExchangeValue
   )
 {
-
   __asm__ __volatile__ (
-" \n\t"
 "lock \n\t"
 "cmpxchgl%1, %2   \n\t"
-: "=a" (CompareValue) // %0
-: "q"  (ExchangeValue),   // %1
-  "m"  (*Value),  // %2
-  "0"  (CompareValue) // %4
+: "=a" (CompareValue)   // %0
+: "q"  (ExchangeValue), // %1
+  "m"  (*Value),// %2
+  "0"  (CompareValue)   // %3
 : "memory",
   "cc"
 );
@@ -171,6 +168,7 @@ InternalSyncCompareExchange32 (
   return CompareValue;
 }
 
+
 /**
   Performs an atomic compare exchange operation on a 64-bit unsigned integer.
 
@@ -197,7 +195,6 @@ InternalSyncCompareExchange64 (
   )
 {
   __asm__ __volatile__ (
-"   \n\t"
 "push%%ebx  \n\t"
 "movl%2,%%ebx   \n\t"
 "lock   \n\t"
diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
index ab7efe23c4db..0212798d7a27 100644
--- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
@@ -39,7 +39,7 @@ InternalSyncIncrement (
 "movl$1, %%eax  \n\t"
 "lock   \n\t"
 "xadd%%eax, %1  \n\t"
-"inc %%eax  "
+"inc %%eax  \n\t"
 : "=a" (Result),  // %0
   "+m" (*Value)   // %1
 : // no inputs that aren't also outputs
@@ -75,10 +75,10 @@ InternalSyncDecrement (
 "movl$-1, %%eax  \n\t"
 "lock\n\t"
 "xadd%%eax, %1   \n\t"
-&q

[edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

[Laszlo Ersek]

Repo:   https://github.com/lersek/edk2.git
Branch: inline_asm_rw_ops_1208

This series mainly fixes the operand constraints (missing input-output
qualifications) in "BaseSynchronizationLib/*/GccInline.c".

(It would be better to remove these files altogether in favor of the
already existing NASM implementation, but due to
<https://bugzilla.tianocore.org/show_bug.cgi?id=881>, we can't generally
do that in libraries yet.)

Cc: Liming Gao 
Cc: Michael D Kinney 

Thanks,
Laszlo

Laszlo Ersek (5):
  MdePkg/BaseSynchronizationLib GCC: fix whitespace and comments
  MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange16()
  MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange32()
  MdePkg/BaseSynchronizationLib GCC: fix X64
InternalSyncCompareExchange64()
  MdePkg/BaseSynchronizationLib GCC: simplify IA32
InternalSyncCompareExchange64()

 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 +++--
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 47 
+++-
 2 files changed, 34 insertions(+), 55 deletions(-)

-- 
2.14.1.3.gb7cf6e02401b

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

Re: [edk2] [PATCH v3 0/5] [CVE-2017-5753] Bounds Check Bypass issue in SMI handlers

[Laszlo Ersek]

On 09/29/18 08:57, Hao Wu wrote:
> V3 changes:
> A. Fix wrong file (should be LoadFenceSmm.c) gets listed in
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> 
> B. Rename the newly introduced internal function from 'VariableLoadFence'
>to 'MemoryLoadFence' within
>MdeModulePkg/Universal/Variable/RuntimeDxe/
> 
> C. Remove extra empty line before EOF for files:
>MdePkg/Library/BaseLib/Ia32/Lfence.nasm
>MdePkg/Library/BaseLib/X64/Lfence.nasm
> 
> D. Remove dummy message within commit log messages
> 
> Since A. has functional impact. Thus send V3 of the series.

series
Acked-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

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

Re: [edk2] [Patch] UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h: Change to DOS format file.

[Laszlo Ersek]

On 09/29/18 03:37, Eric Dong wrote:
> Follow EDKII coding style, change file format to dos style.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1213
> 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h | 544 
> +++---
>  1 file changed, 272 insertions(+), 272 deletions(-)

Acked-by: Laszlo Ersek 

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

Re: [edk2] TCG MOR and processor caches

[Laszlo Ersek]

On 09/27/18 13:45, Laszlo Ersek wrote:
> On 09/27/18 12:59, Marc-André Lureau wrote:
>> Hi,
>>
>> According to "TCG Platform Reset Attack Mitigation Specification", if
>> MOR bit is set, "it must initiate a vendor-specific method that
>> overwrites all of system memory and the processor caches"
>>
>> In QuarkPlatformPkg/Platform/Pei/PlatformInit/MemoryCallback.c and
>> QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c, there is some
>> code to clear RAM, however I don't see code that would clear the
>> processor caches.
>>
>> For edk2/qemu, Paolo suggested it may be simpler to clear the cache
>> unconditionally. How would you implement that? Using
>> EFI_CPU_ARCH_PROTOCOL.FlushDataCache? (or direct AsmWbinvd call)
> 
> I would call the appropriate low-level BaseLib.h function somewhere in
> OvmfPkg/PlatformPei (unconditionally, yes). I haven't looked into
> AsmWbinvd(), but if that's the right function, call that. (Checking the
> Intel SDM re: WBINVD, I agree it could be the right one.)

BTW: I assume the caches should be flushed on all logical processors; is
that correct? If so, then EFI_PEI_MP_SERVICES_PPI will be needed, to run
AsmWbinvd() on all processors. Luckily, OvmfPkg/PlatformPei already uses
that service; see "OvmfPkg/PlatformPei/FeatureControl.c".

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

Re: [edk2] TCG MOR and processor caches

[Laszlo Ersek]

On 09/27/18 12:59, Marc-André Lureau wrote:
> Hi,
> 
> According to "TCG Platform Reset Attack Mitigation Specification", if
> MOR bit is set, "it must initiate a vendor-specific method that
> overwrites all of system memory and the processor caches"
> 
> In QuarkPlatformPkg/Platform/Pei/PlatformInit/MemoryCallback.c and
> QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c, there is some
> code to clear RAM, however I don't see code that would clear the
> processor caches.
> 
> For edk2/qemu, Paolo suggested it may be simpler to clear the cache
> unconditionally. How would you implement that? Using
> EFI_CPU_ARCH_PROTOCOL.FlushDataCache? (or direct AsmWbinvd call)

I would call the appropriate low-level BaseLib.h function somewhere in
OvmfPkg/PlatformPei (unconditionally, yes). I haven't looked into
AsmWbinvd(), but if that's the right function, call that. (Checking the
Intel SDM re: WBINVD, I agree it could be the right one.)

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

Re: [edk2] [PATCH] MdePkg/BaseSynchronizationLib: fix XADD operands in GCC IA32/X64 assembly

[Laszlo Ersek]

On 09/27/18 11:28, Shao, Ming wrote:
> Hi Laszlo,
>
> I build Ruiyu's code with gcc 4.8.5 as X64. And got below disassembled
> code:
>
> [cid:image002.jpg@01D45686.AFEDF140]
>
> So I didn't see register used as both destination and source of xadd
> instruction.
>
> Then I build your patch, and got exactly the same disassembled code.
>
> Both Ray's patch and yours can pass my test.

That's not surprising: the gcc documentation says that not marking
input-output operands as such may, or may not, break the code. Such a
bug in the operand list of the inline assembly is not *required* to
break the code, it just *can*. The only guarantee given is that, if the
input-output operands are all marked properly as such, then the code
will not break.

> Could you provide more details about your environment so I can
> reproduce this issue? Thanks.

Sure. My compiler version is the following (on RHEL-7.5 Workstation):

- gcc-4.8.5-28.el7_5.1.x86_64

Binutils (not that I think it matters in this case, but anyway):

- binutils-2.27-28.base.el7_5.1.x86_64

The OVMF build command line was:

  build \
-a X64 \
-p OvmfPkg/OvmfPkgX64.dsc \
-t GCC48 \
-b NOOPT \
-D SECURE_BOOT_ENABLE \
-D TLS_ENABLE \
-D NETWORK_IP6_ENABLE \
-D HTTP_BOOT_ENABLE \
-n 4 \
--report-file=.../build.ovmf.report \
--log=.../build.ovmf.log

It's very likely that the gcc version in RHEL-7.5 has a large number of
backports from later upstream changes. The base version is indeed 4.8.5,
but the internal build number is "-28.el7_5.1". That could mean a huge
number of patches. I'll append the relevant part of the RPM changelog at
the bottom of my email.

I'd just like to point out that this is not a gcc bug; the compiler
behaves according to its documentation.

Thanks,
Laszlo

> * Tue Mar 27 2018 Jeff Law  4.8.5-29
> - s390 retpoline support for spectre mitigation (#1552021)
>
> * Fri Jan 19 2018 Marek Polacek  4.8.5-28
> - Minor testsuite fixes to clean up test results (#1469697)
> - retpoline support for spectre mitigation (#1535655)
>
> * Thu Jan 11 2018 Marek Polacek  4.8.5-27
> - bump for rebuild with RELRO enabled even for ppc64/ppc64le
>
> * Thu Jan 04 2018 Jeff Law  4.8.5-26
> - Avoid red zone probing for zero residual dynamic allocation (#1469697)
> - Avoid bogus CFIs for probes in noreturn fucntions on x86/x86_64 (#1469697)
>
> * Tue Nov 14 2017 Jeff Law  4.8.5-25
> - Avoid red zone probe on aarch64 (#1469697)
>
> * Mon Nov 06 2017 Jeff Law  4.8.5-24
> - Sync gcc48-rh1469697-13 patch to upstream (#1469697)
> - Avoid probing in the red zone for noreturn functions (#1507980, #1469697)
> - Avoid infinite loop if probing interval is less than guard size (#1469697)
> - Fix debug information for large probing interval on aarch64 (#1469697)
> - Fix ICE on ppc port with large probing interval (#1469697)
>
> - rebuild to remove static relocations not known to older linkers (#1508968)
>
> * Thu Nov 02 2017 Marek Polacek  4.8.5-23
> - rebuild to remove static relocations not known to older linkers (#1508968)
>
> * Thu Oct 19 2017 Marek Polacek  4.8.5-22
> - fix gcc.c-torture/execute/pr80692.x
> - fix divmod expansion (PR middle-end/78416)
>
> * Wed Oct 18 2017 Marek Polacek  4.8.5-21
> - fix 27_io/basic_fstream/53984.cc
> - fix for classes with bases with mutable members (PR c++/77375)
> - fix handling side-effects of parameters (PR c/77767)
> - fix combine's make_extraction (PR rtl-optimization/78378)
> - fix gimplification of const var initialization from COND_EXPR (PR c++/80129)
> - fix -A / -B to A / B folding (PR middle-end/80362)
> - fix comparison of decimal float zeroes (PR middle-end/80692)
> - fix __mulv[dt]i3 and expand_mul_overflow (PR target/82274)
>
> * Thu Oct 12 2017 Marek Polacek  4.8.5-20
> - handle exceptions in basic_istream::sentry (#1469384)
> - don't run pr63354.c on ppc (#1468546)
> - ensure proxy privatization safety (#1491395)
> - fix incorrect codegen from rdseed intrinsic use (#1482762, CVE-2017-11671)
> - on aarch64, remove libatomic.so (#1465510)
>
> * Sun Oct 08 2017 Jeff Law  4.8.5-19
> - Backport stack clash protection from upstream (#1469697)
>
> * Fri Oct 06 2017 Marek Polacek  4.8.5-18
> - backport several -mprofile-kernel fixes (#1468546)
>
> * Thu Sep 14 2017 Marek Polacek  4.8.5-17
> - fix -mcpu=power8 atomic expansion (#1437220, PR target/69644)
> - fix .toc alignment (#1487434)
>
> * Thu Jun 01 2017 Marek Polacek  4.8.5-16
> - disable emitting profiling in functions marked with a special
>   attribute (#1457969)
>
> * Wed May 31 2017 Marek Polacek  4.8.5-15
> - properly apply the PR70549 patch (#1349067)
>
> * Mon Mar 13 2017 Marek Polacek  4.8.5-14
> - promote reloads of a PLUS to RELOAD_OTHER (#1402585)
>
> * Fri Mar 10 2017 Jakub Jelinek  4.8.5-13
> - add -mstack-protector-guard={tls,global}, -mstack-protector-guard-reg=
>   and -mstack-protector-guard-offset= options on ppc* (#1415952,
>   PR target/78875)
>
> * Tue Mar 07 2017 Jakub Jelinek  4.8.5-12
> - fix up 

Re: [edk2] [PATCH] MdePkg/BaseSynchronizationLib: fix XADD operands in GCC IA32/X64 assembly

[Laszlo Ersek]

On 09/26/18 11:34, Ni, Ruiyu wrote:
> On 9/26/2018 5:05 PM, Laszlo Ersek wrote:
>> Hi,
>>
>> On 09/25/18 21:48, Laszlo Ersek wrote:
>>> Currently, "gcc-4.8.5-28.el7_5.1.x86_64" generates the following code
>>> for
>>> me, from the XADD inline assembly added to "X64/GccInline.c" in commit
>>> 17634d026f96:
>>>
>>>> 4383 :
>>>> UINT32
>>>> EFIAPI
>>>> InternalSyncIncrement (
>>>>    IN  volatile UINT32    *Value
>>>>    )
>>>> {
>>>>  4383:   55  push   %rbp
>>>>  4384:   48 89 e5    mov    %rsp,%rbp
>>>>  4387:   48 83 ec 10 sub    $0x10,%rsp
>>>>  438b:   48 89 4d 10 mov    %rcx,0x10(%rbp)
>>>>    UINT32  Result;
>>>>
>>>>    __asm__ __volatile__ (
>>>>  438f:   48 8b 55 10 mov    0x10(%rbp),%rdx
>>>>  4393:   48 8b 45 10 mov    0x10(%rbp),%rax
>>>>  4397:   b8 01 00 00 00  mov    $0x1,%eax
>>>>  439c:   f0 0f c1 00 lock xadd %eax,(%rax)
>>>>  43a0:   ff c0   inc    %eax
>>>>  43a2:   89 45 fc    mov    %eax,-0x4(%rbp)
>>>>  : "m"  (*Value)   // %2
>>>>  : "memory",
>>>>    "cc"
>>>>  );
>>>>
>>>>    return Result;
>>>>  43a5:   8b 45 fc    mov    -0x4(%rbp),%eax
>>>> }
>>>>  43a8:   c9  leaveq
>>>>  43a9:   c3  retq
>>>>
>>>
>>> The MOV $0X1,%EAX instruction corrupts the address of Value in %RAX
>>> before
>>> we reach the XADD instruction. In fact, it makes no sense for XADD to
>>> use
>>> %EAX as source operand and (%RAX) as destination operand at the same
>>> time.
>>
>> may I get a fast review for this patch, please? The regression from
>> commit 17634d026f96 prevents OVMF from booting.
> 
> Sure. Reviewed-by: Ruiyu Ni 

Thanks, Ray! Commit 8a94eb9283fa.
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseSynchronizationLib: fix XADD operands in GCC IA32/X64 assembly

[Laszlo Ersek]

Hi,

On 09/25/18 21:48, Laszlo Ersek wrote:
> Currently, "gcc-4.8.5-28.el7_5.1.x86_64" generates the following code for
> me, from the XADD inline assembly added to "X64/GccInline.c" in commit
> 17634d026f96:
> 
>> 4383 :
>> UINT32
>> EFIAPI
>> InternalSyncIncrement (
>>   IN  volatile UINT32*Value
>>   )
>> {
>> 4383:   55  push   %rbp
>> 4384:   48 89 e5mov%rsp,%rbp
>> 4387:   48 83 ec 10 sub$0x10,%rsp
>> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>>   UINT32  Result;
>>
>>   __asm__ __volatile__ (
>> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
>> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
>> 4397:   b8 01 00 00 00  mov$0x1,%eax
>> 439c:   f0 0f c1 00 lock xadd %eax,(%rax)
>> 43a0:   ff c0   inc%eax
>> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
>> : "m"  (*Value)   // %2
>> : "memory",
>>   "cc"
>> );
>>
>>   return Result;
>> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
>> }
>> 43a8:   c9  leaveq
>> 43a9:   c3  retq
>>
> 
> The MOV $0X1,%EAX instruction corrupts the address of Value in %RAX before
> we reach the XADD instruction. In fact, it makes no sense for XADD to use
> %EAX as source operand and (%RAX) as destination operand at the same time.

may I get a fast review for this patch, please? The regression from
commit 17634d026f96 prevents OVMF from booting.

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

Re: [edk2] [PATCH] UefiCpuPkg/CpuMpPei: fix unsafe way to get stack pointer

[Laszlo Ersek]

On 09/26/18 04:18, Wang, Jian J wrote:
> Hi,
> 
> Since the patch will introduce "#if defined(...)" macro in code, which 
> violates
> edk2 coding style, it's suggested to add exception to static checker.
> 
> I'll wait for one or two days in case there's other suggestions. If no 
> objection
> then, I'll withdraw this patch and close BZ#1186 as not-fix.

If we can *selectively* suppress this one warning from the static
checker (saying that "yeah we know what we are doing"), then I agree
WONTFIX is acceptable for the BZ. It's not optimal IMO (I think there
would be value in a generic facility for getting the stack pointer --
several places in edk2 want to know the stack pointer), but it is
acceptable. (As far as I'm concerned anyway.)

Thanks
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, September 19, 2018 7:17 PM
>> To: Justen, Jordan L ; Wang, Jian J
>> ; edk2-devel@lists.01.org
>> Cc: Wu, Hao A ; Bi, Dandan ;
>> Dong, Eric ; Kinney, Michael D
>> 
>> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuMpPei: fix unsafe way to get stack
>> pointer
>>
>> On 09/18/18 20:02, Jordan Justen wrote:
>>> I guess the git config sendemail.from setting did not help your
>>> patches. ?? It still is coming through with a From field of
>>> .
>>>
>>> Regarding this patch, I suppose it is worth asking if  in
>>> the old code could possibly be an address not on the stack. I don't
>>> think it is possible, and I'm guessing the C specification would
>>> probably back that up.
>>>
>>> It can be unsafe to get an address of something on the stack and then
>>> refer to that address after the variable is no longer in scope. I
>>> suspect this is what the static checker is noticing. By calling
>>> SetJump, aren't we just doing the same thing, but hiding what we are
>>> doing from the static checker?
>>
>> Yep, we're totally doing that.
>>
>> Thanks,
>> Laszlo
>>
>>>
>>> So, can't we just tell the static checker to ignore the error because
>>> we know what we are doing?
>>>
>>> -Jordan
>>>
>>> On 2018-09-18 02:04:48,  wrote:
>>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1186
>>>>
>>>> This patch uses SetJump() to get the stack pointer from esp/rsp
>>>> register to replace local variable way, which was marked by static
>>>> code checker as an unsafe way.
>>>>
>>>> Cc: Dandan Bi 
>>>> Cc: Hao A Wu 
>>>> Cc: Eric Dong 
>>>> Cc: Laszlo Ersek 
>>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>> Signed-off-by: Jian J Wang 
>>>> ---
>>>>  UefiCpuPkg/CpuMpPei/CpuMpPei.h  | 8 
>>>>  UefiCpuPkg/CpuMpPei/CpuPaging.c | 9 +++--
>>>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
>> b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
>>>> index d097a66aa8..fe61f5e3bc 100644
>>>> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
>>>> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
>>>> @@ -35,6 +35,14 @@
>>>>
>>>>  extern EFI_PEI_PPI_DESCRIPTOR   mPeiCpuMpPpiDesc;
>>>>
>>>> +#if   defined (MDE_CPU_IA32)
>>>> +#define CPU_STACK_POINTER(Context)  ((Context).Esp)
>>>> +#elif defined (MDE_CPU_X64)
>>>> +#define CPU_STACK_POINTER(Context)  ((Context).Rsp)
>>>> +#else
>>>> +#error CPU type not supported!
>>>> +#endif
>>>> +
>>>>  /**
>>>>This service retrieves the number of logical processor in the platform
>>>>and the number of those logical processors that are enabled on this 
>>>> boot.
>>>> diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c
>> b/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>>> index c7e0822452..997c20c26e 100644
>>>> --- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>>> +++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>>> @@ -517,9 +517,14 @@ GetStackBase (
>>>>IN OUT VOID *Buffer
>>>>)
>>>>  {
>>>> -  EFI_PHYSICAL_ADDRESSStackBase;
>>>> +  EFI_PHYSICAL_ADDRESS  StackBase;
>>>> +  BASE_LIBRARY_JUMP_BUFFER  Context;
>>>>
>>>> -  StackBase = (EFI_PHYSICAL_ADDRESS)(UINTN)
>>>> +  //
>>>> +  // Retrieve stack pointer from current processor context.
>>>> +  //
>>>> +  SetJump ();
>>>> +  StackBase = (EFI_PHYSICAL_ADDRESS)CPU_STACK_POINTER (Context);
>>>>StackBase += BASE_4KB;
>>>>StackBase &= ~((EFI_PHYSICAL_ADDRESS)BASE_4KB - 1);
>>>>StackBase -= PcdGet32(PcdCpuApStackSize);
>>>> --
>>>> 2.16.2.windows.1
>>>>
>>>> ___
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [PATCH v2 0/5] [CVE-2017-5753] Bounds Check Bypass issue in SMI handlers

[Laszlo Ersek]

On 09/25/18 22:51, Laszlo Ersek wrote:
> On 09/25/18 08:12, Hao Wu wrote:
>> V2 changes:
>> A. Rename the newly introduced BaseLib API to 'AsmLfence', and makes it
>>IA32/X64 specific.
>>
>> B. Add brief comments before calls of the AsmLfence() to state the
>>purpose.
>>
>> C. Refine the patch for Variable/RuntimeDxe driver and make the change
>>focus on the SMM code.
>>
>> V1 history:
>> The series aims to mitigate the Bounds Check Bypass (CVE-2017-5753) issues
>> within SMI handlers.
>>
>> A more detailed explanation of the purpose of the series is under the
>> 'Bounds check bypass mitigation' section of the below link:
>> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
>>
>> And the document at:
>> https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf
>>
>> Cc: Ard Biesheuvel 
>> Cc: Leif Lindholm 
>> Cc: Laszlo Ersek 
>> Cc: Jiewen Yao 
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Star Zeng 
>> Cc: Eric Dong 
>>
>> Hao Wu (5):
>>   MdePkg/BaseLib: Add new AsmLfence API
>>   MdeModulePkg/FaultTolerantWrite:[CVE-2017-5753]Fix bounds check bypass
>>   MdeModulePkg/SmmLockBox: [CVE-2017-5753] Fix bounds check bypass
>>   MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass
>>   UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5753] Fix bounds check bypass
>>
>>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c   |  7 
>> 
>>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf |  1 
>> +
>>  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c | 10 
>> ++
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c  | 31 
>> 
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c  | 30 
>> 
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h  | 13 
>> ++-
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c  |  6 
>> 
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf  |  1 
>> +
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   | 18 
>> ++
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |  1 
>> +
>>  MdePkg/Include/Library/BaseLib.h   | 13 
>> +++
>>  MdePkg/Library/BaseLib/BaseLib.inf |  2 
>> ++
>>  MdePkg/Library/BaseLib/Ia32/Lfence.nasm| 37 
>> +++
>>  MdePkg/Library/BaseLib/X64/Lfence.nasm | 38 
>> 
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  5 
>> +++
>>  15 files changed, 212 insertions(+), 1 deletion(-)
>>  create mode 100644 MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
>>  create mode 100644 MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
>>  create mode 100644 MdePkg/Library/BaseLib/Ia32/Lfence.nasm
>>  create mode 100644 MdePkg/Library/BaseLib/X64/Lfence.nasm
>>
> 
> I regression-tested this series using:
> 
> (1) roughly the Linux guest steps from
> <https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#tests-to-perform-in-the-installed-guest-fedora-26-guest>.
> 
> 
> Those steps cover all of the SMM variable driver, the SMM FTW driver,
> the SMM lockbox, and PiSmmCpuDxeSmm.
> 
> (2) For briefly checking the runtime (non-SMM) variable driver, I booted
> Fedora guests on X64 OVMF and AARCH64 ArmVirtQemu, and invoked
> "efibootmgr -v".
> 
> series
> Regression-tested-by: Laszlo Ersek 

It's been a long day. I meant to describe another detail of the test
environment:

Because of the regression reported at
<https://bugzilla.tianocore.org/show_bug.cgi?id=1207>, OVMF is currently
unbootable. Therefore I first applied my fix from
<https://bugzilla.tianocore.org/show_bug.cgi?id=1207#c2> on top of
current master (3cb0a311cb7e). I applied this series of yours for
regression testing on top of my fix.

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

Re: [edk2] [PATCH v2 0/5] [CVE-2017-5753] Bounds Check Bypass issue in SMI handlers

[Laszlo Ersek]

On 09/25/18 08:12, Hao Wu wrote:
> V2 changes:
> A. Rename the newly introduced BaseLib API to 'AsmLfence', and makes it
>IA32/X64 specific.
> 
> B. Add brief comments before calls of the AsmLfence() to state the
>purpose.
> 
> C. Refine the patch for Variable/RuntimeDxe driver and make the change
>focus on the SMM code.
> 
> V1 history:
> The series aims to mitigate the Bounds Check Bypass (CVE-2017-5753) issues
> within SMI handlers.
> 
> A more detailed explanation of the purpose of the series is under the
> 'Bounds check bypass mitigation' section of the below link:
> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
> 
> And the document at:
> https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Star Zeng 
> Cc: Eric Dong 
> 
> Hao Wu (5):
>   MdePkg/BaseLib: Add new AsmLfence API
>   MdeModulePkg/FaultTolerantWrite:[CVE-2017-5753]Fix bounds check bypass
>   MdeModulePkg/SmmLockBox: [CVE-2017-5753] Fix bounds check bypass
>   MdeModulePkg/Variable: [CVE-2017-5753] Fix bounds check bypass
>   UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5753] Fix bounds check bypass
> 
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c   |  7 
> 
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf |  1 +
>  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c | 10 
> ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c  | 31 
> 
>  MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c  | 30 
> 
>  MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h  | 13 
> ++-
>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c  |  6 
> 
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf  |  1 +
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   | 18 
> ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |  1 +
>  MdePkg/Include/Library/BaseLib.h   | 13 
> +++
>  MdePkg/Library/BaseLib/BaseLib.inf |  2 
> ++
>  MdePkg/Library/BaseLib/Ia32/Lfence.nasm| 37 
> +++
>  MdePkg/Library/BaseLib/X64/Lfence.nasm | 38 
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  5 
> +++
>  15 files changed, 212 insertions(+), 1 deletion(-)
>  create mode 100644 MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
>  create mode 100644 MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
>  create mode 100644 MdePkg/Library/BaseLib/Ia32/Lfence.nasm
>  create mode 100644 MdePkg/Library/BaseLib/X64/Lfence.nasm
> 

I regression-tested this series using:

(1) roughly the Linux guest steps from
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#tests-to-perform-in-the-installed-guest-fedora-26-guest>.


Those steps cover all of the SMM variable driver, the SMM FTW driver,
the SMM lockbox, and PiSmmCpuDxeSmm.

(2) For briefly checking the runtime (non-SMM) variable driver, I booted
Fedora guests on X64 OVMF and AARCH64 ArmVirtQemu, and invoked
"efibootmgr -v".

series
Regression-tested-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v2 5/5] NetworkPkg/UefiPxeBcDxe: Use the specified MTFTP windowsize.

[Laszlo Ersek]

On 09/25/18 03:11, Jiaxin Wu wrote:
> *v2: Since the new PCD (PcdPxeTftpWindowSize) was renamed/defined in
> NetworkPkg instead of MdeModulePkg, this new version is to update the
> consuming PXE driver.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886
>
> This patch is to use the specified MTFTP windowsize to benefit the PXE
> download performance.
>
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Shao Ming 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c  |  10 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcMtftp.c | 137 +--
>  NetworkPkg/UefiPxeBcDxe/PxeBcMtftp.h |   6 +-
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf |   3 +
>  4 files changed, 121 insertions(+), 35 deletions(-)

I compared this variant against the v1 posting. The difference is very
small (as you explain in the blurb):

> diff --git a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf 
> b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> index 949596c029be..e2a0eb44b1fc 100644
> --- a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +++ b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> @@ -55,6 +55,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  NetworkPkg/NetworkPkg.dec
>
>
>  [LibraryClasses]
> @@ -107,7 +108,7 @@ [Guids]
>
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdTftpBlockSize  ## SOMETIMES_CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdTftpWindowSize ## SOMETIMES_CONSUMES
> +  gEfiNetworkPkgTokenSpaceGuid.PcdPxeTftpWindowSize## SOMETIMES_CONSUMES
>
>  [UserExtensions.TianoCore."ExtraFiles"]
>UefiPxeBcDxeExtra.uni
> diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c 
> b/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> index db463d1b11fb..468b38d887d8 100644
> --- a/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> +++ b/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> @@ -874,9 +874,9 @@ EfiPxeBcMtftp (
>Mode  = Private->PxeBc.Mode;
>
>//
> -  // Get PcdTftpWindowSize.
> +  // Get PcdPxeTftpWindowSize.
>//
> -  WindowSize   = (UINTN) PcdGet64 (PcdTftpWindowSize);
> +  WindowSize = (UINTN) PcdGet64 (PcdPxeTftpWindowSize);
>
>if (Mode->UsingIpv6) {
>  if (!NetIp6IsValidUnicast (>v6)) {

Also, the renaming of the PCD hasn't changed its default value (4), its
data type (UINT64), or its "flavor" ([PcdsFixedAtBuild,
PcdsPatchableInModule]). Therefore, in this specific case, I think we
should carry forward my T-b for this patch (patch #5) as well, from:

bbd4d8e9-6470-8cc8-ff7d-6b154adbd7ce@redhat.com">http://mid.mail-archive.com/bbd4d8e9-6470-8cc8-ff7d-6b154adbd7ce@redhat.com

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

Re: [edk2] [PATCH v2 4/5] NetworkPkg: Define one PCD for PXE to specify MTFTP windowsize.

[Laszlo Ersek]

On 09/25/18 03:11, Jiaxin Wu wrote:
> *v2: Rename and redefine the PCD in NetworkPkg instead of MdeModulePkg.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886
> 
> This patch is to define one new PCD for PXE driver to specify MTFTP 
> windowsize so as
> to improve the PXE download performance. The default value is set to 4.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Shao Ming 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/NetworkPkg.dec | 6 ++
>  NetworkPkg/NetworkPkg.uni | 6 ++
>  2 files changed, 12 insertions(+)

git-am complained about trailing whitespace:

> diff --git a/NetworkPkg/NetworkPkg.dec b/NetworkPkg/NetworkPkg.dec
> index aae36226d5..aa721d8315 100644
> --- a/NetworkPkg/NetworkPkg.dec
> +++ b/NetworkPkg/NetworkPkg.dec
> @@ -90,10 +90,16 @@
># TRUE  - HTTP connections are allowed. Both the "https://; and "http://; 
> URI schemes are permitted.
># FALSE - HTTP connections are denied. Only the "https://; URI scheme is 
> permitted.
># @Prompt Indicates whether HTTP connections are permitted or not.
>
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|FALSE|BOOLEAN|0x0008
>  
> +  ## This setting is to specify the MTFTP windowsize used by UEFI PXE 
> driver. 

(1) here

> +  # A value of 0 indicates the default value of windowsize(1). 

(2) here

> +  # A non-zero value will be used as windowsize.
> +  # @Prompt PXE TFTP windowsize.
> +  gEfiNetworkPkgTokenSpaceGuid.PcdPxeTftpWindowSize|0x4|UINT64|0x1008  

(3) here

> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## IPv6 DHCP Unique Identifier (DUID) Type configuration (From RFCs 3315 
> and 6355).
># 01 = DUID Based on Link-layer Address Plus Time [DUID-LLT]
># 04 = UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
># 02 = DUID Assigned by Vendor Based on Enterprise Number [DUID-EN] (not 
> supported)
> diff --git a/NetworkPkg/NetworkPkg.uni b/NetworkPkg/NetworkPkg.uni
> index 5604b1bf32..07585680e3 100644
> --- a/NetworkPkg/NetworkPkg.uni
> +++ b/NetworkPkg/NetworkPkg.uni
> @@ -53,10 +53,16 @@
>  
>  #string STR_gEfiNetworkPkgTokenSpaceGuid_PcdAllowHttpConnections_HELP  
> #language en-US "Indicates whether HTTP connections are permitted or not.\n"
>   
>   "TRUE  - HTTP connections are allowed.\n"
>   
>   "FALSE - HTTP connections are denied."
>  
> +#string STR_gEfiNetworkPkgTokenSpaceGuid_PcdPxeTftpWindowSize_PROMPT  
> #language en-US "This setting is to specify the MTFTP windowsize used by UEFI 
> PXE driver."
> +
> +#string STR_gEfiNetworkPkgTokenSpaceGuid_PcdPxeTftpWindowSize_HELP  
> #language en-US "Specify MTFTP windowsize used by UEFI PXE driver.\n"
> + 
>"A value of 0 indicates the default value of windowsize(1).\n"
> +     
>"A non-zero value will be used as windowsize." 
>   

(4) and here.

With those fixed:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> +
>  #string STR_gEfiNetworkPkgTokenSpaceGuid_PcdIpsecCertificateEnabled_PROMPT  
> #language en-US "Enable IPsec IKEv2 Certificate Authentication."
>  
>  #string STR_gEfiNetworkPkgTokenSpaceGuid_PcdIpsecCertificateEnabled_HELP  
> #language en-US "Indicates if the IPsec IKEv2 Certificate Authentication 
> feature is enabled or not.\n"
>   
>  "TRUE  - Certificate Authentication feature is enabled.\n"
>   
>  "FALSE - Does not support Certificate Authentication."
> 

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

Re: [edk2] [PATCH v2 0/5] Support windowsize to benefit tftp/pxe download performance.

[Laszlo Ersek]

On 09/25/18 03:11, Jiaxin Wu wrote:
> *v2: The first three patches(1/2/3) are the same with version 1, just update 
> the last two
> patches (4/5):
> I)  windowsize.>
> This patch has been discarded since we rename and redefine the PCD in 
> NetworkPkg instead 
> of MdeModulePkg. The replacement is: 
> [PATCH v2 4/5] NetworkPkg: Define one PCD for PXE to specify MTFTP windowsize.
> II) 
> Since the new PCD (PcdPxeTftpWindowSize) was renamed/defined in NetworkPkg 
> instead of 
> MdeModulePkg, we udpate the consuming PXE driver. The new version patch is:
> [PATCH v2 5/5] NetworkPkg/UefiPxeBcDxe: Use the specified MTFTP windowsize.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886
> 
> The series patches are to support the TFTP windowsize option described in RFC 
> 7440.
> TFTP shell command and UEFI PXE driver will use the feature to benefit the 
> download 
> performance.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Carsey Jaben 
> Cc: Shao Ming 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> 
> Jiaxin Wu (5):
>   MdeModulePke/Mtftp4Dxe: Support windowsize in read request operation.
>   NetworkPkg/Mtftp6Dxe: Support windowsize in read request operation.
>   ShellPkg/TftpDynamicCommand: Add one option for tftp command to
> specify windowsize.
>   NetworkPkg: Define one PCD for PXE to specify MTFTP windowsize.
>   NetworkPkg/UefiPxeBcDxe: Use the specified MTFTP windowsize.

You didn't include the (unchanged) patches #1 through #3 from the v1
series in this posting. Hence, a reminder: please don't forget to pick
up my T-b for patches #1 and #2, from:

bbd4d8e9-6470-8cc8-ff7d-6b154adbd7ce@redhat.com">http://mid.mail-archive.com/bbd4d8e9-6470-8cc8-ff7d-6b154adbd7ce@redhat.com

I'll comment more elsewhere under the v2 posting.

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

[edk2] [PATCH] MdePkg/BaseSynchronizationLib: fix XADD operands in GCC IA32/X64 assembly

[Laszlo Ersek]

Currently, "gcc-4.8.5-28.el7_5.1.x86_64" generates the following code for
me, from the XADD inline assembly added to "X64/GccInline.c" in commit
17634d026f96:

> 4383 :
> UINT32
> EFIAPI
> InternalSyncIncrement (
>   IN  volatile UINT32*Value
>   )
> {
> 4383:   55  push   %rbp
> 4384:   48 89 e5mov%rsp,%rbp
> 4387:   48 83 ec 10 sub$0x10,%rsp
> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>   UINT32  Result;
>
>   __asm__ __volatile__ (
> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
> 4397:   b8 01 00 00 00  mov$0x1,%eax
> 439c:   f0 0f c1 00 lock xadd %eax,(%rax)
> 43a0:   ff c0   inc%eax
> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
> : "m"  (*Value)   // %2
> : "memory",
>   "cc"
> );
>
>   return Result;
> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
> }
> 43a8:   c9  leaveq
> 43a9:   c3  retq
>

The MOV $0X1,%EAX instruction corrupts the address of Value in %RAX before
we reach the XADD instruction. In fact, it makes no sense for XADD to use
%EAX as source operand and (%RAX) as destination operand at the same time.

The XADD instruction's destination operand is a read-write operand. The
GCC documentation states:

> The ordinary output operands must be write-only; GCC will assume that
> the values in these operands before the instruction are dead and need
> not be generated. Extended asm supports input-output or read-write
> operands. Use the constraint character `+' to indicate such an operand
> and list it with the output operands. You should only use read-write
> operands when the constraints for the operand (or the operand in which
> only some of the bits are to be changed) allow a register.

(The above is intentionally quoted from the oldest GCC release that edk2
supports, namely gcc-4.4:
<https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Extended-Asm.html>.)

Fix the operand list accordingly.

With the patch applied, I get:

> 4383 :
> UINT32
> EFIAPI
> InternalSyncIncrement (
>   IN  volatile UINT32*Value
>   )
> {
> 4383:   55  push   %rbp
> 4384:   48 89 e5mov%rsp,%rbp
> 4387:   48 83 ec 10 sub$0x10,%rsp
> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>   UINT32  Result;
>
>   __asm__ __volatile__ (
> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
> 4397:   b8 01 00 00 00  mov$0x1,%eax
> 439c:   f0 0f c1 02 lock xadd %eax,(%rdx)
> 43a0:   ff c0   inc%eax
> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
> : // no inputs that aren't also outputs
> : "memory",
>   "cc"
> );
>
>   return Result;
> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
> }
> 43a8:   c9  leaveq
> 43a9:   c3  retq

Note that some other bugs remain in
"BaseSynchronizationLib/*/GccInline.c"; those should be addressed later,
under <https://bugzilla.tianocore.org/show_bug.cgi?id=1208>.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Cc: Ruiyu Ni 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1207
Fixes: 17634d026f968c404b039a8d8431b6389dd396ea
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: xadd_rw

 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 12 ++--
 MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index d82e0205f553..fa2be7f4b35c 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -38,11 +38,11 @@ InternalSyncIncrement (
   __asm__ __volatile__ (
 "movl$1, %%eax  \n\t"
 "lock   \n\t"
-"xadd%%eax, %2  \n\t"
+"xadd%%eax, %1  \n\t"
 "inc %%eax  "
 : "=a" (Result),  // %0
-  "=m" (*Value)   // %1
-: &qu

Re: [edk2] [PATCH v3] MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

[Laszlo Ersek]

On 09/25/18 20:29, Laszlo Ersek wrote:

> So here's what I'm going to do. I will submit a standalone, "surgical"
> patch, for fixing the regression introduced in 17634d026f96.

Filed <https://bugzilla.tianocore.org/show_bug.cgi?id=1207> about that.

> Additionally, I will file a TianoCore BZ about the *other* bugs in
> GccInline.c, and suggest that we fix those issues by eliminating the
> GCC-specific variant altogether.

That one is <https://bugzilla.tianocore.org/show_bug.cgi?id=1208>.

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

Re: [edk2] [PATCH v3] MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

[Laszlo Ersek]

On 09/25/18 18:18, Laszlo Ersek wrote:
> On 09/25/18 16:22, Laszlo Ersek wrote:
>> On 09/13/18 11:50, Ruiyu Ni wrote:
>>
>>> diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
>>> b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>>> index 5224dd063f..4c4d6e3fc7 100644
>>> --- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>>> +++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>>> @@ -15,14 +15,12 @@
>>>
>>>
>>>
>>> -
>>>  /**
>>>Performs an atomic increment of an 32-bit unsigned integer.
>>>
>>>Performs an atomic increment of the 32-bit unsigned integer specified by
>>>Value and returns the incremented value. The increment operation must be
>>> -  performed using MP safe mechanisms. The state of the return value is not
>>> -  guaranteed to be MP safe.
>>> +  performed using MP safe mechanisms.
>>>
>>>@param  Value A pointer to the 32-bit value to increment.
>>>
>>> @@ -38,9 +36,10 @@ InternalSyncIncrement (
>>>UINT32  Result;
>>>
>>>__asm__ __volatile__ (
>>> +"movl$1, %%eax  \n\t"
>>>  "lock   \n\t"
>>> -"incl%2 \n\t"
>>> -"mov %2, %%eax  "
>>> +"xadd%%eax, %2  \n\t"
>>> +"inc %%eax  "
>>>  : "=a" (Result),  // %0
>>>"=m" (*Value)   // %1
>>>  : "m"  (*Value)   // %2
>>
>> The operand list for the inline assembly is incorrect, I suspect. When I
>> build this code with GCC48 as part of OVMF, for the NOOPT target, then
>> disassemble "CpuMpPei.debug", I get:
>>
>>> 4383 :
>>> UINT32
>>> EFIAPI
>>> InternalSyncIncrement (
>>>   IN  volatile UINT32*Value
>>>   )
>>> {
>>> 4383:   55  push   %rbp
>>> 4384:   48 89 e5mov%rsp,%rbp
>>> 4387:   48 83 ec 10 sub$0x10,%rsp
>>> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>>>   UINT32  Result;
>>>
>>>   __asm__ __volatile__ (
>>> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
>>> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
>>> 4397:   b8 01 00 00 00  mov$0x1,%eax
>>> 439c:   f0 0f c1 00 lock xadd %eax,(%rax)
>>> 43a0:   ff c0   inc%eax
>>> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
>>> : "m"  (*Value)   // %2
>>> : "memory",
>>>   "cc"
>>> );
>>>
>>>   return Result;
>>> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
>>> }
>>> 43a8:   c9  leaveq
>>> 43a9:   c3  retq
>>>
>>
>> The generated code is trying to use EAX for both (a) the
>> exchange-and-add, i.e.  as the source operand of the XADD instruction,
>> and (b) as (part of) the address of the (*Value) argument.
>>
>> In effect, before we reach the XADD instruction, the least significant
>> dword of Value's address is overwritten with 0x_0001. The exchange
>> then happens against that memory location.
>>
>> It is interesting that GCC first spills the parameter from RCX to the
>> stack, and then it loads the parameter from the stack to both RDX and
>> RAX.
>>
>> I think the operand list used with the inline assembly should be updated
>> to prevent GCC from associating %2 with EAX.
>>
>> I'll try to experiment some more.
> 
> The operand lists for almost all of the functions in
> 
> - MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
> - MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
> 
> are wrong. The InternalSyncIncrement() and InternalSyncDecrement() issue
> has now bitten us in practice. The InternalSyncCompareExchangeXx()
> functions also have incorrect operand lists, they just haven't blown up yet.
> 
> The core problem is that input-output operands for the inline assembly
> templates must be marked as such. The GCC documentation describes two
> ways for that:
> 
> - List the r/w operand only in the output operand list, and use the "+"
> (not "=") constraint.
> 

Re: [edk2] [PATCH v3] MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

[Laszlo Ersek]

On 09/25/18 16:22, Laszlo Ersek wrote:
> On 09/13/18 11:50, Ruiyu Ni wrote:
> 
>> diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
>> b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>> index 5224dd063f..4c4d6e3fc7 100644
>> --- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>> +++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
>> @@ -15,14 +15,12 @@
>>
>>
>>
>> -
>>  /**
>>Performs an atomic increment of an 32-bit unsigned integer.
>>
>>Performs an atomic increment of the 32-bit unsigned integer specified by
>>Value and returns the incremented value. The increment operation must be
>> -  performed using MP safe mechanisms. The state of the return value is not
>> -  guaranteed to be MP safe.
>> +  performed using MP safe mechanisms.
>>
>>@param  Value A pointer to the 32-bit value to increment.
>>
>> @@ -38,9 +36,10 @@ InternalSyncIncrement (
>>UINT32  Result;
>>
>>__asm__ __volatile__ (
>> +"movl$1, %%eax  \n\t"
>>  "lock   \n\t"
>> -"incl%2 \n\t"
>> -"mov %2, %%eax  "
>> +"xadd%%eax, %2  \n\t"
>> +"inc %%eax  "
>>  : "=a" (Result),  // %0
>>"=m" (*Value)   // %1
>>  : "m"  (*Value)   // %2
> 
> The operand list for the inline assembly is incorrect, I suspect. When I
> build this code with GCC48 as part of OVMF, for the NOOPT target, then
> disassemble "CpuMpPei.debug", I get:
> 
>> 4383 :
>> UINT32
>> EFIAPI
>> InternalSyncIncrement (
>>   IN  volatile UINT32*Value
>>   )
>> {
>> 4383:   55  push   %rbp
>> 4384:   48 89 e5mov%rsp,%rbp
>> 4387:   48 83 ec 10 sub$0x10,%rsp
>> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>>   UINT32  Result;
>>
>>   __asm__ __volatile__ (
>> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
>> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
>> 4397:   b8 01 00 00 00  mov$0x1,%eax
>> 439c:   f0 0f c1 00 lock xadd %eax,(%rax)
>> 43a0:   ff c0   inc%eax
>> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
>> : "m"  (*Value)   // %2
>> : "memory",
>>   "cc"
>> );
>>
>>   return Result;
>> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
>> }
>> 43a8:   c9  leaveq
>> 43a9:   c3  retq
>>
> 
> The generated code is trying to use EAX for both (a) the
> exchange-and-add, i.e.  as the source operand of the XADD instruction,
> and (b) as (part of) the address of the (*Value) argument.
> 
> In effect, before we reach the XADD instruction, the least significant
> dword of Value's address is overwritten with 0x_0001. The exchange
> then happens against that memory location.
> 
> It is interesting that GCC first spills the parameter from RCX to the
> stack, and then it loads the parameter from the stack to both RDX and
> RAX.
> 
> I think the operand list used with the inline assembly should be updated
> to prevent GCC from associating %2 with EAX.
> 
> I'll try to experiment some more.

The operand lists for almost all of the functions in

- MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
- MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c

are wrong. The InternalSyncIncrement() and InternalSyncDecrement() issue
has now bitten us in practice. The InternalSyncCompareExchangeXx()
functions also have incorrect operand lists, they just haven't blown up yet.

The core problem is that input-output operands for the inline assembly
templates must be marked as such. The GCC documentation describes two
ways for that:

- List the r/w operand only in the output operand list, and use the "+"
(not "=") constraint.

- Alternatively, list the operand in both input and output lists, and
use the "=" constraint in the output list. However, in the input list,
the constraing must be "N" (a decimal number), where N stands for the
operand number in the output list. This is how GCC knows those operands
are actually the same. Using just the same *expression* to fill in the
two instances (= input and output) of the operand is not guaranteed to
work; the gcc documentation explicitly highlights this fact.

In addition, in the ASM template, operands can be referenced by "[name]"
instead of %N. This has been supported since at least gcc-3.1. This
makes the template a lot more readable.

I'm working on a patch set.

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

Re: [edk2] [PATCH v3] MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

[Laszlo Ersek]

On 09/13/18 11:50, Ruiyu Ni wrote:

> diff --git a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c 
> b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
> index 5224dd063f..4c4d6e3fc7 100644
> --- a/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
> +++ b/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
> @@ -15,14 +15,12 @@
>
>
>
> -
>  /**
>Performs an atomic increment of an 32-bit unsigned integer.
>
>Performs an atomic increment of the 32-bit unsigned integer specified by
>Value and returns the incremented value. The increment operation must be
> -  performed using MP safe mechanisms. The state of the return value is not
> -  guaranteed to be MP safe.
> +  performed using MP safe mechanisms.
>
>@param  Value A pointer to the 32-bit value to increment.
>
> @@ -38,9 +36,10 @@ InternalSyncIncrement (
>UINT32  Result;
>
>__asm__ __volatile__ (
> +"movl$1, %%eax  \n\t"
>  "lock   \n\t"
> -"incl%2 \n\t"
> -"mov %2, %%eax  "
> +"xadd%%eax, %2  \n\t"
> +"inc %%eax  "
>  : "=a" (Result),  // %0
>"=m" (*Value)   // %1
>  : "m"  (*Value)   // %2

The operand list for the inline assembly is incorrect, I suspect. When I
build this code with GCC48 as part of OVMF, for the NOOPT target, then
disassemble "CpuMpPei.debug", I get:

> 4383 :
> UINT32
> EFIAPI
> InternalSyncIncrement (
>   IN  volatile UINT32*Value
>   )
> {
> 4383:   55  push   %rbp
> 4384:   48 89 e5mov%rsp,%rbp
> 4387:   48 83 ec 10 sub$0x10,%rsp
> 438b:   48 89 4d 10 mov%rcx,0x10(%rbp)
>   UINT32  Result;
>
>   __asm__ __volatile__ (
> 438f:   48 8b 55 10 mov0x10(%rbp),%rdx
> 4393:   48 8b 45 10 mov0x10(%rbp),%rax
> 4397:   b8 01 00 00 00  mov$0x1,%eax
> 439c:   f0 0f c1 00 lock xadd %eax,(%rax)
> 43a0:   ff c0   inc%eax
> 43a2:   89 45 fcmov%eax,-0x4(%rbp)
> : "m"  (*Value)   // %2
> : "memory",
>   "cc"
> );
>
>   return Result;
> 43a5:   8b 45 fcmov-0x4(%rbp),%eax
> }
> 43a8:   c9  leaveq
> 43a9:   c3  retq
>

The generated code is trying to use EAX for both (a) the
exchange-and-add, i.e.  as the source operand of the XADD instruction,
and (b) as (part of) the address of the (*Value) argument.

In effect, before we reach the XADD instruction, the least significant
dword of Value's address is overwritten with 0x_0001. The exchange
then happens against that memory location.

It is interesting that GCC first spills the parameter from RCX to the
stack, and then it loads the parameter from the stack to both RDX and
RAX.

I think the operand list used with the inline assembly should be updated
to prevent GCC from associating %2 with EAX.

I'll try to experiment some more.

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

Re: [edk2] [PATCH v3] MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

[Laszlo Ersek]

Hi,

On 09/13/18 11:50, Ruiyu Ni wrote:
> Today's InterlockedIncrement()/InterlockedDecrement() guarantees to
> perform atomic increment/decrement but doesn't guarantee the return
> value equals to the new value.
>
> The patch fixes the behavior to use "XADD" instruction to guarantee
> the return value equals to the new value.
>
> The patch calls intrinsic functions for MSVC tool chain, calls the
> NASM implementation for INTEL tool chain and calls GCC inline
> assembly implementation (GccInline.c) for GCC tool chain.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> ---
>  MdePkg/Include/Library/SynchronizationLib.h|  6 +--
>  .../BaseSynchronizationLib.inf | 18 -
>  .../BaseSynchronizationLibInternals.h  |  6 +--
>  .../BaseSynchronizationLib/Ia32/GccInline.c| 18 -
>  .../Ia32/InterlockedDecrement.c| 42 -
>  .../Ia32/InterlockedDecrement.nasm | 10 ++---
>  .../Ia32/InterlockedIncrement.c| 43 
> --
>  .../Ia32/InterlockedIncrement.nasm |  7 ++--
>  ...lockedDecrement.c => InterlockedDecrementMsc.c} |  4 +-
>  ...lockedIncrement.c => InterlockedIncrementMsc.c} |  4 +-
>  .../BaseSynchronizationLib/Synchronization.c   |  6 +--
>  .../BaseSynchronizationLib/SynchronizationGcc.c|  6 +--
>  .../BaseSynchronizationLib/SynchronizationMsc.c|  6 +--
>  .../Library/BaseSynchronizationLib/X64/GccInline.c | 19 +-
>  .../X64/InterlockedDecrement.nasm  |  8 ++--
>  .../X64/InterlockedIncrement.nasm  |  5 ++-
>  16 files changed, 56 insertions(+), 152 deletions(-)
>  delete mode 100644 
> MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedDecrement.c
>  delete mode 100644 
> MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedIncrement.c
>  rename MdePkg/Library/BaseSynchronizationLib/{X64/InterlockedDecrement.c => 
> InterlockedDecrementMsc.c} (87%)
>  rename MdePkg/Library/BaseSynchronizationLib/{X64/InterlockedIncrement.c => 
> InterlockedIncrementMsc.c} (87%)

This patch (commit 17634d026f96) has regressed OVMF on KVM. Here's the
bisection log:

> git bisect start
> # bad: [17634d026f968c404b039a8d8431b6389dd396ea] MdePkg/SynchronizationLib: 
> fix Interlocked[De|In]crement return value
> git bisect bad 17634d026f968c404b039a8d8431b6389dd396ea
> # good: [997731e796f51df57c113dfd966e818622c3d4aa] UefiCpuPkg: Remove 
> redundant library classes, Ppis and GUIDs
> git bisect good 997731e796f51df57c113dfd966e818622c3d4aa
> # good: [b602265d559b2f2ade4d09ba55652c23922c141f] MdeModulePkg 
> RegularExpressionDxe: Update Oniguruma to 6.9.0
> git bisect good b602265d559b2f2ade4d09ba55652c23922c141f
> # good: [d5b28edd63f4d0fab087c5d6c9db773e5b5adc7d] MdePkg: Add a inf path in 
> MdePkg.dsc
> git bisect good d5b28edd63f4d0fab087c5d6c9db773e5b5adc7d
> # good: [ca3e4f8ab82485edff2cfa7eeb87f71b4be38966] MdePkg 
> UefiPciLibPciRootBridgeIo: Remove redundant dependency
> git bisect good ca3e4f8ab82485edff2cfa7eeb87f71b4be38966
> # first bad commit: [17634d026f968c404b039a8d8431b6389dd396ea] 
> MdePkg/SynchronizationLib: fix Interlocked[De|In]crement return value

The symptom is that the boot gets stuck, with all VCPUs spinning, after
the following log is produced:

> Loading PEIM [CpuMpPei]
> Loading PEIM at 0x000BFEA8000 EntryPoint=0x000BFEADE86 CpuMpPei.efi
> Register PPI Notify: [EfiPeiMemoryDiscoveredPpi]
> Notify: PPI Guid: [EfiPeiMemoryDiscoveredPpi], Peim notify entry point: 
> BFEB53B1
> AP Loop Mode is 1
> WakeupBufferStart = 9F000, WakeupBufferSize = 1000

MpInitLib uses SynchronizationLib:

> UefiCpuPkg/Library/MpInitLib/Microcode.c:241:  
> AcquireSpinLock(>MpLock);
> UefiCpuPkg/Library/MpInitLib/Microcode.c:244:  
> ReleaseSpinLock(>MpLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:117:  AcquireSpinLock (>ApLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:119:  ReleaseSpinLock (>ApLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:555:
> AcquireSpinLock(>MpLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:557:
> ReleaseSpinLock(>MpLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:560:  
> InitializeSpinLock(>CpuData[ProcessorNumber].ApLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:609:  InterlockedIncrement ((UINT32 
> *) >CpuCount);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:637:  InterlockedCompareExchange32 (
> UefiCpuPkg/Library/MpInitLib/MpLib.c:706:InterlockedIncrement ((UINT32 *) 
> >FinishedCount);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:707:InterlockedDecrement ((UINT32 *) 
> >MpCpuExchangeInfo->NumApsExecuting);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:775:  while 
> (InterlockedCompareExchange32 (
> UefiCpuPkg/Library/MpInitLib/MpLib.c:1645:  
> InitializeSpinLock(>MpLock);
> UefiCpuPkg/Library/MpInitLib/MpLib.c:1718:  
> InitializeSpinLock(>CpuData[Index].ApLock);

I'll 

Re: [edk2] [PATCH v2 1/5] MdePkg/BaseLib: Add new AsmLfence API

[Laszlo Ersek]

Hi Hao,

On 09/25/18 08:12, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1193
> 
> This commit will add a new BaseLib API AsmLfence(). This API will perform
> a serializing operation on all load-from-memory instructions that were
> issued prior to the call of this function. Please note that this API is
> only available on IA-32 and x64.
> 
> The purpose of adding this API is to mitigate of the [CVE-2017-5753]
> Bounds Check Bypass issue when untrusted data are being processed within
> SMM. More details can be referred at the 'Bounds check bypass mitigation'
> section at the below link:
> 
> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdePkg/Include/Library/BaseLib.h| 13 +++
>  MdePkg/Library/BaseLib/BaseLib.inf  |  2 ++
>  MdePkg/Library/BaseLib/Ia32/Lfence.nasm | 37 +++
>  MdePkg/Library/BaseLib/X64/Lfence.nasm  | 38 
>  4 files changed, 90 insertions(+)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 123ae19dc2..656b7736b1 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -9139,6 +9139,19 @@ AsmWriteTr (
>);
>  
>  /**
> +  Performs a serializing operation on all load-from-memory instructions that
> +  were issued prior the AsmLfence function.
> +
> +  Executes a LFENCE instruction. This function is only available on IA-32 
> and x64.
> +
> +**/
> +VOID
> +EFIAPI
> +AsmLfence (
> +  VOID
> +  );
> +
> +/**
>Patch the immediate operand of an IA32 or X64 instruction such that the 
> byte,
>word, dword or qword operand is encoded at the end of the instruction's
>binary representation.
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index a1b5ec4b75..ed15c025f9 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -68,6 +68,7 @@
>  
>  [Sources.Ia32]
>Ia32/WriteTr.nasm
> +  Ia32/Lfence.nasm
>  
>Ia32/Wbinvd.c | MSFT
>Ia32/WriteMm7.c | MSFT
> @@ -346,6 +347,7 @@
>X64/EnableCache.nasm
>X64/DisableCache.nasm
>X64/WriteTr.nasm
> +  X64/Lfence.nasm
>  
>X64/CpuBreakpoint.c | MSFT
>X64/WriteMsr64.c | MSFT
> diff --git a/MdePkg/Library/BaseLib/Ia32/Lfence.nasm 
> b/MdePkg/Library/BaseLib/Ia32/Lfence.nasm
> new file mode 100644
> index 00..f8b2550ef8
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/Ia32/Lfence.nasm
> @@ -0,0 +1,37 @@
> +;--
>  ;
> +; Copyright (c) 2018, Intel Corporation. All rights reserved.
> +; This program and the accompanying materials
> +; are licensed and made available under the terms and conditions of the BSD 
> License
> +; which accompanies this distribution.  The full text of the license may be 
> found at
> +; http://opensource.org/licenses/bsd-license.php.
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +;
> +; Module Name:
> +;
> +;   Lfence.nasm
> +;
> +; Abstract:
> +;
> +;   Performs a serializing operation on all load-from-memory instructions 
> that
> +;   were issued prior to the call of this function.
> +;
> +; Notes:
> +;
> +;--
> +
> +SECTION .text
> +
> +;--
> +; VOID
> +; EFIAPI
> +; AsmLfence (
> +;   VOID
> +;   );
> +;--
> +global ASM_PFX(AsmLfence)
> +ASM_PFX(AsmLfence):
> +lfence
> +ret
> +
> diff --git a/MdePkg/Library/BaseLib/X64/Lfence.nasm 
> b/MdePkg/Library/BaseLib/X64/Lfence.nasm
> new file mode 100644
> index 00..e81c77964b
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/X64/Lfence.nasm
> @@ -0,0 +1,38 @@
> +;--
>  ;
> +; Copyright (c) 2018, Intel Corporation. All rights reserved.
> +; This program and the accompanying materials
> +; are licensed and made available under the terms and conditions of the BSD 
> License
> +; which acco

Re: [edk2] [PATCH v2 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5753] Fix bounds check bypass

[Laszlo Ersek]

On 09/25/18 08:12, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1194
> 
> Speculative execution is used by processor to avoid having to wait for
> data to arrive from memory, or for previous operations to finish, the
> processor may speculate as to what will be executed.
> 
> If the speculation is incorrect, the speculatively executed instructions
> might leave hints such as which memory locations have been brought into
> cache. Malicious actors can use the bounds check bypass method (code
> gadgets with controlled external inputs) to infer data values that have
> been used in speculative operations to reveal secrets which should not
> otherwise be accessed.
> 
> It is possible for SMI handler(s) to call EFI_SMM_CPU_PROTOCOL service
> ReadSaveState() and use the content in the 'CommBuffer' (controlled
> external inputs) as the 'CpuIndex'. So this commit will insert AsmLfence
> API to mitigate the bounds check bypass issue within SmmReadSaveState().
> 
> For SmmReadSaveState():
> 
> The 'CpuIndex' will be passed into function ReadSaveStateRegister(). And
> then in to ReadSaveStateRegisterByIndex().
> 
> With the call:
> ReadSaveStateRegisterByIndex (
>   CpuIndex,
>   SMM_SAVE_STATE_REGISTER_IOMISC_INDEX,
>   sizeof(IoMisc.Uint32),
>   
>   );
> 
> The 'IoMisc' can be a cross boundary access during speculative execution.
> Later, 'IoMisc' is used as the index to access buffers 'mSmmCpuIoWidth'
> and 'mSmmCpuIoType'. One can observe which part of the content within
> those buffers was brought into cache to possibly reveal the value of
> 'IoMisc'.
> 
> Hence, this commit adds a AsmLfence() after the check of 'CpuIndex'
> within function SmmReadSaveState() to prevent the speculative execution.
> 
> A more detailed explanation of the purpose of commit is under the
> 'Bounds check bypass mitigation' section of the below link:
> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
> 
> And the document at:
> https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf
> 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael D Kinney 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> 
> cb pismm

Before you push this version (or when preparing a v3, if necessary),
please remove the above stray text, from the end of the commit message.

I've now looked over this series. I didn't try to verify whether the
lfence instructions had been added at right places, or whether they had
been added at *all* the right places. However, structurally the series
looks OK to me.

series
Acked-by: Laszlo Ersek 

I will follow up with regression test results.

Thanks
Laszlo

> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index fbf74e8d90..19979d5418 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -237,6 +237,11 @@ SmmReadSaveState (
>if ((CpuIndex >= gSmst->NumberOfCpus) || (Buffer == NULL)) {
>  return EFI_INVALID_PARAMETER;
>}
> +  //
> +  // The AsmLfence() call here is to ensure the above check for the CpuIndex
> +  // has been completed before the execution of subsequent codes.
> +  //
> +  AsmLfence ();
>  
>//
>// Check for special EFI_SMM_SAVE_STATE_REGISTER_PROCESSOR_ID
> 

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

Re: [edk2] [PATCH v2 4/4] MdeModulePkg/PciHostBridge: Move declaration of mIoMmu to header file

[Laszlo Ersek]

On 09/25/18 08:21, Ruiyu Ni wrote:
> The change doesn't have functionality impact.
> It just renames the mIoMmuProtocol to mIoMmu and moves the\
> declaration from PciRootBridgeIo.c to PciHostBridge.h.

Before pushing the patch, please remove the stray backslash from the
commit message.

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

Re: [edk2] [PATCH v2 4/4] MdeModulePkg/PciHostBridge: Move declaration of mIoMmu to header file

[Laszlo Ersek]

turn Status;
>}
>  
> @@ -1413,11 +1411,11 @@ RootBridgeIoUnmap (
>PCI_ROOT_BRIDGE_INSTANCE *RootBridge;
>EFI_STATUSStatus;
>  
> -  if (mIoMmuProtocol != NULL) {
> -Status = mIoMmuProtocol->Unmap (
> -   mIoMmuProtocol,
> -   Mapping
> -   );
> +  if (mIoMmu != NULL) {
> +Status = mIoMmu->Unmap (
> +   mIoMmu,
> +   Mapping
> +   );
>  return Status;
>}
>  
> @@ -1539,21 +1537,21 @@ RootBridgeIoAllocateBuffer (
>  
>RootBridge = ROOT_BRIDGE_FROM_THIS (This);
>  
> -  if (mIoMmuProtocol != NULL) {
> +  if (mIoMmu != NULL) {
>  if (!RootBridge->DmaAbove4G) {
>//
>// Clear DUAL_ADDRESS_CYCLE
>//
>Attributes &= ~((UINT64) EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE);
>  }
> -Status = mIoMmuProtocol->AllocateBuffer (
> -   mIoMmuProtocol,
> -   Type,
> -   MemoryType,
> -   Pages,
> -   HostAddress,
> -   Attributes
> -   );
> +Status = mIoMmu->AllocateBuffer (
> +   mIoMmu,
> +   Type,
> +   MemoryType,
> +   Pages,
> +   HostAddress,
> +   Attributes
> +       );
>  return Status;
>}
>  
> @@ -1603,12 +1601,12 @@ RootBridgeIoFreeBuffer (
>  {
>EFI_STATUSStatus;
>  
> -  if (mIoMmuProtocol != NULL) {
> -Status = mIoMmuProtocol->FreeBuffer (
> -   mIoMmuProtocol,
> -   Pages,
> -   HostAddress
> -   );
> +  if (mIoMmu != NULL) {
> +Status = mIoMmu->FreeBuffer (
> +   mIoMmu,
> +   Pages,
> +   HostAddress
> +   );
>  return Status;
>}
>  
> 

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

Re: [edk2] [Patch 6/6] NetworkPkg/UefiPxeBcDxe: Add the clarification compared to UefiPxeBcDxe in MdeModulePkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to UefiPxeBcDxe in MdeModulePkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf 
> b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> index e2a0eb44b1..f2ec34df93 100644
> --- a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +++ b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> @@ -1,12 +1,17 @@
>  ## @file
>  #  Access PXE-compatible devices for network access and network booting.
>  #
>  #  This driver provides PXE Base Code Protocol which is used to accessing
> -#  PXE-compatible device for network access or booting. It could work 
> together
> -#  with an IPv4 stack, an IPv6 stack or both.
> +#  PXE-compatible device for network access or booting. This driver supports 
> +#  both IPv4 and IPv6 network stack.
>  #
> +#  Notes: 
> +#  1) This driver can't co-work with the UefiPxeBcDxe driver in 
> MdeModulePkg. 
> +#  2) This driver includes more bugs fix and supports more features (e.g. 
> IPv6, 
> +# MTFTP windowsize) than the UefiPxeBcDxe driver in MdeModulePkg. So, we 
> +# recommand to use this driver even both of them can be used.
>  #
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> 

Same comments as for patch #4. With those updates:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [Patch 5/6] NetworkPkg/IScsiDxe: Add the clarification compared to IScsiDxe in MdeModulePkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to IScsiDxe in MdeModulePkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/IScsiDxe/IScsiDxe.inf | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/NetworkPkg/IScsiDxe/IScsiDxe.inf 
> b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> index 61a0693a07..007418fd9c 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDxe.inf
> +++ b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> @@ -1,10 +1,20 @@
>  ## @file
>  #  Client-side iSCSI service.
>  #
>  #  The iSCSI driver provides iSCSI service in the preboot environment and 
> supports
> -#  booting over iSCSI.
> +#  booting over iSCSI. This driver supports both IPv4 and IPv6 network stack.
> +#
> +#  Notes: 
> +#  1) This driver can't co-work with the IScsiDxe driver in MdeModulePkg. 
> +#  2) This driver includes more bugs fix and supports more features (e.g. 
> IPv6, Dns 
> +# support for target URL configuration, iSCSI keyword support) than the 
> IscsiDxe 
> +# driver in MdeModulePkg. So, we recommand to use this driver even both 
> of them 
> +# can be used.

Same comments as for patch #4.

> +#  3) This driver depends on the OpenSSL building. To use this driver, 
> please follow 

I suggest "on the OpenSSL building" --> "on OpenSSL".

> +# the instructions found in the file "Patch-HOWTO.txt" located in 
> +# CryptoPkg\Library\OpensslLib to enable the OpenSSL building first.

The "Patch-HOWTO.txt" file no longer exists; it's now called
"OpenSSL-HOWTO.txt".

With those fixed:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

>  #
>  # Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the BSD 
> License
>  # which accompanies this distribution.  The full text of the license may be 
> found at
> 

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

Re: [edk2] [Patch 4/6] NetworkPkg/TcpDxe: Add the clarification compared to Tcp4Dxe in MdeModulePkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to Tcp4Dxe in MdeModulePkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/TcpDxe/TcpDxe.inf | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/TcpDxe/TcpDxe.inf b/NetworkPkg/TcpDxe/TcpDxe.inf
> index eb693a147f..56cfd16b98 100644
> --- a/NetworkPkg/TcpDxe/TcpDxe.inf
> +++ b/NetworkPkg/TcpDxe/TcpDxe.inf
> @@ -1,12 +1,17 @@
>  ## @file
>  #  TCPv4 I/O and TCPv6 I/O services.
>  #
>  #  This module provides EFI TCPv4 Protocol and EFI TCPv6 Protocol to send 
> and receive data stream.
> -#  It might provide TCPv4 Protocol or TCPv6 Protocol or both of them that 
> depends on
> -#  which network stack has been loaded in system.
> +#  It might provide TCPv4 Protocol or TCPv6 Protocol or both of them that 
> depends on which network 
> +#  stack has been loaded in system. This driver supports both IPv4 and IPv6 
> network stack.
>  #
> +#  Notes: 
> +#  1) This driver can't co-work with the Tcp4Dxe driver in MdeModulePkg. 
> +#  2) This driver includes more bugs fix and supports more features (e.g. 
> IPv6, TCP Cancel 

suggestion: "bugs fix" --> "bug fixes"

> +# function) than the Tcp4Dxe driver in MdeModulePkg. So, we recommand to 
> use this driver 

suggestion: "recommand to use" --> "recommend using"

> +# even both of them can be used.

"even" --> "even though"

With those:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

>  #
>  #  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> 

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

Re: [edk2] [Patch 3/6] MdeModulePkg/UefiPxeBcDxe: Add the clarification compared to UefiPxeBcDxe in NetworkPkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to UefiPxeBcDxe in NetworkPkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  .../Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf   | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf 
> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> index b5b9e80710..0fef0058bd 100644
> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> @@ -2,11 +2,20 @@
>  #  This module produces EFI Preboot Execution Environment (PXE) Base Code 
> Protocol.
>  #
>  #  This module produces EFI PXE Base Code Protocol upon EFI MMP Protocl and 
> IPv4
>  #  network stack, used to control PXE-compatible devices. It produces EFI 
> Load File
>  #  Protocol to provide one clean way to otain control from the boot manager 
> if the
> -#  boot patch is from the remote device.
> +#  boot patch is from the remote device. This driver only supports IPv4 
> network stack.
> +#
> +#  Notes: 
> +#  1) This driver can't co-work with the UefiPxeBcDxe driver in NetworkPkg. 
> +#  2) This driver might have some issues that have been fixed in the 
> UefiPxeBcDxe 
> +# driver in NetworkPkg. 
> +#  3) This driver supports less feature than the UefiPxeBcDxe driver in 
> NetworkPkg 
> +# (e.g. IPv6, MTFTP windowsize).
> +#  4) UefiPxeBcDxe driver in NetworkPkg is recommanded to use instead of 
> this one even 
> +# both of them can be used.
>  #
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
>  #  which accompanies this distribution. The full text of the license may be 
> found at
> 

Same comments as for patch #1. With those addressed:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [Patch 2/6] MdeModulePkg/IScsiDxe: Add the clarification compared to IScsiDxe in NetworkPkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to IScsiDxe in NetworkPkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf 
> b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
> index c3b8c7d15a..cd6a2ef843 100644
> --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
> +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
> @@ -2,11 +2,21 @@
>  #  This module produces EFI iSCSI Initiator Name Protocol.
>  #
>  #  This module produces EFI iSCSI Initiator Name Protocol upon EFI TCPv4 
> Protocol
>  #  and EFI DHCPv4 Protocol, to provide the capability to do the transport 
> for SCSI
>  #  data over TCP/IP. It installs EFI HII Configuration Access Protocol to 
> provide
> -#  one way to configurate the iSCSI setting.
> +#  one way to configurate the iSCSI setting. This driver only supports IPv4 
> network 
> +#  stack.
> +#
> +#  Notes: 
> +#  1) This driver can't co-work with the IScsiDxe driver in NetworkPkg. 
> +#  2) This driver might have some issues that have been fixed in the 
> IScsiDxe driver 
> +# in NetworkPkg.
> +#  3) This driver supports less feature than the IScsiDxe driver in 
> NetworkPkg 
> +# (e.g. IPv6, Dns support for target URL configuration, iSCSI keyword 
> support).
> +#  4) IScsiDxe driver in NetworkPkg is recommanded to use instead of this 
> one even 
> +# both of them can be used.
>  #
>  #  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
>  #  which accompanies this distribution.  The full text of the license may be 
> found at
> 

Same comments as for patch #1. With those addressed:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [Patch 1/6] MdeModulePkg/Tcp4Dxe: Add the clarification compared to TcpDxe in NetworkPkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to TcpDxe in NetworkPkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf 
> b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> index b54321caaa..0561eb7421 100644
> --- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> +++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> @@ -1,10 +1,20 @@
>  ## @file
>  #  This module produces EFI TCPv4 Protocol and EFI TCPv4 Service Binding 
> Protocol.
>  #
>  #  This module produces EFI TCPv4(Transmission Control Protocol version 4) 
> Protocol
> -#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services.
> +#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services. This driver 
> only 
> +#  supports IPv4 network stack.
> +#
> +#  Notes: 
> +#  1) This driver can't co-work with the TcpDxe driver in NetworkPkg. 
> +#  2) This driver might have some issues that have been fixed in the TcpDxe 
> driver 
> +# in NetworkPkg. 
> +#  3) This driver supports less feature than the TcpDxe driver in NetworkPkg 
> (e.g. IPv6, 
> +# TCP Cancel function). 
> +#  4) TcpDxe driver in NetworkPkg is recommanded to use instead of this one 
> even both 
> +# of them can be used.

Sorry, a few more suggestions:

- "recommanded to use" --> "recommended for use" (both typo fix and
grammar fix)

- "even" --> "even though".

Anyway I don't think it's necessary to repost the patch just because of
this.

Thanks!
Laszlo



>  #
>  #  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
>  #  which accompanies this distribution. The full text of the license may be 
> found at
> 

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

Re: [edk2] [Patch 1/6] MdeModulePkg/Tcp4Dxe: Add the clarification compared to TcpDxe in NetworkPkg.

[Laszlo Ersek]

On 09/25/18 05:44, Jiaxin Wu wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205
> 
> This patch is to add the driver usage/difference clarification
> compared to TcpDxe in NetworkPkg.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf 
> b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> index b54321caaa..0561eb7421 100644
> --- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> +++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> @@ -1,10 +1,20 @@
>  ## @file
>  #  This module produces EFI TCPv4 Protocol and EFI TCPv4 Service Binding 
> Protocol.
>  #
>  #  This module produces EFI TCPv4(Transmission Control Protocol version 4) 
> Protocol
> -#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services.
> +#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services. This driver 
> only 
> +#  supports IPv4 network stack.
> +#
> +#  Notes: 
> +#  1) This driver can't co-work with the TcpDxe driver in NetworkPkg. 
> +#  2) This driver might have some issues that have been fixed in the TcpDxe 
> driver 
> +# in NetworkPkg. 
> +#  3) This driver supports less feature than the TcpDxe driver in NetworkPkg 
> (e.g. IPv6, 
> +# TCP Cancel function). 

I suggest replacing "less feature" with "fewer features".

Looks good to me, otherwise.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> +#  4) TcpDxe driver in NetworkPkg is recommanded to use instead of this one 
> even both 
> +# of them can be used.
>  #
>  #  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
>  #  which accompanies this distribution. The full text of the license may be 
> found at
> 

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

Re: [edk2] [Patch v3 00/14] Update MSR definitions

[Laszlo Ersek]

On 09/25/18 04:08, Eric Dong wrote:
> Current MSR definition are follow the SDM 2016-09 version. The latest SDM is 
> 2018-05. This patch serial update the MSR related definition to follow the 
> latest SDM 2018-05 version. MSR related defintion are saved at 
> UefiCpuPkg\Include\Register\.
> 
> V3 changes includes:
> 1. Only change Patch 8 and 14 which changed MSR data structures.
> 2. Keep ReservedX not change if bit info not changed for this field.

series
Acked-by: Laszlo Ersek 

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

Re: [edk2] [Question] Testing environment regarding SMM driver

[Laszlo Ersek]

On 09/21/18 20:15, poxyran wrote:
> Hello again,
> 
> my question is: is it possible to create a SMM driver that
> installs/register a SMI handler (in order to call it from a usermode app
> in the OS) and test it in the UEFI Shell or do I need to setup up a
> dedicated machine with the SMM stack as described in official EDK II
> documentation [1]?
> 
> [1]
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

These questions are not "either/or", they are orthogonal.

Normally, any pre-existent platform firmware will keep you, as a 3rd
party UEFI developer, *out* of SMM. Doing otherwise would be a huge
security hole. However, if you own the platform in question (meaning you
can build and install the firmware to the platform), then you should be
able to use whatever the SMM infrastructure has to offer. It does not
matter whether you do this on a physical UEFI development platform, or
in OVMF + QEMU/KVM. As long as you get sufficient access to the platform
itself. I hope this answers Q1.

Regarding the wiki article. I wrote that article mainly for developers
with a Windows desktop background. That's why I recommend to set up a
separate, headless Linux server. Because, running Linux as the host OS,
you get to run OVMF on QEMU not just with software emulation (TCG) but
with hardware virtualization (KVM). And the latter makes for a world of
difference. If you work at a Windows shop, you can run virtualization
clients (management tools) on your Windows desktop, and with them,
connect to the Linux server for managing / running your firmware.

If you already work on a Linux laptop, you should be able to run OVMF on
QEMU/KVM using nothing but your laptop. In such cases, the libvirt
client and server components, and QEMU, and the host kernel (KVM), and
OVMF, build up the "virt stack" on a single machine.

Whether you can do the *exact* things you want to do, within OVMF, I
can't tell. I don't know what you mean to do. A good part of the edk2
SMM stack is built into OVMF with SMM_REQUIRE, but (due to QEMU/KVM
being a virtual platform), at least *some* artifacts of physical
hardware will be necessarily missing. (Such as SMRR, movable LAPIC base,
etc.) OVMF also does not include/provide a number of standardized SMM
abstractions, such as EFI_PEI_SMM_COMMUNICATION_PPI. (That's by choice,
BTW.)

I vaguely recall that Ray used OVMF as a testbed for some SMM driver he
was developing at some point. I think Ray was using Q35 because of that
(i.e. SMM), and his use case also included CSM, and that's why he wrote
commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region
manipulation of Q35", 2016-03-15). But I could be totally imagining things.

If you run

  git log --reverse --grep=SMM -- OvmfPkg

you'll get a good amount of documentation about OVMF's SMM support. The
first large series was 8786ba4fe722..5e04f4b7e1a4, but things didn't
stop with that, of course. The OvmfPkg/README file has some notes on SMM
too.

I think you should be able to imitate the variable driver split, for
your use case. You can write a runtime DXE driver that exposes a custom
protocol. You can write a UEFI app (to be started from the UEFI shell)
that locates and calls this protocol. In the implementation of the new
runtime protocol, you can use EFI_SMM_COMMUNICATION_PROTOCOL to send
message buffers into SMM. (Actually you could do this directly in your
UEFI app too.) I expect you should be able to write a DXE_SMM_DRIVER
driver too that registered a hook for the message sent. I don't recall
all the details off-hand, but it's very well specified in the Platform
Init spec. I hope this helps with Q2.

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

Re: [edk2] [PATCH 3/3] MdeModulePkg/PciHostBridge: Add RESOURCE_VALID() to simplify code

[Laszlo Ersek]

On 09/21/18 09:25, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Star Zeng 
> ---
>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 26 
> ++
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index f6234b5d11..916709e276 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -21,6 +21,8 @@ extern EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
>  
>  #define NO_MAPPING  (VOID *) (UINTN) -1
>  
> +#define RESOURCE_VALID(R) ((R).Base <= (R).Limit)
> +
>  //
>  // Lookup table for increment values based on transfer widths
>  //
> @@ -122,25 +124,25 @@ CreateRootBridge (
>//
>// Make sure Mem and MemAbove4G apertures are valid
>//
> -  if (Bridge->Mem.Base <= Bridge->Mem.Limit) {
> +  if (RESOURCE_VALID (Bridge->Mem)) {
>  ASSERT (Bridge->Mem.Limit < SIZE_4GB);
>  if (Bridge->Mem.Limit >= SIZE_4GB) {
>return NULL;
>  }
>}
> -  if (Bridge->MemAbove4G.Base <= Bridge->MemAbove4G.Limit) {
> +  if (RESOURCE_VALID (Bridge->MemAbove4G)) {
>  ASSERT (Bridge->MemAbove4G.Base >= SIZE_4GB);
>  if (Bridge->MemAbove4G.Base < SIZE_4GB) {
>return NULL;
>  }
>}
> -  if (Bridge->PMem.Base <= Bridge->PMem.Limit) {
> +  if (RESOURCE_VALID (Bridge->PMem)) {
>  ASSERT (Bridge->PMem.Limit < SIZE_4GB);
>  if (Bridge->PMem.Limit >= SIZE_4GB) {
>return NULL;
>  }
>}
> -  if (Bridge->PMemAbove4G.Base <= Bridge->PMemAbove4G.Limit) {
> +  if (RESOURCE_VALID (Bridge->PMemAbove4G)) {
>  ASSERT (Bridge->PMemAbove4G.Base >= SIZE_4GB);
>  if (Bridge->PMemAbove4G.Base < SIZE_4GB) {
>return NULL;
> @@ -157,11 +159,9 @@ CreateRootBridge (
>// support separate windows for Non-prefetchable and Prefetchable
>// memory.
>//
> -  ASSERT (Bridge->PMem.Base > Bridge->PMem.Limit);
> -  ASSERT (Bridge->PMemAbove4G.Base > Bridge->PMemAbove4G.Limit);
> -  if ((Bridge->PMem.Base <= Bridge->PMem.Limit) ||
> -  (Bridge->PMemAbove4G.Base <= Bridge->PMemAbove4G.Limit)
> -  ) {
> +  ASSERT (!RESOURCE_VALID (Bridge->PMem));
> +  ASSERT (!RESOURCE_VALID (Bridge->PMemAbove4G));
> +  if (RESOURCE_VALID (Bridge->PMem) || RESOURCE_VALID 
> (Bridge->PMemAbove4G)) {
>  return NULL;
>}
>  }
> @@ -171,11 +171,9 @@ CreateRootBridge (
>// If this bit is not set, then the PCI Root Bridge does not support
>// 64 bit memory windows.
>//
> -  ASSERT (Bridge->MemAbove4G.Base > Bridge->MemAbove4G.Limit);
> -  ASSERT (Bridge->PMemAbove4G.Base > Bridge->PMemAbove4G.Limit);
> -  if ((Bridge->MemAbove4G.Base <= Bridge->MemAbove4G.Limit) ||
> -  (Bridge->PMemAbove4G.Base <= Bridge->PMemAbove4G.Limit)
> -  ) {
> +  ASSERT (!RESOURCE_VALID (Bridge->MemAbove4G));
> +  ASSERT (!RESOURCE_VALID (Bridge->PMemAbove4G));
> +  if (RESOURCE_VALID (Bridge->MemAbove4G) || RESOURCE_VALID 
> (Bridge->PMemAbove4G)) {
>  return NULL;
>}
>  }
> 

Two superficial comments:

- edk2 prefers long parameter names, so I suggest replacing "R" in the
macro definition with "Resource"

- taking the parameter as a pointer is frequently considered more flexible.

#define RESOURCE_VALID(Resource) ((Resource)->Base <= (Resource)->Limit)
...
if (RESOURCE_VALID (>Mem)) {
...

Up to you -- if you like these, feel free to update the patch before
pushing it (from my side anyway; you do need MdeModulePkg maintainer
review as well).

With or without changes:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 2/3] MdeModulePkg/PciHostBridge: Fix a bug that prevents PMEM access

[Laszlo Ersek]

On 09/21/18 09:25, Ruiyu Ni wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1196
> 
> RootBridgeIoCheckParameter() verifies that the requested MMIO access
> can fit in any of the MEM/PMEM 32/64 ranges. But today's logic
> somehow only checks the requested access against MEM 32/64 ranges.
> 
> It should also check the requested access against PMEM 32/64 ranges.
> 
> The patch fixes this issue.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Star Zeng 
> Cc: Kirkendall, Garrett 
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index 0b6b56f846..f6234b5d11 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -411,12 +411,18 @@ RootBridgeIoCheckParameter (
>  // By comparing the Address against Limit we know which range to be used
>  // for checking
>  //
> -if (Address + Length <= RootBridge->Mem.Limit + 1) {
> -  Base = RootBridge->Mem.Base;
> +if ((Address >= RootBridge->Mem.Base) && (Address + Length <= 
> RootBridge->Mem.Limit + 1)) {
> +  Base  = RootBridge->Mem.Base;
>Limit = RootBridge->Mem.Limit;
> -} else {
> -  Base = RootBridge->MemAbove4G.Base;
> +} else if ((Address >= RootBridge->PMem.Base) && (Address + Length <= 
> RootBridge->PMem.Limit + 1)) {
> +  Base  = RootBridge->PMem.Base;
> +  Limit = RootBridge->PMem.Limit;
> +} else if ((Address >= RootBridge->MemAbove4G.Base) && (Address + Length 
> <= RootBridge->MemAbove4G.Limit + 1)) {
> +  Base  = RootBridge->MemAbove4G.Base;
>Limit = RootBridge->MemAbove4G.Limit;
> +} else {
> +  Base  = RootBridge->PMemAbove4G.Base;
> +  Limit = RootBridge->PMemAbove4G.Limit;
>  }
>} else {
>  PciRbAddr = (EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_PCI_ADDRESS*) 
> 

The interesting thing about this patch is that, if any one of the first
three branches is taken, then the final checks will automatically pass.
That's because, on the first three branches, we select the base & the
limit *because* the access falls between them. Therefore, in the end,
when we check whether the access falls between base and end, they
miraculously happen to do so. :)

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 1/3] MdeModulePkg/PciHostBridge: Enhance boundary check in Io/Mem.Read/Write

[Laszlo Ersek]

On 09/21/18 09:25, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Star Zeng 
> ---
>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 26 
> +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index f8a1239ceb..0b6b56f846 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -321,6 +321,7 @@ RootBridgeIoCheckParameter (
>UINT64   Base;
>UINT64   Limit;
>UINT32   Size;
> +  UINT64   Length;
>  
>//
>// Check to see if Buffer is NULL
> @@ -337,7 +338,7 @@ RootBridgeIoCheckParameter (
>}
>  
>//
> -  // For FIFO type, the target address won't increase during the access,
> +  // For FIFO type, the device address won't increase during the access,
>// so treat Count as 1
>//
>if (Width >= EfiPciWidthFifoUint8 && Width <= EfiPciWidthFifoUint64) {
> @@ -347,6 +348,13 @@ RootBridgeIoCheckParameter (
>Width = (EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH) (Width & 0x03);
>Size  = 1 << Width;
>  
> +  //
> +  // Make sure (Count * Size) doesn't exceed MAX_UINT64
> +  //
> +  if (Count > DivU64x32 (MAX_UINT64, Size)) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
>//
>// Check to see if Address is aligned
>//
> @@ -354,6 +362,14 @@ RootBridgeIoCheckParameter (
>  return EFI_UNSUPPORTED;
>}
>  
> +  //
> +  // Make sure (Address + Count * Size) doesn't exceed MAX_UINT64
> +  //
> +  Length = MultU64x32 (Count, Size);
> +  if (Address > MAX_UINT64 - Length) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
>RootBridge = ROOT_BRIDGE_FROM_THIS (This);
>  
>//
> @@ -372,7 +388,7 @@ RootBridgeIoCheckParameter (
>  //
>  // Allow Legacy IO access
>  //
> -if (Address + MultU64x32 (Count, Size) <= 0x1000) {
> +if (Address + Length <= 0x1000) {
>if ((RootBridge->Attributes & (
> EFI_PCI_ATTRIBUTE_ISA_IO | EFI_PCI_ATTRIBUTE_VGA_PALETTE_IO | 
> EFI_PCI_ATTRIBUTE_VGA_IO |
> EFI_PCI_ATTRIBUTE_IDE_PRIMARY_IO | 
> EFI_PCI_ATTRIBUTE_IDE_SECONDARY_IO |
> @@ -386,7 +402,7 @@ RootBridgeIoCheckParameter (
>  //
>  // Allow Legacy MMIO access
>  //
> -if ((Address >= 0xA) && (Address + MultU64x32 (Count, Size)) <= 
> 0xC) {
> +if ((Address >= 0xA) && (Address + Length) <= 0xC) {
>if ((RootBridge->Attributes & EFI_PCI_ATTRIBUTE_VGA_MEMORY) != 0) {
>  return EFI_SUCCESS;
>}
> @@ -395,7 +411,7 @@ RootBridgeIoCheckParameter (
>  // By comparing the Address against Limit we know which range to be used
>  // for checking
>  //
> -if (Address + MultU64x32 (Count, Size) <= RootBridge->Mem.Limit + 1) {
> +if (Address + Length <= RootBridge->Mem.Limit + 1) {
>Base = RootBridge->Mem.Base;
>Limit = RootBridge->Mem.Limit;
>  } else {
> @@ -427,7 +443,7 @@ RootBridgeIoCheckParameter (
>return EFI_INVALID_PARAMETER;
>}
>  
> -  if (Address + MultU64x32 (Count, Size) > Limit + 1) {
> +  if (Address + Length > Limit + 1) {
>  return EFI_INVALID_PARAMETER;
>}
>  
> 

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

Re: [edk2] [PATCH v2] UefiCpuPkg PiSmmCpuDxeSmm: Update SmiEntry function run the same position

[Laszlo Ersek]

Hi Liming,

On 09/21/18 02:56, Liming Gao wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1191
> 
> Before commit e21e355e2ca7fefb15b4df7078f995d3fb9c2b89, jmp _SmiHandler
> is commented. And below code, ASM_PFX(CpuSmmDebugEntry) is moved into rax,
> then call it. But, this code doesn't work in XCODE5 tool chain. Because XCODE5
> doesn't generated the absolute address in the EFI image. So, rax stores the
> relative address. Once this logic is moved to another place, it will not work.
> ;   jmp _SmiHandler ; instruction is not needed
> ...
> mov rax, ASM_PFX(CpuSmmDebugEntry)
> callrax
> 
> Commit e21e355e2ca7fefb15b4df7078f995d3fb9c2b89 is to support XCODE5.
> One tricky way is selected to fix it. Although SmiEntry logic is copied to
> another place and run, but here jmp _SmiHandler is enabled to jmp the original
> code place, then call ASM_PFX(CpuSmmDebugEntry) with the relative address.
> mov rax, strict qword 0 ;   mov rax, _SmiHandler
> _SmiHandlerAbsAddr:
> jmp rax
> ...
> callASM_PFX(CpuSmmDebugEntry)
> 
> Now, BZ 1191 raises the issue that SmiHandler should run in the copied 
> address,
> can't run in the common address. So, jmp _SmiHandler is required to be 
> removed,
> the code is kept to run in copied address. And, the relative address is
> requried to be fixed up to the absolute address. The necessary changes should
> not affect the behavior of platforms that already consume PiSmmCpuDxeSmm.
> OVMF SMM boot to shell with VS2017, GCC5 and XCODE5 tool chain has been 
> verified.
> ...
> mov rax, strict qword 0 ;   callASM_PFX(CpuSmmDebugEntry)
> CpuSmmDebugEntryAbsAddr:
> callrax
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Laszlo Ersek 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm | 42 
> ++---
>  1 file changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> index 315d0f8..815f95b 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
> @@ -173,9 +173,6 @@ SmiHandlerIdtrAbsAddr:
>  mov gs, eax
>  mov ax, [rbx + DSC_SS]
>  mov ss, eax
> -mov rax, strict qword 0 ;   mov rax, _SmiHandler
> -_SmiHandlerAbsAddr:
> -jmp rax
>  
>  _SmiHandler:
>  mov rbx, [rsp + 0x8] ; rcx <- CpuIndex
> @@ -189,13 +186,19 @@ _SmiHandler:
>  add rsp, -0x20
>  
>  mov rcx, rbx
> -callASM_PFX(CpuSmmDebugEntry)
> +mov rax, strict qword 0 ;   callASM_PFX(CpuSmmDebugEntry)
> +CpuSmmDebugEntryAbsAddr:
> +callrax
>  
>  mov rcx, rbx
> -callASM_PFX(SmiRendezvous)
> +mov rax, strict qword 0 ;   callASM_PFX(SmiRendezvous)
> +SmiRendezvousAbsAddr:
> +callrax
>  
>  mov rcx, rbx
> -callASM_PFX(CpuSmmDebugExit)
> +mov rax, strict qword 0 ;   callASM_PFX(CpuSmmDebugExit)
> +CpuSmmDebugExitAbsAddr:
> +callrax
>  
>  add rsp, 0x20
>  
> @@ -206,7 +209,8 @@ _SmiHandler:
>  
>  add rsp, 0x200
>  
> -lea rax, [ASM_PFX(mXdSupported)]
> +mov rax, strict qword 0 ;   lea rax, 
> [ASM_PFX(mXdSupported)]
> +mXdSupportedAbsAddr:
>  mov al, [rax]
>  cmp al, 0
>  jz  .1
> @@ -224,13 +228,33 @@ _SmiHandler:
>  
>  ASM_PFX(gcSmiHandlerSize)DW  $ - _SmiEntryPoint
>  
> +;
> +; Retrieve the address and fill it into mov opcode.
> +;
> +; It is called in the driver entry point first.
> +; It is used to fix up the real address in mov opcode.
> +; Then, after the code logic is copied to the different location, 

The "git am" command complained that the line above added a whitespace
error. Can you please strip the trailing space character when you push
the patch?

Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

Thanks,
Laszlo


> +; the code can also run.
> +;
>  global ASM_PFX(PiSmmCpuSmiEntryFixupAddress)
>  ASM_PFX(PiSmmCpuSmiEntryFixupAddress):
>  learax, [ASM_PFX(gSmiHandlerIdtr)]
>  learcx, [SmiHandlerIdtrAbsAddr]
>  movqword [rcx - 8], rax
>  
> -learax, [_SmiHandler]
> -learcx, [_SmiHandlerAbsAddr]
> +learax, [ASM_PFX(CpuSmmDebugEntry)]
> +learcx, [CpuSmmDebugEntryAbsAddr]
> +movqword [rcx - 8], rax
> +
> +lea

Re: [edk2] [PATCH v2 2/2] MdeModulePkg/DxeIpl: support more NX related PCDs

[Laszlo Ersek]

On 09/21/18 10:42, Zeng, Star wrote:
> Another minor suggestion is to move IsExecuteDisableBitAvailable() to
> VirtualMemory.c, then there will be no need to declare it in
> VirtualMemeory.h.

I'm fine with both ideas (name change as you see fit, and code movement).

Thanks
Laszlo

> 
> 
> Thanks,
> Star
> On 2018/9/21 14:00, Zeng, Star wrote:
>> Jian and Laszlo,
>>
>> There is also a superficial comment at below.
>>
>> On 2018/9/20 14:02, Jian J Wang wrote:
>>>> v2 changes:
>>>>     a. remove macros no longer needed
>>>>     b. remove DEBUG and ASSERT in ToEnableExecuteDisableFeature()
>>>>     c. change ToEnableExecuteDisableFeature to EnableNonExec
>>>
>>> BZ#1116: https://bugzilla.tianocore.org/show_bug.cgi?id=1116
>>>
>>> Currently IA32_EFER.NXE is only set against PcdSetNxForStack. This
>>> confuses developers because following two other PCDs also need NXE
>>> to be set, but actually not.
>>>
>>>  PcdDxeNxMemoryProtectionPolicy
>>>      PcdImageProtectionPolicy
>>>
>>> This patch solves this issue by adding logic to enable IA32_EFER.NXE
>>> if any of those PCDs have anything enabled.
>>>
>>> Cc: Star Zeng 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: Ruiyu Ni 
>>> Cc: Jiewen Yao 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Jian J Wang 
>>> ---
>>>   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  2 ++
>>>   MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  4 ++--
>>>   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 30
>>> +++-
>>>   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 24
>>> +++
>>>   4 files changed, 57 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> index fd82657404..068e700074 100644
>>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> @@ -117,6 +117,8 @@
>>>   [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
>>>     gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ##
>>> SOMETIMES_CONSUMES
>>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ##
>>> SOMETIMES_CONSUMES
>>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ##
>>> SOMETIMES_CONSUMES
>>>   [Depex]
>>>     gEfiPeiLoadFilePpiGuid AND gEfiPeiMasterBootModePpiGuid
>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
>>> b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
>>> index d28baa3615..ccd30f964b 100644
>>> --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
>>> +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
>>> @@ -245,7 +245,7 @@ ToBuildPageTable (
>>>   return TRUE;
>>>     }
>>> -  if (PcdGetBool (PcdSetNxForStack) && IsExecuteDisableBitAvailable
>>> ()) {
>>> +  if (EnableNonExec ()) {
>>>   return TRUE;
>>>     }
>>> @@ -436,7 +436,7 @@ HandOffToDxeCore (
>>>   BuildPageTablesIa32Pae = ToBuildPageTable ();
>>>   if (BuildPageTablesIa32Pae) {
>>>     PageTables = Create4GPageTablesIa32Pae (BaseOfStack,
>>> STACK_SIZE);
>>> -  if (IsExecuteDisableBitAvailable ()) {
>>> +  if (EnableNonExec ()) {
>>>   EnableExecuteDisableBit();
>>>     }
>>>   }
>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> index 496e219913..73b0f67c6b 100644
>>> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> @@ -106,6 +106,31 @@ IsNullDetectionEnabled (
>>>     return ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) !=
>>> 0);
>>>   }
>>> +/**
>>> +  Check if Execute Disable Bit (IA32_EFER.NXE) should be enabled or
>>> not.
>>> +
>>> +  @retval TRUE    IA32_EFER.NXE should be enabled.
>>> +  @retval FALSE   IA32_EFER.NXE should not be enabled.
>>> +
>>> +**/
>>> +BOOLEAN
>>> +EnableNonExec (
>>> +  VOID
>>> +  )
>>> +{
>>> +  if (!IsExecuteDisableBitAvailable ()) {
>>> +    return FALSE;
>>> +  }
>>> +
>>> +  //
&

Re: [edk2] [Patch v2 08/14] UefiCpuPkg/Include/Register/ArchitecturalMsr.h: Change structure definition.

[Laszlo Ersek]

On 09/21/18 10:44, Ni, Ruiyu wrote:
> On 9/21/2018 3:41 PM, Eric Dong wrote:
>>   UINT32  User:1;
>> -    UINT32  Reserved1:2;
>> +    ///
>> +    /// [Bit 4] PwrEvtEn.
>> +    ///
>> +    UINT32  PwrEvtEn:1;
>> +    ///
>> +    /// [Bit 5] FUPonPTW.
>> +    ///
>> +    UINT32  FUPonPTW:1;
>>   ///
>>   /// [Bit 6] FabricEn. If (CPUID.(EAX=07H, ECX=0):ECX[3] = 1).
>>   ///
>> @@ -4672,7 +4679,10 @@ typedef union {
>>   /// [Bit 11] DisRETC.
>>   ///
>>   UINT32  DisRETC:1;
>> -    UINT32  Reserved2:1;
>> +    ///
>> +    /// [Bit 12] PTWEn.
>> +    ///
>> +    UINT32  PTWEn:1;
>>   ///
>>   /// [Bit 13] BranchEn.
>>   ///
>> @@ -4681,17 +4691,17 @@ typedef union {
>>   /// [Bits 17:14] MTCFreq. If (CPUID.(EAX=07H, ECX=0):EBX[3] = 1).
>>   ///
>>   UINT32  MTCFreq:4;
>> -    UINT32  Reserved3:1;
>> +    UINT32  Reserved7:1;
> 
> I prefer to not change this field name since the bit range for this
> Reserved6 is not changed.
> 
>>   ///
>>   /// [Bits 22:19] CYCThresh. If (CPUID.(EAX=07H, ECX=0):EBX[1] = 1).
>>   ///
>>   UINT32  CYCThresh:4;
>> -    UINT32  Reserved4:1;
>> +    UINT32  Reserved8:1;
> 
> I prefer to not change this field name since the bit range for this
> Reserved6 is not changed.
> 
>>   ///
>>   /// [Bits 27:24] PSBFreq. If (CPUID.(EAX=07H, ECX=0):EBX[1] = 1).
>>   ///
>>   UINT32  PSBFreq:4;
>> -    UINT32  Reserved5:4;
>> +    UINT32  Reserved9:4;
> 
> I prefer to not change this field name since the bit range for this
> Reserved6 is not changed.
> 
>>   ///
>>   /// [Bits 35:32] ADDR0_CFG. If (CPUID.(EAX=07H, ECX=1):EAX[2:0]
>> > 0).
>>   ///
>> @@ -4708,7 +4718,7 @@ typedef union {
>>   /// [Bits 47:44] ADDR3_CFG. If (CPUID.(EAX=07H, ECX=1):EAX[2:0]
>> > 3).
>>   ///
>>   UINT32  ADDR3_CFG:4;
>> -    UINT32  Reserved6:16;
>> +    UINT32  Reserved10:16;
> 
> I prefer to not change this field name since the bit range for this
> Reserved6 is not changed.
> 
>>     } Bits;
> 
> 
> Eric,
> As comments above, I suggest we keep the original Reserved## name if the
> bit range for that field doesn't change. We can only update the
> Reserved## name if the bit range changes.
> 
> In this way, we can maximally avoid build failure and also avoid silent
> failure.
> 
> In general, the Reserved## name is updated when the bit range changes.
> The ## is updated to
> 1 + MAX (all numbers used by Reserved## in this structure).
> 
> 
> Laszlo,
> What's your opinion?
> 

I agree with your suggestion.

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

Re: [edk2] [Patch 0/5] Support windowsize to benefit tftp/pxe download performance.

[Laszlo Ersek]

On 09/21/18 08:33, Wu, Jiaxin wrote:

> I agree we need document something to highlight that. Siyuan/Ting, if no 
> objection, I will do that in separate patch instead of mixing with this new 
> feature support.

That's a good idea (well, both: documenting the differences, and adding
the documentation in a separate patch).

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

Re: [edk2] SPI Flash Corruption

[Laszlo Ersek]

On 09/19/18 16:26, Samah Mansour wrote:
> Hello,
> 
> 
> Our product uses a Baytrail with Minnowboard Max bios firmware ( version
> 0.93). Every now and then we see SPI flash corruption due to power cuts
> while the unit is booting which causes the unit not to boot anymore. After
> investigation we noticed that the VPD area is all FFs (address
> 44000->47DFF0).
> 
> 
> We have noticed that the Bios while booting writes to the flash from
> several places in the code, which is if interrupted most probably is
> causing the corruption.
> 
> 
> Why is the bios writing all these configurations to flash while booting, is
> it to optimize boot time? is it ok if we disable the bios writing to flash
> completely to protect ourselves from corruption?

The firmware is at liberty to write various non-volatile UEFI variables
during boot. Some of those variables are standardized, some others may
be specific to UEFI drivers (with correspondingly private namespace
GUIDs for the variables).

Power loss during flash write (and resultant flash corruption) is
expected. My understanding is that the Fault Tolerant Write protocol /
driver, sitting between the FVB (firmware volume block, i.e. flash)
protocol / driver, and the variable write protocol / driver, implements
a kind of journaling. It is described in the Intel whitepaper

  A Tour Beyond BIOS
  Implementing UEFI Authenticated Variables in SMM with EDKII
  September 2015

My expectation has been that the platform should recover from
interrupted writes. That is, for a single given UEFI variable, you
should either see "before" or "after" status, never "middle". (The
whitepaper says that "Individual variable atomicity" is maintained even
through a failed "reclaim", with the help of FTW.)

If multiple variables should be in sync with each other, that's a
different question. If the variables are not in sync, I think "failure
to boot" may be a reasonable outcome. But, "failure to boot" means a lot
of things, and I hope one should be at least dropped to the setup
utility or the shell. Are you seeing an actual crash?

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

Re: [edk2] [PATCH v1 0/5] [CVE-2017-5753] Bounds Check Bypass issue in SMI handlers

[Laszlo Ersek]

On 09/20/18 08:40, Hao Wu wrote:
> The series aims to mitigate the Bounds Check Bypass (CVE-2017-5753) issues
> within SMI handlers.
> 
> A more detailed explanation of the purpose of the series is under the
> 'Bounds check bypass mitigation' section of the below link:
> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
> 
> And the document at:
> https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf
> 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Star Zeng 
> Cc: Eric Dong 

I'd like to test this series, but before I do that, I'll wait a bit
longer for other review feedback. Please ping me, should I forget.

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

Re: [edk2] [PATCH v1 1/5] MdePkg/BaseLib: Add new LoadFence API

[Laszlo Ersek]

On 09/20/18 08:40, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1193
> 
> This commit will add a new BaseLib API LoadFence(). This API will perform
> a serializing operation on all load-from-memory instructions that were
> issued prior to the call of this function.
> 
> The purpose of adding this API is to mitigate of the [CVE-2017-5753]
> Bounds Check Bypass issue when untrusted data are being processed within
> SMM. More details can be referred at the 'Bounds check bypass mitigation'
> section at the below link:
> 
> https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation
> 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdePkg/Include/Library/BaseLib.h   | 12 +++
>  MdePkg/Library/BaseLib/Arm/LoadFence.c | 26 ++
>  MdePkg/Library/BaseLib/BaseLib.inf |  4 +++
>  MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c | 15 +++-
>  MdePkg/Library/BaseLib/Ia32/LoadFence.nasm | 37 +++
>  MdePkg/Library/BaseLib/X64/LoadFence.nasm  | 38 
>  6 files changed, 131 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 123ae19dc2..194726ca35 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4939,6 +4939,18 @@ MemoryFence (
>  
>  
>  /**
> +  Performs a serializing operation on all load-from-memory instructions that
> +  were issued prior to the call of this function.
> +
> +**/
> +VOID
> +EFIAPI
> +LoadFence (
> +  VOID
> +  );
> +
> +
> +/**
>Saves the current CPU context that can be restored with a call to 
> LongJump()
>and returns 0.
>  
> diff --git a/MdePkg/Library/BaseLib/Arm/LoadFence.c 
> b/MdePkg/Library/BaseLib/Arm/LoadFence.c
> new file mode 100644
> index 00..69f0c3a07e
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/Arm/LoadFence.c
> @@ -0,0 +1,26 @@
> +/** @file
> +  LoadFence() function for ARM.
> +
> +  Copyright (C) 2018, Intel Corporation. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +**/
> +
> +/**
> +  Performs a serializing operation on all load-from-memory instructions that
> +  were issued prior to the call of this function.
> +
> +**/
> +VOID
> +EFIAPI
> +LoadFence (
> +  VOID
> +  )
> +{
> +}
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index a1b5ec4b75..f028fbc75a 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -68,6 +68,7 @@
>  
>  [Sources.Ia32]
>Ia32/WriteTr.nasm
> +  Ia32/LoadFence.nasm
>  
>Ia32/Wbinvd.c | MSFT
>Ia32/WriteMm7.c | MSFT
> @@ -346,6 +347,7 @@
>X64/EnableCache.nasm
>X64/DisableCache.nasm
>X64/WriteTr.nasm
> +  X64/LoadFence.nasm
>  
>X64/CpuBreakpoint.c | MSFT
>X64/WriteMsr64.c | MSFT
> @@ -580,6 +582,7 @@
>  [Sources.ARM]
>Arm/InternalSwitchStack.c
>Arm/Unaligned.c
> +  Arm/LoadFence.c
>Math64.c   | RVCT
>Math64.c   | MSFT
>  
> @@ -613,6 +616,7 @@
>  [Sources.AARCH64]
>Arm/InternalSwitchStack.c
>Arm/Unaligned.c
> +  Arm/LoadFence.c
>Math64.c
>  
>AArch64/MemoryFence.S | GCC
> diff --git a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c 
> b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> index 9b7d875664..a79461cfbf 100644
> --- a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> +++ b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> @@ -1,7 +1,7 @@
>  /** @file
>Base Library CPU Functions for EBC
>  
> -  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -52,6 +52,19 @@ MemoryFence (
>