public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Marvin Häuser" <mhaeuser@outlook.de>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs
Date: Wed, 25 Sep 2019 17:54:40 +0200	[thread overview]
Message-ID: <ac3fe017-6aa1-2577-c940-3dabaf1d897b@redhat.com> (raw)
In-Reply-To: <HE1PR07MB4394FCE796375FFFBF13C459AC870@HE1PR07MB4394.eurprd07.prod.outlook.com>

(snipping liberally)

On 09/25/19 10:13, Marvin Häuser wrote:
> Am 24.09.2019 um 22:26 schrieb Laszlo Ersek:

>> I'm opposed to enforcing the strict aliasing rules, even though in
>> all code that I write, I either try to conform to them, or at least I
>> seek to be fully conscious of breaking them.
>
> I agree with that, but I often see completely needless violations of
> them. In my opinion, all intentional violations should be documented
> to  signal the conscious breakage of the standard, as should be any
> "abuse"  of known implementation-defined behaviour.

Agreed!

> I suppose for the amount of in-place parsing done, the Strict Aliasing
> rule should be an exception for these cases, as per the assumptions
> below.

Probably so; from personal experience, I'm basically only drawn to type
punning when there's some binary data to parse into (or via)
structure(s); and in firmware, there are *surprisingly* many sequences /
tables to parse.

>> Consider the following example. You have a dynamically allocated
>> buffer. You read some data into it, from the network or the disk,
>> using PCI DMA. Let's assume that, from the block read via PCI DMA,
>> the library function(s) or protocol member(s) that you call, directly
>> or indirectly, there is at least one that:
>> - copies data from a source buffer to a target buffer, using UINT32
>> or UINT64 assignments (for speed),
>
> Honestly, I did not consider this and only had memcpy/memmove in mind.

It may not be an intuitive example.

There are other (similarly practical) instances of this pattern. See
commit 6e2543b01d0c ("ArmVirtualizationPkg: introduce QemuFwCfgLib
instance for DXE drivers", 2015-01-02), for example:

>     [...]
>
>     Because MMIO accesses are costly on KVM/ARM, InternalQemuFwCfgReadBytes()
>     accesses the fw_cfg data register in full words. This speeds up transfers
>     almost linearly.
>
>     [...]
>
> +/**
> +  Reads firmware configuration bytes into a buffer
> +
> +  @param[in] Size    Size in bytes to read
> +  @param[in] Buffer  Buffer to store data into  (OPTIONAL if Size is 0)
> +
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +InternalQemuFwCfgReadBytes (
> +  IN UINTN Size,
> +  IN VOID  *Buffer OPTIONAL
> +  )
> +{
> +  UINTN Left;
> +  UINT8 *Ptr;
> +  UINT8 *End;
> +
> +#ifdef MDE_CPU_AARCH64
> +  Left = Size & 7;
> +#else
> +  Left = Size & 3;
> +#endif
> +
> +  Size -= Left;
> +  Ptr = Buffer;
> +  End = Ptr + Size;
> +
> +#ifdef MDE_CPU_AARCH64
> +  while (Ptr < End) {
> +    *(UINT64 *)Ptr = MmioRead64 (mFwCfgDataAddress);
> +    Ptr += 8;
> +  }
> +  if (Left & 4) {
> +    *(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> +    Ptr += 4;
> +  }
> +#else
> +  while (Ptr < End) {
> +    *(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> +    Ptr += 4;
> +  }
> +#endif
> +
> +  if (Left & 2) {
> +    *(UINT16 *)Ptr = MmioRead16 (mFwCfgDataAddress);
> +    Ptr += 2;
> +  }
> +  if (Left & 1) {
> +    *Ptr = MmioRead8 (mFwCfgDataAddress);
> +  }
> +}

And then the data read like this from the hypervisor may contain
arbitrary structures for the firmware to parse.

Back to the discussion:

On 09/25/19 10:13, Marvin Häuser wrote:

> However, if we "virtually" treat CopyMem as memmove, the compiler
> compatibility verification would be reduced from all callers to just
> it, i.e. CopyMem must be implemented in a way that, for all supported
> compilers, we can assume the original effective type is "carried
> over", such with at worst (which should not be required with any sane
> compiler) char-copying.

As far as I understand, you're saying that, if we ensure that compilers
recognize CopyMem() as similar to memmove(), then we can apply the C
standard (~ the effective type rules) to edk2 too, only replacing
memcpy() / memmove() references in the std language with CopyMem()
references.

Then we could call edk2 conformant once all such data manipulation
boiled down to correct use of CopyMem().

If that's your point, then I agree with it.

> I'm not looking to have absolute C compliance enforced, but to reduce
> pointless violations and possibly "concentrate" violations for easier
> compatibility verification.

These are very good goals.

(As a digression, consider the following -- very frequent -- pattern:

  EFI_PCI_IO_PROTOCOL *PciIo;

  Status = gBS->OpenProtocol (
                  DeviceHandle,
                  &gEfiPciIoProtocolGuid,
                  (VOID **)&PciIo,
                  This->DriverBindingHandle,
                  DeviceHandle,
                  EFI_OPEN_PROTOCOL_BY_DRIVER
                  );

Technically, the third argument

  (VOID **)&PciIo

is wrong, as pointer-to-structure types (which have identical
representation to each other) need not have the same representation as
pointer-to-void. See C99 "6.2.5 Types", p27:

> A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. [...] Similarly,
> pointers to qualified or unqualified versions of compatible types
> shall have the same representation and alignment requirements. All
> pointers to structure types shall have the same representation and
> alignment requirements as each other. All pointers to union types
> shall have the same representation and alignment requirements as each
> other. Pointers to other types need not have the same representation
> or alignment requirements.

The proper way to do it would be:

  VOID                *Interface;
  EFI_PCI_IO_PROTOCOL *PciIo;

  Status = gBS->OpenProtocol (
                  DeviceHandle,
                  &gEfiPciIoProtocolGuid,
                  &Interface,
                  This->DriverBindingHandle,
                  DeviceHandle,
                  EFI_OPEN_PROTOCOL_BY_DRIVER
                  );
  if (!EFI_ERROR (Status)) {
    PciIo = Interface;
  }

Because, in the assignment, the pointer-to-void is *converted* to
pointer-to-structure (not just re-interpreted as), with any necessary
updates to the internal representation.

IIRC, POSIX ultimately added a requirement (beyond the C standard) for
implementations, for said pointer representations to be identical.

So, this is a very frequent violation of the standard; I think it's even
visible in the UEFI spec, in various example code.

Is this violation pointless? It wouldn't be difficult to write all new
code following the second (proper) pattern. Updating all existent sites
would be a nightmare though.

)

Continuing:

On 09/25/19 10:13, Marvin Häuser wrote:

> If nothing else, casting away CONST drastically increases the
> likeliness of misuse happening, as the only indicator for const-ness
> has been dropped.

I agree; before casting away an existing const-qualification, we should
think thrice.

(OTOH, trying to design all function prototypes as tightly as possible,
const-qualifying as many as possible pointed-to objects under the
pointer-typed parameters, tends to become unwieldy really quick. In my
experience anyway.)

>> It would be nice to remove all toolchains that don't support the
>> flexible array member, and then to replace all struct hacks with the
>> flexible array member. I agree.
>>
>> Unfortunately, there's one extra difficulty (beyond the "expected"
>> regressions in adjusting code for the fixed element at offset 0): the
>> struct hack is used in several places in the UEFI 2.8 spec. So that
>> would have to be updated too.
>
> Agreed. However, I see value in updating the UEFI specification, as it
> should mandate the abstract-ish concept (trailing array of a length not
> known at compile time), not the implementation (struct hack), which in
> this case even is a language standard violation.

It's not that I don't see value in updating the spec -- I generally
don't have time for working on the spec (or for reviewing ECRs)! :)

Thanks!
Laszlo

  reply	other threads:[~2019-09-25 15:54 UTC|newest]

Thread overview: 155+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 19:49 [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Laszlo Ersek
2019-09-17 19:49 ` [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Laszlo Ersek
2019-09-17 20:06   ` [edk2-devel] " Ni, Ray
2019-09-17 20:22     ` Andrew Fish
2019-09-17 20:28       ` Ni, Ray
2019-09-17 21:07         ` Andrew Fish
2019-09-17 21:11           ` Michael D Kinney
2019-09-18  8:41       ` Laszlo Ersek
2019-09-18 15:16         ` Michael D Kinney
2019-09-18 17:41           ` Laszlo Ersek
2019-09-18 15:55         ` Andrew Fish
2019-09-18 16:16           ` Leif Lindholm
2019-09-18 17:45           ` Laszlo Ersek
2019-09-18  8:36     ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers Laszlo Ersek
2019-09-18 17:41   ` Leif Lindholm
2019-09-17 19:49 ` [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call Laszlo Ersek
2019-09-24 10:47   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:12   ` Laszlo Ersek
2019-09-26 12:16   ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop() Laszlo Ersek
2019-09-25 15:52   ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast Laszlo Ersek
2019-09-17 20:02   ` Ni, Ray
2019-09-20 15:00   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:01   ` Ni, Ray
2019-09-24 10:44   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls Laszlo Ersek
2019-09-19  1:46   ` Dandan Bi
2019-09-24 10:43   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-19  1:46   ` Dandan Bi
2019-09-24 10:49   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-17 20:17   ` Ni, Ray
2019-09-25 16:02   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:10     ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call Laszlo Ersek
2019-09-23 11:45   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-24 17:28     ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug Laszlo Ersek
2019-09-19  1:47   ` Dandan Bi
2019-09-17 19:49 ` [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration Laszlo Ersek
2019-09-17 20:16   ` [edk2-devel] " Ni, Ray
2019-09-19  1:47   ` Dandan Bi
2019-09-24 10:54   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx() Laszlo Ersek
2019-09-19  1:46   ` Dandan Bi
2019-09-24 15:40   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
2019-09-17 20:16   ` Ni, Ray
2019-09-17 19:49 ` [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent Laszlo Ersek
2019-09-18  2:38   ` Dong, Eric
2019-09-17 19:49 ` [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly Laszlo Ersek
2019-09-19  1:47   ` [edk2-devel] " Dandan Bi
2019-09-17 19:49 ` [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast Laszlo Ersek
2019-09-18  4:47   ` [edk2-devel] " Liming Gao
2019-09-24 15:38   ` Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress() Laszlo Ersek
2019-09-24 11:00   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-10-08  0:32     ` Siyuan, Fu
2019-10-08 23:36       ` Laszlo Ersek
2019-09-26 12:14   ` Laszlo Ersek
2019-10-03 11:05     ` Laszlo Ersek
2019-10-04 19:18       ` Laszlo Ersek
2019-10-07 18:15   ` Michael D Kinney
2019-09-17 19:49 ` [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls Laszlo Ersek
2019-09-26 12:14   ` [edk2-devel] " Laszlo Ersek
2019-09-26 12:42   ` Philippe Mathieu-Daudé
2019-09-30 20:16     ` Laszlo Ersek
2019-10-01  7:18       ` Philippe Mathieu-Daudé
2019-09-27  0:03   ` Siyuan, Fu
2019-09-17 19:49 ` [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call Laszlo Ersek
2019-09-23 16:03   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-27  0:04     ` Siyuan, Fu
2019-09-26 12:14   ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list Laszlo Ersek
2019-09-23 15:09   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:14   ` Laszlo Ersek
2019-09-27  0:06   ` Siyuan, Fu
2019-09-17 19:49 ` [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call Laszlo Ersek
2019-09-18  9:32   ` Anthony PERARD
2019-09-18 10:30   ` Julien Grall
2019-09-23 15:03   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call Laszlo Ersek
2019-09-20 14:59   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:16   ` Laszlo Ersek
2019-09-26 12:17   ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions Laszlo Ersek
2019-09-20 14:56   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-25 15:57   ` Ard Biesheuvel
2019-09-17 19:49 ` [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call Laszlo Ersek
2019-09-23 15:59   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:43     ` Laszlo Ersek
2019-10-04 20:01       ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls Laszlo Ersek
2019-09-23  9:55   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:45   ` Laszlo Ersek
2019-10-03 11:06     ` Laszlo Ersek
2019-10-04  0:05       ` Yao, Jiewen
2019-10-04 13:14       ` Zhang, Chao B
2019-10-04 18:15         ` Laszlo Ersek
2019-10-05 14:28       ` Zhang, Chao B
2019-10-07 18:14         ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration Laszlo Ersek
2019-09-23  9:56   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 12:46   ` Laszlo Ersek
2019-10-03 11:06     ` Laszlo Ersek
2019-10-04  0:05       ` Yao, Jiewen
2019-10-04 13:16       ` Zhang, Chao B
2019-10-05 14:28       ` Zhang, Chao B
2019-09-17 19:49 ` [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo Laszlo Ersek
2019-09-24 15:44   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26  2:46   ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE Laszlo Ersek
2019-09-25 18:04   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26 11:48     ` Laszlo Ersek
2019-09-26  2:43   ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE Laszlo Ersek
2019-09-23  9:58   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-26  2:53   ` Gao, Zhichao
2019-09-26 12:08     ` Laszlo Ersek
2019-09-26 14:43       ` Gao, Zhichao
2019-09-30 19:52         ` Laszlo Ersek
2019-09-17 19:49 ` [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call Laszlo Ersek
2019-09-23 10:01   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-23 14:28     ` Carsey, Jaben
2019-09-24  1:18       ` Gao, Zhichao
2019-09-17 19:49 ` [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug Laszlo Ersek
2019-09-26 12:47   ` [edk2-devel] " Laszlo Ersek
2019-09-26 14:05     ` Gao, Zhichao
2019-09-26 14:58     ` Carsey, Jaben
2019-09-17 19:49 ` [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking Laszlo Ersek
2019-09-26 12:48   ` [edk2-devel] " Laszlo Ersek
2019-10-03 11:10     ` Laszlo Ersek
2019-10-03 11:17       ` Achin Gupta
2019-10-04  0:10       ` Yao, Jiewen
2019-10-04 14:53       ` Achin Gupta
2019-09-17 19:49 ` [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT Laszlo Ersek
2019-09-23  2:30   ` Guo Dong
2019-09-26 13:17   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-17 19:49 ` [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls Laszlo Ersek
2019-09-23  2:28   ` [edk2-devel] " Guo Dong
2019-09-23 15:08   ` Philippe Mathieu-Daudé
2019-09-23 16:02     ` Guo Dong
2019-09-23 16:04       ` Philippe Mathieu-Daudé
2019-09-24 17:29     ` Laszlo Ersek
2019-09-19  0:32 ` [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs Wu, Hao A
2019-09-23 16:27 ` Marvin Häuser
2019-09-24 20:26   ` Laszlo Ersek
2019-09-25  8:13     ` Marvin Häuser
2019-09-25 15:54       ` Laszlo Ersek [this message]
2019-10-08 23:49 ` Laszlo Ersek
2019-10-09  9:50   ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac3fe017-6aa1-2577-c940-3dabaf1d897b@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox