linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Fenghua Yu <fenghua.yu@intel.com>,
	x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch
Date: Wed, 14 Oct 2020 15:36:42 -0700	[thread overview]
Message-ID: <20201014223642.GN2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <429789d3-ab5b-49c3-65c3-f0fc30a12516@intel.com>

On Tue, Oct 13, 2020 at 11:31:45AM -0700, Dave Hansen wrote:
> On 10/9/20 12:42 PM, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > The PKRS MSR is defined as a per-logical-processor register.  This
> > isolates memory access by logical CPU.  Unfortunately, the MSR is not
> > managed by XSAVE.  Therefore, tasks must save/restore the MSR value on
> > context switch.
> > 
> > Define a saved PKRS value in the task struct, as well as a cached
> > per-logical-processor MSR value which mirrors the MSR value of the
> > current CPU.  Initialize all tasks with the default MSR value.  Then, on
> > schedule in, check the saved task MSR vs the per-cpu value.  If
> > different proceed to write the MSR.  If not avoid the overhead of the
> > MSR write and continue.
> 
> It's probably nice to note how the WRMSR is special here, in addition to
> the comments below.

Sure,

> 
> >  #endif /*_ASM_X86_PKEYS_INTERNAL_H */
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 97143d87994c..da2381136b2d 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -18,6 +18,7 @@ struct vm86;
> >  #include <asm/cpufeatures.h>
> >  #include <asm/page.h>
> >  #include <asm/pgtable_types.h>
> > +#include <asm/pkeys_common.h>
> >  #include <asm/percpu.h>
> >  #include <asm/msr.h>
> >  #include <asm/desc_defs.h>
> > @@ -542,6 +543,11 @@ struct thread_struct {
> >  
> >  	unsigned int		sig_on_uaccess_err:1;
> >  
> > +#ifdef	CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> > +	/* Saved Protection key register for supervisor mappings */
> > +	u32			saved_pkrs;
> > +#endif
> 
> Could you take a look around thread_struct and see if there are some
> other MSRs near which you can stash this?  This seems like a bit of a
> lonely place.

Are you more concerned with aesthetics or the in memory struct layout?

How about I put it after error_code?

	unsigned long           error_code;                                     
+                                                                               
+#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS                                        
+       /* Saved Protection key register for supervisor mappings */             
+       u32                     saved_pkrs;                                     
+#endif                                                                         
+                                                                               

?

> 
> ...
> >  void flush_thread(void)
> >  {
> >  	struct task_struct *tsk = current;
> > @@ -195,6 +212,8 @@ void flush_thread(void)
> >  	memset(tsk->thread.tls_array, 0, sizeof(tsk->thread.tls_array));
> >  
> >  	fpu__clear_all(&tsk->thread.fpu);
> > +
> > +	pks_init_task(tsk);
> >  }
> >  
> >  void disable_TSC(void)
> > @@ -644,6 +663,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p)
> >  
> >  	if ((tifp ^ tifn) & _TIF_SLD)
> >  		switch_to_sld(tifn);
> > +
> > +	pks_sched_in();
> >  }
> >  
> >  /*
> > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> > index 3cf8f775f36d..30f65dd3d0c5 100644
> > --- a/arch/x86/mm/pkeys.c
> > +++ b/arch/x86/mm/pkeys.c
> > @@ -229,3 +229,31 @@ u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int flags)
> >  
> >  	return pk_reg;
> >  }
> > +
> > +DEFINE_PER_CPU(u32, pkrs_cache);
> > +
> > +/**
> > + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is not
> > + * serializing but still maintains ordering properties similar to WRPKRU.
> > + * The current SDM section on PKRS needs updating but should be the same as
> > + * that of WRPKRU.  So to quote from the WRPKRU text:
> > + *
> > + * 	WRPKRU will never execute transiently. Memory accesses
> > + * 	affected by PKRU register will not execute (even transiently)
> > + * 	until all prior executions of WRPKRU have completed execution
> > + * 	and updated the PKRU register.
> > + */
> > +void write_pkrs(u32 new_pkrs)
> > +{
> > +	u32 *pkrs;
> > +
> > +	if (!static_cpu_has(X86_FEATURE_PKS))
> > +		return;
> > +
> > +	pkrs = get_cpu_ptr(&pkrs_cache);
> > +	if (*pkrs != new_pkrs) {
> > +		*pkrs = new_pkrs;
> > +		wrmsrl(MSR_IA32_PKRS, new_pkrs);
> > +	}
> > +	put_cpu_ptr(pkrs);
> > +}
> > 
> 
> It bugs me a *bit* that this is being called in a preempt-disabled
> region, but we still bother with the get/put_cpu jazz.  Are there other
> future call-sites for this that aren't in preempt-disabled regions?

I'm not specifically disabling preempt before calling write_pkrs except in the
next patch (which is buggy because I meant to have it around the modification
of thread.saved_pkrs as well).  But that was to protect the thread variable not
the percpu cache vs MSR.

My thought above was it is safer for this call to ensure the per-cpu variable
is consistent with the register.  The other calls to write_pkrs() may require
preemption disable but for reasons unrelated to write_pkrs' state.

After some research I've now fully confused myself if this is needed in patch
7/9 where write_pkrs() is called from the exception handing code.  But I think
it is needed there.  Isn't it?

Since preempt_disable() is nestable I think this is ok correct?

Ira

  reply	other threads:[~2020-10-14 22:36 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 19:42 [PATCH RFC V3 0/9] PKS: Add Protection Keys Supervisor (PKS) support RFC v3 ira.weiny
2020-10-09 19:42 ` [PATCH RFC V3 1/9] x86/pkeys: Create pkeys_common.h ira.weiny
2020-10-13 17:46   ` Dave Hansen
2020-10-13 19:44     ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 2/9] x86/fpu: Refactor arch_set_user_pkey_access() for PKS support ira.weiny
2020-10-13 17:50   ` Dave Hansen
2020-10-13 23:56     ` Ira Weiny
2020-10-16 10:57   ` Peter Zijlstra
2020-10-17  3:32     ` Ira Weiny
2020-10-19  9:35       ` Peter Zijlstra
2020-10-09 19:42 ` [PATCH RFC V3 3/9] x86/pks: Enable Protection Keys Supervisor (PKS) ira.weiny
2020-10-13 18:23   ` Dave Hansen
2020-10-14  2:08     ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch ira.weiny
2020-10-13 18:31   ` Dave Hansen
2020-10-14 22:36     ` Ira Weiny [this message]
2020-10-16 11:12     ` Peter Zijlstra
2020-10-17  5:14       ` Ira Weiny
2020-10-19  9:37         ` Peter Zijlstra
2020-10-19 18:48           ` Ira Weiny
2020-10-16 11:06   ` Peter Zijlstra
2020-10-17  5:37     ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API ira.weiny
2020-10-13 18:43   ` Dave Hansen
2020-10-15  1:08     ` Ira Weiny
2020-10-16 11:07   ` Peter Zijlstra
2020-10-17  5:42     ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 6/9] x86/entry: Pass irqentry_state_t by reference ira.weiny
2020-10-16 11:45   ` Peter Zijlstra
2020-10-16 12:55     ` Thomas Gleixner
2020-10-19  5:37       ` Ira Weiny
2020-10-19  9:32         ` Thomas Gleixner
2020-10-19 20:26           ` Ira Weiny
2020-10-19 21:12             ` Thomas Gleixner
2020-10-20 14:10               ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions ira.weiny
2020-10-13 18:52   ` Dave Hansen
2020-10-15  3:46     ` Ira Weiny
2020-10-15  4:06       ` Dave Hansen
2020-10-15  4:18         ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 8/9] x86/fault: Report the PKRS state on fault ira.weiny
2020-10-13 18:56   ` Dave Hansen
2020-10-15  4:13     ` Ira Weiny
2020-10-09 19:42 ` [PATCH RFC V3 9/9] x86/pks: Add PKS test code ira.weiny
2020-10-13 19:02   ` Dave Hansen
2020-10-15  4:46     ` Ira Weiny
2020-10-09 20:18 ` [PATCH RFC V3 0/9] PKS: Add Protection Keys Supervisor (PKS) support RFC v3 Ira Weiny

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=20201014223642.GN2046448@iweiny-DESK2.sc.intel.com \
    --to=ira.weiny@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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).