public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <mhaeuser@posteo.de>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Sami Mujawar <sami.mujawar@arm.com>
Subject: [RFC PATCH] Fix ArmReplaceLiveTranslationEntry alignment
Date: Mon, 10 Apr 2023 18:08:00 +0000	[thread overview]
Message-ID: <A265FC41-6F06-4827-90E4-405E24657AC0@posteo.de> (raw)

Good day everyone,

Sorry, but due to time constraints, I cannot immediately provide a proper patch. Would you mind checking this commit and commenting on whether it looks about right, so I can submit a proper patch for review some time this or next week? https://github.com/acidanthera/audk/commit/53f2af3ad5909e177818445cafed7bdb6aae9d97

With the proper patch, I will probably also include an ASSERT to make sure the alignment is actually checked.

The symptom is that late PEI may crash due to corrupted memory. This is due to the fact that ArmReplaceLiveTranslationEntry() is misaligned despite the requirement it may not cross page boundaries. The related .balign directive technically belongs to the previous section, as ArmReplaceLiveTranslationEntry() is moved to its own section via ASM_FUNC() macro *after' the directive appears. The directive also cannot nicely be placed after ASM_FUNC(), as that would mean the label may refer to the padding inserted to achieve said alignment. Hence, my solution is to introduce a separate macro.

Reproducers are here, I tested the last two stable tags:
https://github.com/mhaeuser/edk2/tree/arm_corruption-202211
https://github.com/mhaeuser/edk2/tree/arm_corruption-202302

... and identified the last commit it is reproducible with (my hack does not work on master):
https://github.com/mhaeuser/edk2/tree/arm_corruption-latest

The fact that the commits after that last branch work is mere luck, I just didn't want to bruteforce a new hack to trigger the issue. :)

To trigger the issue, build ArmVirtQemu/AARCH64 of any of those branches with GCC 12 (GCC5) and as DEBUG - GCC 11 and RELEASE/NOOPT do *not* trigger the issue as-is for me. If this doesn't work for you, you probably need to find a different hack to move the function across a page boundary. When starting the generated FD, I get a hang right when jumping to DxeIplPeim (its entry point is badly corrupted). Opening PeiCore in IDA, it's obvious said function is misaligned.

Best regards,
Marvin

                 reply	other threads:[~2023-04-10 18:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=A265FC41-6F06-4827-90E4-405E24657AC0@posteo.de \
    --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