[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180607200714.GA2525@uranus>
Date: Thu, 7 Jun 2018 23:07:14 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Yu-cheng Yu <yu-cheng.yu@...el.com>,
Florian Weimer <fweimer@...hat.com>,
Dmitry Safonov <dsafonov@...tuozzo.com>,
LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. J. Lu" <hjl.tools@...il.com>,
"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Jonathan Corbet <corbet@....net>,
Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
mike.kravetz@...cle.com
Subject: Re: [PATCH 03/10] x86/cet: Signal handling for shadow stack
On Thu, Jun 07, 2018 at 11:30:34AM -0700, Andy Lutomirski wrote:
> On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu <yu-cheng.yu@...el.com> wrote:
> >
> > Set and restore shadow stack pointer for signals.
>
> How does this interact with siglongjmp()?
>
> This patch makes me extremely nervous due to the possibility of ABI
> issues and CRIU breakage.
>
> > diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
> > index 844d60eb1882..6c8997a0156a 100644
> > --- a/arch/x86/include/uapi/asm/sigcontext.h
> > +++ b/arch/x86/include/uapi/asm/sigcontext.h
> > @@ -230,6 +230,7 @@ struct sigcontext_32 {
> > __u32 fpstate; /* Zero when no FPU/extended context */
> > __u32 oldmask;
> > __u32 cr2;
> > + __u32 ssp;
> > };
> >
> > /*
> > @@ -262,6 +263,7 @@ struct sigcontext_64 {
> > __u64 trapno;
> > __u64 oldmask;
> > __u64 cr2;
> > + __u64 ssp;
> >
> > /*
> > * fpstate is really (struct _fpstate *) or (struct _xstate *)
> > @@ -320,6 +322,7 @@ struct sigcontext {
> > struct _fpstate __user *fpstate;
> > __u32 oldmask;
> > __u32 cr2;
> > + __u32 ssp;
>
> Is it actually okay to modify these structures like this? They're
> part of the user ABI, and I don't know whether any user code relies on
> the size being constant.
For sure it might cause problems for CRIU since we have
similar definitions for this structure inside our code.
That said if kernel is about to modify the structures it
should keep backward compatibility at least if a user
passes previous version of a structure @ssp should be
set to something safe by the kernel itself.
I didn't read the whole series of patches in details
yet, hopefully will be able tomorrow. Thanks Andy for
CC'ing!
Powered by blists - more mailing lists