From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Ni, Ray" <ray.ni@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"Liu, Zhiguang" <zhiguang.liu@intel.com>,
"Dong, Guo" <guo.dong@intel.com>,
"You, Benjamin" <benjamin.you@intel.com>,
"Rhodes, Sean" <sean@starlabs.systems>
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack.
Date: Wed, 8 Jun 2022 08:52:59 +0200 [thread overview]
Message-ID: <20220608065259.xfl3o22hgoq3r6wi@sirius.home.kraxel.org> (raw)
In-Reply-To: <MWHPR11MB16316F91C7C2F816273A68C08CA49@MWHPR11MB1631.namprd11.prod.outlook.com>
Hi,
> > > But I still have some doubts about using linux-style page split.
> > > Because it's marked as not present:
> > > 1. Active code should not access data in the 2M region (stack is in the 2M region in our case)
> > > 2. Active code should not in the 2M region (how to guarantee that?)
> > >
> > > How does Linux guarantee the above two points?
> >
> > Easy. It's kernel code changing mappings for userspace, so no need to
> > worry about code removing its own mappings in the first place. It's a
> > different story for edk2 though ...
> >
> > Can this be covered by the page fault handler? Update the entry like
> > the current code does, except for clearing the present bit, then flush
> > tlb, then set the present bit. In case we take a page fault the only
> > action the handler must do is enable the present bit, which might even
> > be possible to do without additional state tracking.
>
> It's a bit heavy from my perspective.
> I prefer to split the page to 4K in the very beginning of stack setup.
> It also guarantees such issue doesn't appear.
Yes, avoiding hugepages being created in the first place will surely fix
that specific case. The commit message should describe the problem
better, otherwise I'm fine with the patch.
But I think there are more cases where edk2 splits huge pages.
HeapGuard comes to mind for example. So I'm wondering whenever there
are more simliar problems in the code base.
take care,
Gerd
prev parent reply other threads:[~2022-06-08 6:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 5:39 [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack Zhiguang Liu
2022-05-31 7:45 ` [edk2-devel] " Gerd Hoffmann
2022-05-31 8:03 ` Ni, Ray
2022-05-31 11:21 ` Gerd Hoffmann
2022-05-31 13:24 ` Ni, Ray
2022-05-31 15:32 ` Gerd Hoffmann
2022-06-08 0:49 ` Ni, Ray
2022-06-08 6:52 ` Gerd Hoffmann [this message]
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=20220608065259.xfl3o22hgoq3r6wi@sirius.home.kraxel.org \
--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