From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyrill Gorcunov Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack Date: Fri, 8 Jun 2018 18:52:25 +0300 Message-ID: <20180608155225.GC2525@uranus> References: <20180607143807.3611-7-yu-cheng.yu@intel.com> <1528403417.5265.35.camel@2b52.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: "H. J. Lu" , Dmitry Safonov , Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com List-Id: linux-arch.vger.kernel.org On Fri, Jun 08, 2018 at 07:57:22AM -0700, Andy Lutomirski wrote: > On Fri, Jun 8, 2018 at 5:24 AM H.J. Lu wrote: > > > > On Thu, Jun 7, 2018 at 9:38 PM, Andy Lutomirski wrote: > > > On Thu, Jun 7, 2018 at 9:10 PM H.J. Lu wrote: > > >> > > >> On Thu, Jun 7, 2018 at 4:01 PM, Andy Lutomirski wrote: > > >> > > > > > > By the time malicious code issue its own syscalls, you've already lost > > > the battle. I could probably be convinced that a lock-CET-on feature > > > that applies *only* to the calling thread and is not inherited by > > > clone() is a decent idea, but I'd want to see someone who understands > > > the state of the art in exploit design justify it. You're also going > > > to need to figure out how to make CRIU work if you allow locking CET > > > on. > > > > > > A priori, I think we should just not provide a lock mechanism. > > > > We need a door for CET. But it is a very bad idea to leave it open > > all the time. I don't know much about CRIU, If it is Checkpoint/Restore > > In Userspace. Can you free any application with AVX512 on AVX512 > > machine and restore it on non-AVX512 machine? > > Presumably not -- if the program uses AVX512 and AVX512 goes away, > then the program won't be happy. Yes. In most scenarios we require the fpu capability to be the same on both machines (in case of migration) or/and not being changed between c/r cycles. ... > As an aside, where are the latest CET docs? I've found the "CET > technology preview 2.0", but it doesn't seem to be very clear or > entirely complete. +1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f68.google.com ([209.85.215.68]:46705 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbeFHPw2 (ORCPT ); Fri, 8 Jun 2018 11:52:28 -0400 Date: Fri, 8 Jun 2018 18:52:25 +0300 From: Cyrill Gorcunov Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack Message-ID: <20180608155225.GC2525@uranus> References: <20180607143807.3611-7-yu-cheng.yu@intel.com> <1528403417.5265.35.camel@2b52.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: "H. J. Lu" , Dmitry Safonov , Yu-cheng Yu , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com Message-ID: <20180608155225.DMCH7b7-eWejeCn_ucW29oqtctu3NmNIjcm30ZUhOSI@z> On Fri, Jun 08, 2018 at 07:57:22AM -0700, Andy Lutomirski wrote: > On Fri, Jun 8, 2018 at 5:24 AM H.J. Lu wrote: > > > > On Thu, Jun 7, 2018 at 9:38 PM, Andy Lutomirski wrote: > > > On Thu, Jun 7, 2018 at 9:10 PM H.J. Lu wrote: > > >> > > >> On Thu, Jun 7, 2018 at 4:01 PM, Andy Lutomirski wrote: > > >> > > > > > > By the time malicious code issue its own syscalls, you've already lost > > > the battle. I could probably be convinced that a lock-CET-on feature > > > that applies *only* to the calling thread and is not inherited by > > > clone() is a decent idea, but I'd want to see someone who understands > > > the state of the art in exploit design justify it. You're also going > > > to need to figure out how to make CRIU work if you allow locking CET > > > on. > > > > > > A priori, I think we should just not provide a lock mechanism. > > > > We need a door for CET. But it is a very bad idea to leave it open > > all the time. I don't know much about CRIU, If it is Checkpoint/Restore > > In Userspace. Can you free any application with AVX512 on AVX512 > > machine and restore it on non-AVX512 machine? > > Presumably not -- if the program uses AVX512 and AVX512 goes away, > then the program won't be happy. Yes. In most scenarios we require the fpu capability to be the same on both machines (in case of migration) or/and not being changed between c/r cycles. ... > As an aside, where are the latest CET docs? I've found the "CET > technology preview 2.0", but it doesn't seem to be very clear or > entirely complete. +1