From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: devel@edk2.groups.io, cheptsov@ispras.ru, "Kinney,
Michael D" <michael.d.kinney@intel.com>
Cc: "Andrew Fish" <afish@apple.com>,
"Bret Barkelew" <bret.barkelew@microsoft.com>,
"Brian J . Johnson" <brian.johnson@hpe.com>,
"Chiu, Chasel" <chasel.chiu@intel.com>,
"Justen, Jordan L" <jordan.l.justen@intel.com>,
"Laszlo Ersek" <lersek@redhat.com>,
"Leif Lindholm" <leif@nuviainc.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Marvin Häuser" <mhaeuser@outlook.de>,
"Zimmer, Vincent" <vincent.zimmer@intel.com>,
"Gao, Zhichao" <zhichao.gao@intel.com>
Subject: Re: [edk2-devel] [PATCH V6 1/1] MdePkg: Fix SafeString performing assertions on runtime checks
Date: Thu, 14 May 2020 21:45:41 +0200 [thread overview]
Message-ID: <f28dc5a7-86b2-d022-924b-c0633eb40a3b@arm.com> (raw)
In-Reply-To: <EEAC21EB-5AB3-49AF-A894-4D9A026F2236@ispras.ru>
On 5/14/20 8:59 PM, Vitaly Cheptsov via groups.io wrote:
> Mike,
>
> The code you posted may inflict undefined behaviour is not valid C for
> several reasons. The compiler is free to do whatever it desires. Please
> refer to ISO/IEC 9899 for more details.
>
> If applications cast raw pointers to typed pointers without checking
> their alignment, well, god bless them :)
> My opinion is both the compiler and the hardware are welcome to do the
> worst once your third line is discovered. On a number of CPUs such
> addresses cannot be even represented in the first place.
>
> Yet, once again it is out of the scope of the current problem.
>
This has come up a couple of times in the past, and it is indeed a
serious issue with the EDK2 codebase.
For example, in BaseLib we have
UINT16
EFIAPI
WriteUnaligned16 (
OUT UINT16 *Buffer,
IN UINT16 Value
);
which does not make any sense, since a UINT16* is defined as being
aligned to 16 bits, and so the compiler is permitted to generate code
assuming that constraint is never violated.
So the correct way would be to define this prototype as
UINT16
EFIAPI
WriteUnaligned16 (
OUT VOID *Buffer,
IN UINT16 Value
);
and let the underlying implementation deal with the misalignment.
As I said, I'm sure this has come up in the past, and there may even be
a bugzilla entry for it.
next prev parent reply other threads:[~2020-05-14 19:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 9:25 [PATCH V6 0/1] Disable safe string constraint assertions Vitaly Cheptsov
2020-05-14 9:25 ` [PATCH V6 1/1] MdePkg: Fix SafeString performing assertions on runtime checks Vitaly Cheptsov
2020-05-14 13:35 ` Laszlo Ersek
2020-05-14 16:38 ` [edk2-devel] " Michael D Kinney
2020-05-14 17:39 ` Vitaly Cheptsov
2020-05-14 17:58 ` Michael D Kinney
2020-05-14 18:59 ` Vitaly Cheptsov
2020-05-14 19:45 ` Ard Biesheuvel [this message]
2020-05-14 21:07 ` Michael D Kinney
2020-05-14 21:15 ` [EXTERNAL] " Bret Barkelew
2020-05-14 22:14 ` Michael D Kinney
2020-05-15 9:28 ` Marvin Häuser
2020-05-15 9:30 ` [EXTERNAL] " Vitaly Cheptsov
2020-05-15 15:26 ` Bret Barkelew
2020-05-14 11:33 ` [edk2-devel] [PATCH V6 0/1] Disable safe string constraint assertions Ard Biesheuvel
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=f28dc5a7-86b2-d022-924b-c0633eb40a3b@arm.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