Received-SPF: pass (google.com: domain of linux-kernel+bounces-160453-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240321215622.3396410-2-aruna.ramakrishna@oracle.com>
 <20240425210540.3265342-1-jeffxu@chromium.org> <7054B528-C603-4EAC-B48D-784480DFE4B6@oracle.com>
 <CALmYWFsW5XcM8PYwd=SCthfgjC3TxqVz=DjnCuV8TU7k+_jLaQ@mail.gmail.com>
 <CABi2SkVvGWa0=Q9AEkTGAr6f_hZ54Ekrxw5CdgvrRKWtNPNkng@mail.gmail.com> <d0162c76c25bc8e1c876aebe8e243ff2e6862359.camel@intel.com>
In-Reply-To: <d0162c76c25bc8e1c876aebe8e243ff2e6862359.camel@intel.com>
From: Jeff Xu <jeffxu@google.com>
Date: Fri, 26 Apr 2024 10:13:00 -0700
Message-ID: <CALmYWFtnquTxBP+072xy1iTK+Qb-YKJ8iwarvQMiGApT9=P8Jw@mail.gmail.com>
Subject: Re: [RFC PATCH v2 1/1] x86/pkeys: update PKRU to enable pkey 0 before XSAVE
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "jeffxu@chromium.org" <jeffxu@chromium.org>, 
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, 
	"jannh@google.com" <jannh@google.com>, 
	"andrew.brownsword@oracle.com" <andrew.brownsword@oracle.com>, 
	"matthias.neugschwandtner@oracle.com" <matthias.neugschwandtner@oracle.com>, 
	"tglx@linutronix.de" <tglx@linutronix.de>, 
	"aruna.ramakrishna@oracle.com" <aruna.ramakrishna@oracle.com>, 
	"sroettger@google.com" <sroettger@google.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"keescook@chromium.org" <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 26, 2024 at 9:33=E2=80=AFAM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Fri, 2024-04-26 at 09:13 -0700, Jeff Xu wrote:
> > > > I=E2=80=99m wary about reordering anything here. Also, this code is=
 not aware of
> > > > the altstack permissions. I=E2=80=99m wondering if wrpkru(0) is nee=
ded here too.
> > > >
> > > We can't change PKRU after restore_sigcontext,  the calling thread
> > > would have PKRU 0, not the original PKRU from before handling the
> > > signal.
> >
> > probably putting restore_altstack ahead of restore_sigcontext would be
> > good enough.
> > restore_altstack doesn't seem to need to be after restore_sigcontex,
> > it reads data
> > from the sigframe and calls do_sigaltstack to update the current struct=
.
>
> Just was CCed, and haven't reviewed the whole thread.
>
> But I hit an issue with the ordering in setting up a signal frame. I note=
d that
> the ordering in sigreturn was potentially wrong in the same way:
> https://lore.kernel.org/lkml/20231107182251.91276-1-rick.p.edgecombe@inte=
l.com/
>
> It might be useful analysis.

Great! so it is already noticed. It can be fixed in this patch set.