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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 231FBC282CE for ; Mon, 22 Apr 2019 22:23:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E292A205F4 for ; Mon, 22 Apr 2019 22:23:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Vl0fYQ0U" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729014AbfDVWXr (ORCPT ); Mon, 22 Apr 2019 18:23:47 -0400 Received: from mail-vk1-f196.google.com ([209.85.221.196]:40198 "EHLO mail-vk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727336AbfDVWXq (ORCPT ); Mon, 22 Apr 2019 18:23:46 -0400 Received: by mail-vk1-f196.google.com with SMTP id l17so2755965vke.7 for ; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=Vl0fYQ0UCHGtndl0jafErZw5vqbDAq4DrFX3SfBAIMhEhneL9rXawPTcud8fgV5g3D W/sHE49ARVD9KYD5FloU01n2RfA2pTgnKMthR4SE5EVifhT+Zv7f89iMoQqyLkH17UHR Ufjeoo3iZe8A1ywqY/dQX9OJ6hQY+RdFMicuSiIFmS2kjW0kxDgF0PQchZJoFDeQwLJ4 Bu9iNZw8/m1h5Vvq6bsIi0oFDRabTh4fUKE/VXZ1BpEeHCWZiVc862ytrlz+nAaTR+Cp kF/vZydc6r2yg2X0nSiZbBoPzLhOuIzzabOzb88ffPr/VLLo66HUZNIe7JxAbYTKUz7T O38g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=cK8b/Gs3lxWC8ZjuCKYtO6bMHQNgAftcIlEdZxdiAka7Bz7go5OQxanLvTx/P6h8Q3 f47mewUtY4fpXDD7GEKjVcG9e/2xZtiEdPg9RfvGzMk+fbhRVweuYk2FHzeco4z++xHA Ok3/J2UzxGCf3woyjiZrbd6Z8z2MM9cecUtROCgvvJlcrjkFeFobTyVu5XaNxOKhfGc3 ZBBRCLvqpwpzpbcr4mIn6NnCQeLjCZHQQMLk6Ob2wlQ1+q9k4nFMvTAXqwqULcxL3At4 Qu9I6rEI3R/utoGiC3DvABPx96dX4LJmFLcM3IZFgZfCBDowNwV6wz5aoxPY7NDgBBPB A0ug== X-Gm-Message-State: APjAAAUHK+zIz0EKYcHs3mffWtPjyXMaLW/xNLXyRdiwXajQVp32Gbyn d+SzXFZChJc+phBUfUaFyCsKxnzLprMfiKGIb4U5RQ== X-Google-Smtp-Source: APXvYqxiq50qJu8wanUuH+yOCTaJNMUpHEhGXVEwCujnFscJAmlLegU3s6VeZj+61I7iVGG+tUCCywSMlxsTtse/mUo= X-Received: by 2002:a1f:2e07:: with SMTP id u7mr11692664vku.44.1555971825052; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) MIME-Version: 1.0 References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <56A175F6-E5DA-4BBD-B244-53B786F27B7F@gmail.com> <20190417172632.GA95485@gmail.com> <063753CC-5D83-4789-B594-019048DE22D9@gmail.com> <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> From: Kees Cook Date: Mon, 22 Apr 2019 15:23:32 -0700 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Khalid Aziz Cc: Andy Lutomirski , Linus Torvalds , Thomas Gleixner , Nadav Amit , Ingo Molnar , Juerg Haefliger , Tycho Andersen , Julian Stecklina , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris hyser , Tyler Hicks , David Woodhouse , Andrew Cooper , Jon Masters , Boris Ostrovsky , iommu , X86 ML , "linux-alpha@vger.kernel.org" , "open list:DOCUMENTATION" , Linux List Kernel Mailing , Linux-MM , LSM List , Khalid Aziz , Andrew Morton , Peter Zijlstra , Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Arjan van de Ven , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote: > > On 4/17/19 11:41 PM, Kees Cook wrote: > > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote: > >> I don't think this type of NX goof was ever the argument for XPFO. > >> The main argument I've heard is that a malicious user program writes a > >> ROP payload into user memory (regular anonymous user memory) and then > >> gets the kernel to erroneously set RSP (*not* RIP) to point there. > > > > Well, more than just ROP. Any of the various attack primitives. The NX > > stuff is about moving RIP: SMEP-bypassing. But there is still basic > > SMAP-bypassing for putting a malicious structure in userspace and > > having the kernel access it via the linear mapping, etc. > > > >> I find this argument fairly weak for a couple reasons. First, if > >> we're worried about this, let's do in-kernel CFI, not XPFO, to > > > > CFI is getting much closer. Getting the kernel happy under Clang, LTO, > > and CFI is under active development. (It's functional for arm64 > > already, and pieces have been getting upstreamed.) > > > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :) All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream. -- Kees Cook 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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL 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 0D138C10F11 for ; Mon, 22 Apr 2019 22:23:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B0F6E205F4 for ; Mon, 22 Apr 2019 22:23:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Vl0fYQ0U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0F6E205F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4BDD56B0003; Mon, 22 Apr 2019 18:23:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 494746B0006; Mon, 22 Apr 2019 18:23:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 384586B0007; Mon, 22 Apr 2019 18:23:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) by kanga.kvack.org (Postfix) with ESMTP id 129106B0003 for ; Mon, 22 Apr 2019 18:23:47 -0400 (EDT) Received: by mail-vk1-f198.google.com with SMTP id v4so6211904vka.10 for ; Mon, 22 Apr 2019 15:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:references :in-reply-to:from:date:message-id:subject:to:cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=GshvWUUYvJRxhfj9bc43ASNJXUfJLoOBzFWzqep+U6AoJfPuV7T3RSuuXv/ilWPJFy 17KZYBdV05OoNH0PQ30nSIVAieRpFUbG+DoTgtm6aouPsAy1GgqrE3DchYOvNjKjYc1b 4U5EmCLSqWaKbGOZyZuUoNe5grrwrzne8ok9Od9c3aY/9sJS5MfdKucnuPJRGIET21Ag bL1/FH93GpC6/+IsPbDrTDrajo2krQkh5YsUOuHtXDH4BUqqZAdF0k5KzbFWNwZP5rBO 0HJaJ7r+SgCyYGHlh824xT10Bp8Cgs8mHQTbR0LezmMb0qdjxx3s1epBhbaQJTy6NdqS WOXw== X-Gm-Message-State: APjAAAVqkwMmMPh9qv9jp+N8hWn2rhzCapUSxNB/HdTfrqUNXPlObNJB k4SkdmG80n6CKeSjCaDNELHwcxBvjEmQAYKBWZAXGcsK8v0oYxjEgIvOMOnNnSYXEQR/R5uw0eU RIMFDEpSZkgc2mZizbgdfxiptHFcDorXN6MV7geYX/ziq1sify4NFXR9Fk7kjKuhfBQ== X-Received: by 2002:a1f:28d7:: with SMTP id o206mr10861685vko.36.1555971826737; Mon, 22 Apr 2019 15:23:46 -0700 (PDT) X-Received: by 2002:a1f:28d7:: with SMTP id o206mr10861661vko.36.1555971825654; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555971825; cv=none; d=google.com; s=arc-20160816; b=GIHj4eqMsxUW8NlRpIPgrpudYln9rbcDi6ydzLofTF4HBSODj3RliXmR2DP3My9GYr QFRV5ShIXJfJCLlj7Rsjq5Eqv/eQZMbx3G4FcKAPI+Sa4/XgUisK0O8ddfus7L95zPo+ Qb6SVrZmDAsyFe89s36Ughlrw6p5D+EiOYIQFs/bIyer8K+AMF+IMEAfKp9YDFNHiac+ tTKmTDTtl7XMUrpZChjnOeTINQ9mefJKUsj7vkbIgm6HcpSC5gQ7Ye1adrqd4g5aY1mi GySG2uRQfzLOuZXCbwa17WYV2YvdJaK/NM0NWLRVc1aXYI7OvzcVUJrZxT33Q6/S5ZMB ciCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=ry3oGFmLEfjh/8wSooxsIexK1rhyZ4CY0Sjjwp5/8MsSfQkbxRuPhZyRNSSmUC9GON YcqQKGv0YE44ItHBpOdVYpAB2VNPfJ1rLzn+jT6mw059O4DzPgfEECOZI1Ag7g4chC9G Ex7Q5qR0gZnz+xy8V+42tf4HbcSWDSW/x1BphP+oeyZPQ1vPoPpWSqDIjvsYRzg5aUOZ BRKunjTnGEtbadN5rcddC/UJbpBa4ccYGcOyBUKVW0/9IvJx4OfSYqRH30J0k2jB48U9 IpIRxDNFFvNjAwda7q2J4eTW+6JKcyr7D83IjJI8YOSonBOZjdE2GTroEs1jXS09ewnC LhIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Vl0fYQ0U; spf=pass (google.com: domain of keescook@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=keescook@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id l70sor954965vke.12.2019.04.22.15.23.45 for (Google Transport Security); Mon, 22 Apr 2019 15:23:45 -0700 (PDT) Received-SPF: pass (google.com: domain of keescook@google.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Vl0fYQ0U; spf=pass (google.com: domain of keescook@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=keescook@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=Vl0fYQ0UCHGtndl0jafErZw5vqbDAq4DrFX3SfBAIMhEhneL9rXawPTcud8fgV5g3D W/sHE49ARVD9KYD5FloU01n2RfA2pTgnKMthR4SE5EVifhT+Zv7f89iMoQqyLkH17UHR Ufjeoo3iZe8A1ywqY/dQX9OJ6hQY+RdFMicuSiIFmS2kjW0kxDgF0PQchZJoFDeQwLJ4 Bu9iNZw8/m1h5Vvq6bsIi0oFDRabTh4fUKE/VXZ1BpEeHCWZiVc862ytrlz+nAaTR+Cp kF/vZydc6r2yg2X0nSiZbBoPzLhOuIzzabOzb88ffPr/VLLo66HUZNIe7JxAbYTKUz7T O38g== X-Google-Smtp-Source: APXvYqxiq50qJu8wanUuH+yOCTaJNMUpHEhGXVEwCujnFscJAmlLegU3s6VeZj+61I7iVGG+tUCCywSMlxsTtse/mUo= X-Received: by 2002:a1f:2e07:: with SMTP id u7mr11692664vku.44.1555971825052; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) MIME-Version: 1.0 References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <56A175F6-E5DA-4BBD-B244-53B786F27B7F@gmail.com> <20190417172632.GA95485@gmail.com> <063753CC-5D83-4789-B594-019048DE22D9@gmail.com> <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> From: Kees Cook Date: Mon, 22 Apr 2019 15:23:32 -0700 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Khalid Aziz Cc: Andy Lutomirski , Linus Torvalds , Thomas Gleixner , Nadav Amit , Ingo Molnar , Juerg Haefliger , Tycho Andersen , Julian Stecklina , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris hyser , Tyler Hicks , David Woodhouse , Andrew Cooper , Jon Masters , Boris Ostrovsky , iommu , X86 ML , "linux-alpha@vger.kernel.org" , "open list:DOCUMENTATION" , Linux List Kernel Mailing , Linux-MM , LSM List , Khalid Aziz , Andrew Morton , Peter Zijlstra , Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Arjan van de Ven , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote: > > On 4/17/19 11:41 PM, Kees Cook wrote: > > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote: > >> I don't think this type of NX goof was ever the argument for XPFO. > >> The main argument I've heard is that a malicious user program writes a > >> ROP payload into user memory (regular anonymous user memory) and then > >> gets the kernel to erroneously set RSP (*not* RIP) to point there. > > > > Well, more than just ROP. Any of the various attack primitives. The NX > > stuff is about moving RIP: SMEP-bypassing. But there is still basic > > SMAP-bypassing for putting a malicious structure in userspace and > > having the kernel access it via the linear mapping, etc. > > > >> I find this argument fairly weak for a couple reasons. First, if > >> we're worried about this, let's do in-kernel CFI, not XPFO, to > > > > CFI is getting much closer. Getting the kernel happy under Clang, LTO, > > and CFI is under active development. (It's functional for arm64 > > already, and pieces have been getting upstreamed.) > > > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :) All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook via iommu Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Date: Mon, 22 Apr 2019 15:23:32 -0700 Message-ID: References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <56A175F6-E5DA-4BBD-B244-53B786F27B7F@gmail.com> <20190417172632.GA95485@gmail.com> <063753CC-5D83-4789-B594-019048DE22D9@gmail.com> <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> Reply-To: Kees Cook Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Khalid Aziz Cc: Dave Hansen , "open list:DOCUMENTATION" , Linux-MM , deepa.srinivasan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, "H. Peter Anvin" , Thomas Gleixner , Tycho Andersen , X86 ML , LSM List , Ingo Molnar , Julian Stecklina , Arjan van de Ven , Peter Zijlstra , Konrad Rzeszutek Wilk , Jon Masters , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , chris hyser , "linux-alpha-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Khalid Aziz , Juerg Haefliger , Andrew Cooper List-Id: iommu@lists.linux-foundation.org On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote: > > On 4/17/19 11:41 PM, Kees Cook wrote: > > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote: > >> I don't think this type of NX goof was ever the argument for XPFO. > >> The main argument I've heard is that a malicious user program writes a > >> ROP payload into user memory (regular anonymous user memory) and then > >> gets the kernel to erroneously set RSP (*not* RIP) to point there. > > > > Well, more than just ROP. Any of the various attack primitives. The NX > > stuff is about moving RIP: SMEP-bypassing. But there is still basic > > SMAP-bypassing for putting a malicious structure in userspace and > > having the kernel access it via the linear mapping, etc. > > > >> I find this argument fairly weak for a couple reasons. First, if > >> we're worried about this, let's do in-kernel CFI, not XPFO, to > > > > CFI is getting much closer. Getting the kernel happy under Clang, LTO, > > and CFI is under active development. (It's functional for arm64 > > already, and pieces have been getting upstreamed.) > > > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :) All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream. -- Kees Cook 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C6EDFC282E1 for ; Mon, 22 Apr 2019 22:23:48 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8CF21205F4 for ; Mon, 22 Apr 2019 22:23:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Vl0fYQ0U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8CF21205F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lists.linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 36C08CAF; Mon, 22 Apr 2019 22:23:48 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D59DFCAD for ; Mon, 22 Apr 2019 22:23:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk1-f193.google.com (mail-vk1-f193.google.com [209.85.221.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49CAFF4 for ; Mon, 22 Apr 2019 22:23:46 +0000 (UTC) Received: by mail-vk1-f193.google.com with SMTP id x194so2767223vke.0 for ; Mon, 22 Apr 2019 15:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=Vl0fYQ0UCHGtndl0jafErZw5vqbDAq4DrFX3SfBAIMhEhneL9rXawPTcud8fgV5g3D W/sHE49ARVD9KYD5FloU01n2RfA2pTgnKMthR4SE5EVifhT+Zv7f89iMoQqyLkH17UHR Ufjeoo3iZe8A1ywqY/dQX9OJ6hQY+RdFMicuSiIFmS2kjW0kxDgF0PQchZJoFDeQwLJ4 Bu9iNZw8/m1h5Vvq6bsIi0oFDRabTh4fUKE/VXZ1BpEeHCWZiVc862ytrlz+nAaTR+Cp kF/vZydc6r2yg2X0nSiZbBoPzLhOuIzzabOzb88ffPr/VLLo66HUZNIe7JxAbYTKUz7T O38g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=In44Fqthg6QId2znFeE9X+xIprmxzJf9b3cTTy47QnATb/f3KFO+qOAvvyx6/zBwY2 DAxB2klT443nA6hbUE8AbAkAL5eOv6w6aB17zDsrM+JuphInZ1c99HpqaSBSaTz7OHWe smcdCb+jBEcNqswoRLMA2nWxkjxWjRwkyQ26PUONCfI0LLpJYX4Z3rh0MGQxKfvCG6A/ 405+KgzXcpqS9Pw2zS/+KZyZk0godHt0xdnaKKq3zwIbOtWjgf9YQaKL/ZyWz4D0tRdp nPmacTFR8H9h80DXeIiN1549jLM0qg7rw6CFzoNwd8wMOBLtoLaHWm13k1n2t2E06X19 HB+g== X-Gm-Message-State: APjAAAVDX98HfsVPwSWyphX8nJlV/FAX6mwOKdnMkXwCcKACPvbWY5ld uXX93b7A3GAznPhHCWznnd8ZiW1NjEK+l7s72wePUQ== X-Google-Smtp-Source: APXvYqxiq50qJu8wanUuH+yOCTaJNMUpHEhGXVEwCujnFscJAmlLegU3s6VeZj+61I7iVGG+tUCCywSMlxsTtse/mUo= X-Received: by 2002:a1f:2e07:: with SMTP id u7mr11692664vku.44.1555971825052; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) MIME-Version: 1.0 References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <56A175F6-E5DA-4BBD-B244-53B786F27B7F@gmail.com> <20190417172632.GA95485@gmail.com> <063753CC-5D83-4789-B594-019048DE22D9@gmail.com> <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> Date: Mon, 22 Apr 2019 15:23:32 -0700 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Khalid Aziz Cc: Dave Hansen , "open list:DOCUMENTATION" , Linux-MM , deepa.srinivasan@oracle.com, "H. Peter Anvin" , Thomas Gleixner , Tycho Andersen , X86 ML , LSM List , Ingo Molnar , Julian Stecklina , Arjan van de Ven , Peter Zijlstra , Konrad Rzeszutek Wilk , Jon Masters , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , chris hyser , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Kees Cook via iommu Reply-To: Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Message-ID: <20190422222332.COQaj6dLNF4scPERHWieGx2fFstcpMxQRhUV-mODLHg@z> On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote: > > On 4/17/19 11:41 PM, Kees Cook wrote: > > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote: > >> I don't think this type of NX goof was ever the argument for XPFO. > >> The main argument I've heard is that a malicious user program writes a > >> ROP payload into user memory (regular anonymous user memory) and then > >> gets the kernel to erroneously set RSP (*not* RIP) to point there. > > > > Well, more than just ROP. Any of the various attack primitives. The NX > > stuff is about moving RIP: SMEP-bypassing. But there is still basic > > SMAP-bypassing for putting a malicious structure in userspace and > > having the kernel access it via the linear mapping, etc. > > > >> I find this argument fairly weak for a couple reasons. First, if > >> we're worried about this, let's do in-kernel CFI, not XPFO, to > > > > CFI is getting much closer. Getting the kernel happy under Clang, LTO, > > and CFI is under active development. (It's functional for arm64 > > already, and pieces have been getting upstreamed.) > > > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :) All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream. -- Kees Cook _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 C41BEC10F11 for ; Mon, 22 Apr 2019 22:24:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 91B89205F4 for ; Mon, 22 Apr 2019 22:24:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XU2N9eXw"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Vl0fYQ0U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91B89205F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K6uQgUINBNVmhy3SK+kXlzFOcVeb63TwZVsUokwBf/A=; b=XU2N9eXwqY6cIO TxEg3G1XU2g8B3lXN81hDaXr18gSVBGby1VL/dlhjho8maZKpoupVS0AJLqmtrKQ5hHi3hF6Ty9iH ZTXXpZY3K6uDKG7cuXdzsd9qIZuxei5U8iqx5dyHd8VQ1usy6eQYc7aaF96jUfzs5/7vw8Fk4zbB7 qPVQiG6CXUaAHvRT/utn894LQbEEMbDzFIGw8oB0PFDTpQuMe3uUMk0C3TKdV3hRLM1J2Ydkd45D/ yeAyYvhFmJ2ML9g3OpjAJi5wmORtwfU71MsHT5NmFnkehsdqOGFaWCvEUYf/xkxVaMASZ5r+NF+f0 97OwEFAGCUKzzvWCqAWw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hIhLt-0006Wr-DS; Mon, 22 Apr 2019 22:23:53 +0000 Received: from mail-vk1-xa44.google.com ([2607:f8b0:4864:20::a44]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hIhLq-0006VS-1b for linux-arm-kernel@lists.infradead.org; Mon, 22 Apr 2019 22:23:51 +0000 Received: by mail-vk1-xa44.google.com with SMTP id q189so2747086vkq.11 for ; Mon, 22 Apr 2019 15:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=Vl0fYQ0UCHGtndl0jafErZw5vqbDAq4DrFX3SfBAIMhEhneL9rXawPTcud8fgV5g3D W/sHE49ARVD9KYD5FloU01n2RfA2pTgnKMthR4SE5EVifhT+Zv7f89iMoQqyLkH17UHR Ufjeoo3iZe8A1ywqY/dQX9OJ6hQY+RdFMicuSiIFmS2kjW0kxDgF0PQchZJoFDeQwLJ4 Bu9iNZw8/m1h5Vvq6bsIi0oFDRabTh4fUKE/VXZ1BpEeHCWZiVc862ytrlz+nAaTR+Cp kF/vZydc6r2yg2X0nSiZbBoPzLhOuIzzabOzb88ffPr/VLLo66HUZNIe7JxAbYTKUz7T O38g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=pbNLJohNhHpzeKEQLs9vXMCdbfDbWvGmvhGejkaLNTpIAMim73BDtyIgjcRTqSgq6E /W7Scc+bd/85aP/+BWVXbh4XNaLYyutD7Dhpp0oUt1iHzV/SD/T2VJVuM99lyrmamL4y ZdOFXU0f/dltgJs9CKczJcOp4kYAkayJs6Juvnf4PiN1hwikQ6PmQwXoySaUAC5h/SrW frNjbLbYjT6K63wnwTiM6f7xDkTmwTydAe5C9rdGAaKvMQO9XuTHN+EDpreAt4Ni4uzs LeLbs+S7QiN0qfDIMuN5bVjavjJSqufhstgTFDil046Q5pndiDWayzkxKGQAbnQ5E35h gAZw== X-Gm-Message-State: APjAAAVLQt//kIbD+rj/NNuqzHRYOTC8bPpaKS7873lwBNSVCitatEOD nln6E14dxS8BCOiPXh305tIswNeYJsfBRjGT+6AYFA== X-Google-Smtp-Source: APXvYqxiq50qJu8wanUuH+yOCTaJNMUpHEhGXVEwCujnFscJAmlLegU3s6VeZj+61I7iVGG+tUCCywSMlxsTtse/mUo= X-Received: by 2002:a1f:2e07:: with SMTP id u7mr11692664vku.44.1555971825052; Mon, 22 Apr 2019 15:23:45 -0700 (PDT) MIME-Version: 1.0 References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <56A175F6-E5DA-4BBD-B244-53B786F27B7F@gmail.com> <20190417172632.GA95485@gmail.com> <063753CC-5D83-4789-B594-019048DE22D9@gmail.com> <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com> From: Kees Cook Date: Mon, 22 Apr 2019 15:23:32 -0700 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Khalid Aziz X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190422_152350_106937_15145E79 X-CRM114-Status: GOOD ( 19.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dave Hansen , "open list:DOCUMENTATION" , Linux-MM , deepa.srinivasan@oracle.com, "H. Peter Anvin" , Nadav Amit , Thomas Gleixner , Tycho Andersen , X86 ML , LSM List , Ingo Molnar , Julian Stecklina , Arjan van de Ven , Peter Zijlstra , Konrad Rzeszutek Wilk , Jon Masters , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , chris hyser , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , David Woodhouse Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote: > > On 4/17/19 11:41 PM, Kees Cook wrote: > > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote: > >> I don't think this type of NX goof was ever the argument for XPFO. > >> The main argument I've heard is that a malicious user program writes a > >> ROP payload into user memory (regular anonymous user memory) and then > >> gets the kernel to erroneously set RSP (*not* RIP) to point there. > > > > Well, more than just ROP. Any of the various attack primitives. The NX > > stuff is about moving RIP: SMEP-bypassing. But there is still basic > > SMAP-bypassing for putting a malicious structure in userspace and > > having the kernel access it via the linear mapping, etc. > > > >> I find this argument fairly weak for a couple reasons. First, if > >> we're worried about this, let's do in-kernel CFI, not XPFO, to > > > > CFI is getting much closer. Getting the kernel happy under Clang, LTO, > > and CFI is under active development. (It's functional for arm64 > > already, and pieces have been getting upstreamed.) > > > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :) All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream. -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel