Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp748627yba; Fri, 26 Apr 2019 08:08:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxgO2GShgMj0Nb1SHRxPousDRHBGrWEegnd5aBD06h2KdXHkm2kjdP7aspuM/jVXuS28lyL X-Received: by 2002:a63:4c26:: with SMTP id z38mr44983001pga.425.1556291335219; Fri, 26 Apr 2019 08:08:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556291335; cv=none; d=google.com; s=arc-20160816; b=DkeCZL5EriUg5fkP5j9ojBfXFV7ymenibyl/ZOyzHDa+MattzqADFWe/CyBmOp/4rF xZJd+p39j8Ptf7agdS03Nrx9GBwWaUvwJxlpFOwNmLCJ42UeStUGPboHe5TISX18Ht0A ltgYr6DyPtMVdx0snfBVbsXrgTE2W67vSuUCOrQeZKOCZVsMoXbR38YD8c+G5gp0ZIs9 mg48YIKSmn4/fprKfVXrJrRferpS9XEqRaJfuCNpIV6oVgyn2/4unTsMBYK+oWP542wm 9o8SS087Lhx4KvM+RS59ocgmBoIQftkGNCxazHWu6djzLxtmlLYxMW9aJJKoKMpl2Dbg +4MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=IiTlllJV7T8Ybav7NUjeUyZVUhhnS7kZRU1PPhbGkJM=; b=zXju4awutSe7BLhsoAZTaybLI7NQZUKgvGeB5UsfqKtQs+h4cGO+uenLvFrMBYjhqj NQ/14MkKMlnU1ySQ34D7wZlrOfq4zeRZRKrKh4MXhDgoWGP8rY0YEf/2uk/sQJhCL+Cm 6NZLnh5a7O3v7CFh5fWYQ5sQmVi/Uh/AkekuaRnJU6sY2AWK3B02ENqH1n5HWITw49M7 Z3nhEOEyE89wRdByPu6l+UpKYXl9RreogR771+r3n6ZEHFGgTxmeUQuCF2aaOePFuDUd MLSXOczkDxhYeqI6Revo6J2yiWAX+PpRD2yyeMWCiJXostYrCaz9Mq2Eae1I2CkvamXv lJRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=lL2n9vt8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u5si23164707pgp.240.2019.04.26.08.08.38; Fri, 26 Apr 2019 08:08:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=lL2n9vt8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726617AbfDZPHa (ORCPT + 99 others); Fri, 26 Apr 2019 11:07:30 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:45300 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726310AbfDZPHa (ORCPT ); Fri, 26 Apr 2019 11:07:30 -0400 Received: by mail-pl1-f193.google.com with SMTP id o5so1704576pls.12 for ; Fri, 26 Apr 2019 08:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IiTlllJV7T8Ybav7NUjeUyZVUhhnS7kZRU1PPhbGkJM=; b=lL2n9vt8GnIPUDFoTEJvf33Y5pQF3uo+rWu5qEgbH4HLxkSLx9jcc9TgyzRHksCYAj fmqBt8KcPRhmOtkK37ubeAfoG6y85dhMIr00G8/l5QKNCrHl+uAHYqZa3tqrKJGN/hNF zMa3B964tLPhi0oSvuAu+2gT3es4gkyza8ZHVSBXBM3/lziiDPPsEq1fEoXGTlrl9ymn HW+jVq0eHkWEj5PWkmH+nzUBebi0aQ1DIrGkI35HSVEbH8s6MoxMjQlUwrNbge+pBTwd EISfz9afMMiyAm8SlpyJVhLYaLgXSI/p17RwVC/21KPAGuwHhTZG4PtV9zb52apojoWM ss8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IiTlllJV7T8Ybav7NUjeUyZVUhhnS7kZRU1PPhbGkJM=; b=pqcKM8Yn3zavK6AARlSaFuz1eY9lfgWAtLAIDWaLzkXm4gzEmaVS2ay/YsD7b4cKlT tt9jnM+M6eb2vCRnVi8VMrhZUyTA2KnCZD6bZ+bw3cdmE7O9Ew+Iwae988+Xy+a/ZfB8 dDrk/zFJLlfRUuPh4YpMghG6rdU8z/duEicB8B5BskkrmF54pz5YM9XHFynZrPc+sJCl gwt3rn2vkk9o1mh0VMU4MIZ2EI8Qn1LHCy5upFZNdJW7HySZ7DEK3jMKGFhsMetNf4K0 EcnTJn2wj1BzBqbfPO6uklT4pV0AEiuflfH4LedS+/HUAu06LONpIg/a57zliCMhNIHd TPbA== X-Gm-Message-State: APjAAAUz69q9Qb8XJhXqjBzoHDqPy8PerjF0GoylFiJRinEhYbXjBIWP U0w4vJnl+Oh0CDkQfYkj+IcmXQ== X-Received: by 2002:a17:902:7b8e:: with SMTP id w14mr28880635pll.202.1556291249630; Fri, 26 Apr 2019 08:07:29 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:dd4b:950:9d5a:d566? ([2601:646:c200:1ef2:dd4b:950:9d5a:d566]) by smtp.gmail.com with ESMTPSA id l15sm11072795pgb.71.2019.04.26.08.07.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 08:07:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: <1556290658.2833.28.camel@HansenPartnership.com> Date: Fri, 26 Apr 2019 08:07:27 -0700 Cc: Dave Hansen , Mike Rapoport , linux-kernel@vger.kernel.org, Alexandre Chartre , Andy Lutomirski , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Jonathan Adams , Kees Cook , Paul Turner , Peter Zijlstra , Thomas Gleixner , linux-mm@kvack.org, linux-security-module@vger.kernel.org, x86@kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <54090243-E4C7-4C66-8025-AFE0DF5DF337@amacapital.net> References: <1556228754-12996-1-git-send-email-rppt@linux.ibm.com> <1556228754-12996-3-git-send-email-rppt@linux.ibm.com> <627d9321-466f-c4ed-c658-6b8567648dc6@intel.com> <1556290658.2833.28.camel@HansenPartnership.com> To: James Bottomley Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 26, 2019, at 7:57 AM, James Bottomley wrote: >=20 >> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote: >>> On 4/25/19 2:45 PM, Mike Rapoport wrote: >>> After the isolated system call finishes, the mappings created >>> during its execution are cleared. >>=20 >> Yikes. I guess that stops someone from calling write() a bunch of >> times on every filesystem using every block device driver and all the >> DM code to get a lot of code/data faulted in. But, it also means not >> even long-running processes will ever have a chance of behaving >> anything close to normally. >>=20 >> Is this something you think can be rectified or is there something >> fundamental that would keep SCI page tables from being cached across >> different invocations of the same syscall? >=20 > There is some work being done to look at pre-populating the isolated > address space with the expected execution footprint of the system call, > yes. It lessens the ROP gadget protection slightly because you might > find a gadget in the pre-populated code, but it solves a lot of the > overhead problem. >=20 I=E2=80=99m not even remotely a ROP expert, but: what stops a ROP payload fr= om using all the =E2=80=9Cfault-in=E2=80=9D gadgets that exist =E2=80=94 any= function that can return on an error without doing to much will fault in th= e whole page containing the function. To improve this, we would want some thing that would try to check whether th= e caller is actually supposed to call the callee, which is more or less the h= ard part of CFI. So can=E2=80=99t we just do CFI and call it a day? On top of that, a robust, maintainable implementation of this thing seems ve= ry complicated =E2=80=94 for example, what happens if vfree() gets called?