From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D5FFC43218 for ; Fri, 26 Apr 2019 15:07:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A4E520675 for ; Fri, 26 Apr 2019 15:07:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="lL2n9vt8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726549AbfDZPHa (ORCPT ); Fri, 26 Apr 2019 11:07:30 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:43758 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726537AbfDZPHa (ORCPT ); Fri, 26 Apr 2019 11:07:30 -0400 Received: by mail-pl1-f196.google.com with SMTP id n8so1703194plp.10 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=VS+YftbUsvUTN6JkGMuoK6oN/FHM72MqSsHxZfeTZ18q9wh5cbaZ84CqZr2s/jmpDM T1rrZaez7L2XUgRbU9xq4IWmqavWwE66bczRDD5oGfHx6KAM5j5QhyQc27Rg8IhJpEon cKrpWaweLICV3keJs2vGzyYXKLvlXD02QN9olRa4a7HknLTDGojLJLPpkCDMsesrclys tRJWVJKYCQGAc6y1BKxnqN76hjf9C7pZwb02No8X/vfqTOBuSMbX3jUZhoga4CHuhLG+ UglSKnNAsBFyzNgsTrE3WkeG9TA9+tSe3NOw3b5pnE2cLqWKIoNFBJkK3DobknJbD3aT E9Xg== X-Gm-Message-State: APjAAAXNGyrpcF/Qrl2KS4hUwJd3IksZfU1qIAUj4sOWn8sui5jm7rYt NgWcc8VvWqjzQ5nAkv6mT4YzqA== X-Google-Smtp-Source: APXvYqxw6s47f9ZtAEqXzz4CE/DWzlsYAbZ43O38HXxSazAc+xuzWMJmNzZfd0ZmQluLX4nGUmluqQ== 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: > 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?