All of lore.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: 17+ 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 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
  -- strict thread matches above, loose matches on Subject: below --
2024-04-27  4:07 kernel test robot
2024-05-07  3:17 ` kernel test robot

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 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.