From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6] x86/dom0: disable SMAP for PV domain building only
Date: Thu, 29 Aug 2024 09:31:11 +0200 [thread overview]
Message-ID: <ZtAjv6hdbPTZ1dGI@macbook.local> (raw)
In-Reply-To: <a5b4ca69-96ea-46d6-ab0d-2be4fd1d9d99@citrix.com>
On Wed, Aug 28, 2024 at 07:57:39PM +0100, Andrew Cooper wrote:
> On 28/08/2024 2:02 pm, Roger Pau Monné wrote:
> > On Wed, Aug 28, 2024 at 12:51:23PM +0100, Andrew Cooper wrote:
> >> On 28/08/2024 12:50 pm, Jan Beulich wrote:
> >>> On 28.08.2024 13:30, Roger Pau Monne wrote:
> >>>> Move the logic that disables SMAP so it's only performed when building a PV
> >>>> dom0, PVH dom0 builder doesn't require disabling SMAP.
> >>>>
> >>>> The fixes tag is to account for the wrong usage of cpu_has_smap in
> >>>> create_dom0(), it should instead have used
> >>>> boot_cpu_has(X86_FEATURE_XEN_SMAP). Fix while moving the logic to apply to PV
> >>>> only.
> >>>>
> >>>> While there also make cr4_pv32_mask __ro_after_init.
> >>>>
> >>>> Fixes: 493ab190e5b1 ('xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself')
> >>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >>> preferably with ...
> >>>
> >>>> @@ -1051,6 +1051,34 @@ out:
> >>>> return rc;
> >>>> }
> >>>>
> >>>> +int __init dom0_construct_pv(struct domain *d,
> >>>> + const module_t *image,
> >>>> + unsigned long image_headroom,
> >>>> + module_t *initrd,
> >>>> + const char *cmdline)
> >>>> +{
> >>>> + int rc;
> >>>> +
> >>>> + /*
> >>>> + * Temporarily clear SMAP in CR4 to allow user-accesses in
> >>>> + * construct_dom0(). This saves a large number of corner cases
> >>> ... the final 's' dropped here and ...
> >>>
> >>>> + * interactions with copy_from_user().
>
>
> Actually, even with this adjustment the comment is still wonky.
>
> The point is that we're clearing SMAP so we *don't* need to rewrite
> construct_dom0() in terms of copy_{to,from}_user().
>
> I've adjusted it.
It did seem weird to me, I've assumed the wording was meaning to imply
that SMAP was disabled so that construct_dom0() didn't need to use
copy_from_user().
The comment you added seems fine to me, however there's a typo I
think:
/*
* Clear SMAP in CR4 to allow user-accesses in construct_dom0(). This
* prevents us needing to write rewrite construct_dom0() in terms of
^ extra?
* copy_{to,from}_user().
*/
We can fix at some later point when modifying this.
Thanks, Roger.
next prev parent reply other threads:[~2024-08-29 7:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 11:30 [PATCH v6] x86/dom0: disable SMAP for PV domain building only Roger Pau Monne
2024-08-28 11:50 ` Jan Beulich
2024-08-28 11:51 ` Andrew Cooper
2024-08-28 13:02 ` Roger Pau Monné
2024-08-28 18:57 ` Andrew Cooper
2024-08-29 7:31 ` Roger Pau Monné [this message]
2024-08-29 13:01 ` Andrew Cooper
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=ZtAjv6hdbPTZ1dGI@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.