[edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER
Marvin Häuser
mhaeuser at posteo.de
Fri Jun 18 09:37:12 UTC 2021
Hey Kun,
On 16.06.21 22:58, Kun Qin wrote:
> Hi Marvin,
>
> Thanks for reaching out. Please see my comment inline.
>
> Regards,
> Kun
>
> On 06/16/2021 00:02, Marvin Häuser wrote:
>> Good day,
>>
>> May I ask about two small things?
>>
>> 1) Was there any rationale as to e.g. code compatibility with
>> choosing UINT64 for the data length? I understand that this is the
>> maximum of the two as of currently, but I wonder whether a message
>> length that exceeds the UINT32 range (4 GB!) can possibly be
>> considered sane or a good idea.
> I agree that >4GB communication buffer may not be practical as of
> today. That is why we modified the SMM communication routine in
> PiSmmIpl to use SafeInt functions in Patch 2 of this series. With that
> change, at least for 32bit MM, larger than 4GB will be considered
> insane. But in the meantime, I do not want to rule out the >4GB
> communication capability that a 64bit MM currently already have.
>
> Please let me know if I missed anything in regards to adding SafeInt
> functions to SmmCommunication routine.
I didn't see anything missed, but that is part of the point. If it was
UINT32, no such validation would be required. Also I feel like in
high-security scenarios, you would have a cap (that is well below 4 GB I
imagine) anyway past which you reject transmission for looking insane. I
totally understand it's a tough choice to reduce the capabilities and to
go with a capacity less than what is possible, but I do not think
current transmission realistically exceed a very few megabytes? This
would still allow for incredible headroom.
>>
>> 2) Is it feasible yet with the current set of supported compilers to
>> support flexible arrays?
> My impression is that flexible arrays are already supported (as seen
> in UnitTestFrameworkPkg/PrivateInclude/UnitTestFrameworkTypes.h).
> Please correct me if I am wrong.
>
> Would you mind letting me know why this is applicable here? We are
> trying to seek ideas on how to catch developer mistakes caused by this
> change. So any input is appreciated.
Huh, interesting. Last time I tried I was told about incompatibilities
with MSVC, but I know some have been dropped since then (2005 and 2008
if I recall correctly?), so that'd be great to allow globally. I feel
like if the structure is modified anyway, it should probably get a
trailing flexible array over the 1-sized hack. What do you think?
Best regards,
Marvin
>>
>> Thank you for your work!
>>
>> Best regards,
>> Marvin
>>
>> On 10.06.21 03:42, Kun Qin wrote:
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430
>>>
>>> In PI Spec v1.7 Errata A, Vol.4, Sec 5.7 MM Communication Protocol, the
>>> MessageLength field of EFI_MM_COMMUNICATE_HEADER (also derived as
>>> EFI_SMM_COMMUNICATE_HEADER) is currently defined as type UINTN.
>>>
>>> But this structure, as a generic definition, could be used for both PEI
>>> and DXE MM communication. Thus for a system that supports PEI MM
>>> launch,
>>> but operates PEI in 32bit mode and MM foundation in 64bit, the current
>>> EFI_MM_COMMUNICATE_HEADER definition will cause structure parse
>>> error due
>>> to UINTN being used.
>>>
>>> The suggested change is to make the MessageLength field defined with
>>> definitive size as below:
>>> ```
>>> typedef struct {
>>> EFI_GUID HeaderGuid;
>>> UINT64 MessageLength;
>>> UINT8 Data[ANYSIZE_ARRAY];
>>> } EFI_MM_COMMUNICATE_HEADER;
>>> ```
>>>
>>> Patch v1 branch:
>>> https://github.com/kuqin12/edk2/tree/BZ3398-MmCommunicate-Length
>>>
>>> Cc: Jian J Wang <jian.j.wang at intel.com>
>>> Cc: Hao A Wu <hao.a.wu at intel.com>
>>> Cc: Eric Dong <eric.dong at intel.com>
>>> Cc: Ray Ni <ray.ni at intel.com>
>>> Cc: Michael D Kinney <michael.d.kinney at intel.com>
>>> Cc: Liming Gao <gaoliming at byosoft.com.cn>
>>> Cc: Zhiguang Liu <zhiguang.liu at intel.com>
>>> Cc: Andrew Fish <afish at apple.com>
>>> Cc: Laszlo Ersek <lersek at redhat.com>
>>> Cc: Leif Lindholm <leif at nuviainc.com>
>>>
>>> Kun Qin (5):
>>> EDK2 Code First: PI Specification: EFI_MM_COMMUNICATE_HEADER Update
>>> MdeModulePkg: PiSmmIpl: Update MessageLength calculation for
>>> MmCommunicate
>>> MdeModulePkg: MemoryProfileInfo: Updated MessageLength calculation
>>> MdeModulePkg: SmiHandlerProfileInfo: Updated MessageLength
>>> calculation
>>> MdePkg: MmCommunication: Extend MessageLength field size to UINT64
>>>
>>> MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 20
>>> +++--
>>> MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c
>>> | 8 +-
>>> MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 13 ++-
>>> BZ3430-SpecChange.md | 88 ++++++++++++++++++++
>>> MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf | 1 +
>>> MdePkg/Include/Protocol/MmCommunication.h | 3 +-
>>> 6 files changed, 124 insertions(+), 9 deletions(-)
>>> create mode 100644 BZ3430-SpecChange.md
>>>
>>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76745): https://edk2.groups.io/g/devel/message/76745
Mute This Topic: https://groups.io/mt/83435921/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list