public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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