From: Steven Price <steven.price@arm.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: the arch/x86 maintainers <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: your "x86: mm: convert dump_pagetables to use walk_page_range" change
Date: Tue, 12 May 2020 14:02:51 +0100 [thread overview]
Message-ID: <d95d756d-e940-d81e-d6ca-e45054df72c4@arm.com> (raw)
In-Reply-To: <d573dc7e-e742-84de-473d-f971142fa319@suse.com>
On 12/05/2020 10:39, Jan Beulich wrote:
> Steven,
Hi Jan,
> in the description of this change you say:
>
> "The effective permissions are passed down the chain using new fields in
> struct pg_state."
>
> I don't see how this works, and I suppose this part of the change is
> (part of) the reason why a W+X warning has magically disappeared in
> 5.6.x (compared to 5.5.x) when running a 32-bit kernel under Xen.
>
> Quoting the relevant piece of code:
>
> if (level > 0) {
> new_eff = effective_prot(st->prot_levels[level - 1],
> new_prot);
> } else {
> new_eff = new_prot;
> }
>
> if (level >= 0)
> st->prot_levels[level] = new_eff;
>
> The generic framework calls note_page() only for leaf pages or holes
> afaics. The protections for a leaf page found at a level other than
> the numerically highest one have no meaning at all for a mapping at
> a later address mapped with a numerically higher level mapping.
> Instead it's the non-leaf page tables for that specific address
> which determine the effective protection for any particular mapping.
>
> To take an example, suppose the first present leaf page is found
> at level 4. st->prot_levels[] will be all zero at this time, from
> which it follows that new_eff will be zero then, too.
>
> I don't think the intended effect can be achieved without either
> retaining the original behavior of passing the effective protection
> into note_page(), or calling note_page() also for non-leaf pages
> (indicating to it which case it is, and adjusting it accordingly).
>
> Am I overlooking something?
Sadly I don't think you are - you're reasoning seems correct. It looks
like the computation of effective permissions will need to be done in
ptdump.c rather than dump_pagetables.c - as it's only ptdump.c that
deals with the non-leaf entries as you point out.
> Additionally I'd like to note that note_page()'s "unsigned long val"
> parameter isn't wide enough for 32-bit PAE PTEs, and hence the NX
> flag will always be seen as clear in new_prot in such configs.
Ah, interesting. I'm not sure what type is actually guaranteed to be
correct. pgprotval_t is x86 specific, but it might be necessary to
extend it to other architectures. I think I got the "unsigned long" from
the generic page.h (and because it happens to work on most
architectures) - but hadn't noticed that that file was specifically only
for NOMMU architectures.
I'll see if I can come up with fixes, but if you've got anything ready
already then please jump in.
Steve
next prev parent reply other threads:[~2020-05-12 13:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 9:39 your "x86: mm: convert dump_pagetables to use walk_page_range" change Jan Beulich
2020-05-12 13:02 ` Steven Price [this message]
2020-05-12 13:09 ` Jan Beulich
2020-05-12 13:18 ` Peter Zijlstra
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-all 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=d95d756d-e940-d81e-d6ca-e45054df72c4@arm.com \
--to=steven.price@arm.com \
--cc=jbeulich@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).