From: Thomas Gleixner <tglx@linutronix.de>
To: Aruna Ramakrishna <aruna.ramakrishna@oracle.com>,
linux-kernel@vger.kernel.org
Cc: x86@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org,
keith.lucas@oracle.com, aruna.ramakrishna@oracle.com
Subject: Re: [PATCH v3 2/4] x86/pkeys: Add helper functions to update PKRU on sigframe
Date: Tue, 07 May 2024 18:16:34 +0200 [thread overview]
Message-ID: <87zft1ppgd.ffs@tglx> (raw)
In-Reply-To: <20240425180542.1042933-3-aruna.ramakrishna@oracle.com>
On Thu, Apr 25 2024 at 18:05, Aruna Ramakrishna wrote:
> This patch adds helper functions that will update PKRU value on the
git grep 'This patch' Documentation/process/
Also please explain WHY this is needed and not just what.
> sigframe after XSAVE.
...
> +/*
> + * Update the value of PKRU register that was already pushed
> + * onto the signal frame.
> + */
> +static inline int
> +__update_pkru_in_sigframe(struct xregs_state __user *buf, u32 pkru)
No line break and why does this need two underscores in the function name?
> +{
> + int err = -EFAULT;
> + struct _fpx_sw_bytes fx_sw;
> + struct pkru_state *pk = NULL;
Why assign NULL to pk?
Also this wants to have a
if (unlikely(!cpu_feature_enabled(X86_FEATURE_OSPKE)))
return 0;
Instead of doing it at the call site.
> + if (unlikely(!check_xstate_in_sigframe((void __user *) buf, &fx_sw)))
What is this check for?
More interesting: How is this check supposed to succeed at all?
copy_fpstate_to_sigframe()
....
copy_fpregs_to_sigframe()
xsave_to_user_sigframe();
__update_pkru_in_sigframe();
save_xstate_epilog();
check_xstate_in_sigframe() validates the full frame including what
save_xstate_epilog() writes afterwards. So this clearly cannot work.
> + goto out;
What's wrong with 'return -EFAULT;'?
> + pk = get_xsave_addr_user(buf, XFEATURE_PKRU);
> + if (!pk || !user_write_access_begin(buf, sizeof(struct xregs_state)))
> + goto out;
Why user_write_access_begin()?
1) The access to the FPU frame on the stack has been validated
already in copy_fpstate_to_sigframe() _before_
copy_fpregs_to_sigframe() is invoked.
2) This does not require the nospec_barrier() as this is not a user
controlled potentially malicious access.
> + unsafe_put_user(pkru, (unsigned int __user *) pk, uaccess_end);
This type case would need __force to be valid for make C=1.
But that's not required at all because get_xsave_addr_user() should
return a user pointer in the first place.
> +
> + err = 0;
> +uaccess_end:
> + user_access_end();
> +out:
> + return err;
So none of the above voodoo is required at all.
return __put_user(pkru, get_xsave_addr_user(buf, XFEATURE_PKRU));
Is all what's needed, no?
> +/*
> + * Given an xstate feature nr, calculate where in the xsave
> + * buffer the state is. The xsave buffer should be in standard
> + * format, not compacted (e.g. user mode signal frames).
> + */
> +void *get_xsave_addr_user(struct xregs_state __user *xsave, int xfeature_nr)
void __user *
> +{
> + if (WARN_ON_ONCE(!xfeature_enabled(xfeature_nr)))
> + return NULL;
> +
> + return (void *)xsave + xstate_offsets[xfeature_nr];
return (void __user *)....
Thanks,
tglx
next prev parent reply other threads:[~2024-05-07 16:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 18:05 [PATCH v3 0/4] x86/pkeys: update PKRU to enable pkey 0 before Aruna Ramakrishna
2024-04-25 18:05 ` [PATCH v3 1/4] x86/pkeys: Signal handling function interface changes to accept PKRU as a parameter Aruna Ramakrishna
2024-05-07 12:16 ` Thomas Gleixner
2024-04-25 18:05 ` [PATCH v3 2/4] x86/pkeys: Add helper functions to update PKRU on sigframe Aruna Ramakrishna
2024-05-07 16:16 ` Thomas Gleixner [this message]
2024-05-07 17:15 ` Aruna Ramakrishna
2024-04-25 18:05 ` [PATCH v3 3/4] x86/pkeys: Update PKRU to enable all pkeys before XSAVE Aruna Ramakrishna
2024-05-07 16:47 ` Thomas Gleixner
2024-05-07 17:34 ` Aruna Ramakrishna
2024-05-08 12:52 ` Thomas Gleixner
2024-04-25 18:05 ` [PATCH v3 4/4] selftests/mm: Add new testcases for pkeys Aruna Ramakrishna
2024-05-07 3:17 ` kernel test robot
2024-05-07 12:05 ` Thomas Gleixner
2024-05-07 16:56 ` Thomas Gleixner
2024-05-07 18:04 ` Aruna Ramakrishna
2024-05-08 12:55 ` Thomas Gleixner
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=87zft1ppgd.ffs@tglx \
--to=tglx@linutronix.de \
--cc=aruna.ramakrishna@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=keith.lucas@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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