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 3E953C10F0E for ; Thu, 18 Apr 2019 05:42:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 079822183F for ; Thu, 18 Apr 2019 05:42:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="R/AYdV4I" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732424AbfDRFl7 (ORCPT ); Thu, 18 Apr 2019 01:41:59 -0400 Received: from mail-vk1-f195.google.com ([209.85.221.195]:38669 "EHLO mail-vk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbfDRFl7 (ORCPT ); Thu, 18 Apr 2019 01:41:59 -0400 Received: by mail-vk1-f195.google.com with SMTP id h71so219450vkf.5 for ; Wed, 17 Apr 2019 22:41:58 -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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=R/AYdV4IFItQnfjUNNubyf9+5USGcILzz8B1DmWPKSECRCluWxSP8rnztSiAw/nHbx OgWc7upQI8/4NLGzsj8XCYD8CtK21EXPUD3kqVz8L9yqhXJs06gDEQL5f14t98XkKrDi zZLGfesRzIi7SEtmDIBJc/zWHSSeITVGpq4qWo6pCUtYoX+1nKYsEkGc/aMtjhfeYPaR zpe5obPY5UDXKnX5Ux3km1WyEqJmPrsvxZPBHysfpd+ZMjsl8a01eFzYpNC5mgWQOQvs wfgj8VJjyeSiWxP7AB+2Th18IJzOpvgz45GRbENtjjUmOZDRpabHmRe+wBMg/KPgX8r9 SNsQ== 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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=WDUxQaUrSkMijcaPwp2sJVrUWYHsInToEM2/oREHH7CfxzH2Z2j16Hx0XY2lx8SHiT DnwWdSnW7eNqB0ByvdSWa8xwZ9YYcI2LH5NCgC61nCXDqPHmvqZvB7kDKpSQ7FiJsvKv jnbwLUGiIGiI+HMnIaRuC+vnKUGwAErhFiZ/wVupypyhQzL+lyYlKLAv7Xy0N2zeodEN b8XtBovqlchN39HrV4u5PG5vdBCPKxbP9s18QN55TD0Qcr7iwgOmfMXO3rjJtRRuFaO/ bte1COYmDdZ/sNIW3tMq8pDrbhxutcnS1+6asI40vO0BPWquWY7N0o/XX2PsIPw+IqV5 KfbA== X-Gm-Message-State: APjAAAUcTflXi2AFT5JW7yd0LIKGDxWl/2YsY4nVdNGqPzZyVhgp9U8A p4kJ8qAl32Lz2WjAF/OH3YBODZE6lfRctGEtyxH1PA== X-Google-Smtp-Source: APXvYqzZLwtZBmPJJ/5v5RygK+/cFMwA6/cdqWVv/GY3jUCoHNshsVXhYcdmHi4zwosCo3mHVhlDcSu086Z/Mts0mIg= X-Received: by 2002:a1f:a4d:: with SMTP id 74mr51091145vkk.13.1555566117779; Wed, 17 Apr 2019 22:41:57 -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> In-Reply-To: From: Kees Cook Date: Thu, 18 Apr 2019 00:41:45 -0500 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Andy Lutomirski Cc: Linus Torvalds , Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , Julian Stecklina , Kees Cook , 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 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.) > mitigate it. Second, I don't see why the exact same attack can't be > done using, say, page cache, and unless I'm missing something, XPFO > doesn't protect page cache. Or network buffers, or pipe buffers, etc. My understanding is that it's much easier to feel out the linear mapping address than for the others. But yes, all of those same attack primitives are possible in other memory areas (though most are NX), and plenty of exploits have done such things. -- 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 7A38EC10F0B for ; Thu, 18 Apr 2019 05:42:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2154A2183F for ; Thu, 18 Apr 2019 05:42:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="R/AYdV4I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2154A2183F 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 B47A16B0005; Thu, 18 Apr 2019 01:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACFBB6B0006; Thu, 18 Apr 2019 01:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 997C06B0007; Thu, 18 Apr 2019 01:41:59 -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 6E4006B0005 for ; Thu, 18 Apr 2019 01:41:59 -0400 (EDT) Received: by mail-vk1-f198.google.com with SMTP id g12so429982vkf.20 for ; Wed, 17 Apr 2019 22:41:59 -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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=e1DCfJGSLVSc9DWsW2d1i9bhYC8V8OX1dvracLVViAWJCcKjJamUJz/UKKOGmkakTW lAtaI61WG0ey5sYLvgbjbNuIkbJa24zR88LAWnPju0l9XsliQEPET4eAaJQWvUDhvrI6 Y/kAZiwvL3yRqkSMjKVHZX7SJsX2qwKCH9VyYy2a5UdBcJAZ/9Pxj2ESX9cbyG1E1q79 y4zTY3KNZCUXICPqU2uMzWgygFKrpeotWi0UH/Hv/fEpo9V8mxM4zaxvGt5txD/kiE3G K7fuonaxnGc3iQdIBnM1tO9FurohvFAO+boO3KRGbYOlVqbWsra18P30cIGhqaMacbHK w/sg== X-Gm-Message-State: APjAAAXu72UtLnWVR4QwfDftW781MREjsFjS4DnYV/l1kyTUKNq3LW9a 997jxGlQZvs+Wz2cdHHkVNw9n7YXW0RYyi7Ivf9jHQylcnDi3j2u2ukTfWV0r1qpfilntwMFh14 OPNH6sQhgLY8F3rOevxPjcQqCWz2D0QC9lOyPQ1fR4V0Mmd7nUMSe1tZK1Q6y/D5rQg== X-Received: by 2002:ab0:274a:: with SMTP id c10mr24804714uap.107.1555566119212; Wed, 17 Apr 2019 22:41:59 -0700 (PDT) X-Received: by 2002:ab0:274a:: with SMTP id c10mr24804696uap.107.1555566118440; Wed, 17 Apr 2019 22:41:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555566118; cv=none; d=google.com; s=arc-20160816; b=Kl058gLnsi2Azv53dPDrVnMplzCz3IbQM3gjAUrWkve4U6zpmeq+nrwTvrlke3kgG4 rzMOka0Q2J18PNXN0fAb0c6BkQSPIi4vydM4qZi2HMI2hIPCvncu47H8Tqw1OL2eWoFE 006PfVO4MYnKVugSX21HCLCY4LGSObxp6V8IkGE/q2BxZjwkdGK5wkG+ZzwL5FqHee3b 3RER54AgBHPdg7VmMpK+WRJbh69pjA/aaO0QYOwiyEPfJSR5gnp8oKjpMBI4JCHMXUBg yLX6Aj4PiSAEq+8vfqYKa8mbPu5QWVZjf4C4YkvZoewNbozqI48wz8T7zZcLSwI5omox ZVxQ== 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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=R0QRpIiFedI+QUN4c14Sc8WUCOOM5+Nw+b1iSxjxWJP5DN8SI326xnKsLHlZZIBb+U f0d7R+wr6MaivYMZ0hakUVV3+3vFu5X1+wk+WKmzm8GoMk7Gx0Ycrq9HBu7M0/tOqZHe QqlLbKsKq/H/w7KaaReOSpvJEAW1i6KP0qMSwJKWONVM5skR5ecCv0I9ohcnAyrSdV1R +YIM2XtDu68Ih5VC/nQFsL9Kk666HzNOENLUuS/oW7KCUX3Q7wNFQCIkE6lLRS5ZlaqH txxw/t12k4nsBznQ2My5qED8X7UKDTHgqZ2x3aQref/+/Xr/oUEKfBM8qn4Kq7dtnvm9 W2Ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="R/AYdV4I"; 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 s85sor314503vkb.4.2019.04.17.22.41.58 for (Google Transport Security); Wed, 17 Apr 2019 22:41:58 -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="R/AYdV4I"; 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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=R/AYdV4IFItQnfjUNNubyf9+5USGcILzz8B1DmWPKSECRCluWxSP8rnztSiAw/nHbx OgWc7upQI8/4NLGzsj8XCYD8CtK21EXPUD3kqVz8L9yqhXJs06gDEQL5f14t98XkKrDi zZLGfesRzIi7SEtmDIBJc/zWHSSeITVGpq4qWo6pCUtYoX+1nKYsEkGc/aMtjhfeYPaR zpe5obPY5UDXKnX5Ux3km1WyEqJmPrsvxZPBHysfpd+ZMjsl8a01eFzYpNC5mgWQOQvs wfgj8VJjyeSiWxP7AB+2Th18IJzOpvgz45GRbENtjjUmOZDRpabHmRe+wBMg/KPgX8r9 SNsQ== X-Google-Smtp-Source: APXvYqzZLwtZBmPJJ/5v5RygK+/cFMwA6/cdqWVv/GY3jUCoHNshsVXhYcdmHi4zwosCo3mHVhlDcSu086Z/Mts0mIg= X-Received: by 2002:a1f:a4d:: with SMTP id 74mr51091145vkk.13.1555566117779; Wed, 17 Apr 2019 22:41:57 -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> In-Reply-To: From: Kees Cook Date: Thu, 18 Apr 2019 00:41:45 -0500 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Andy Lutomirski Cc: Linus Torvalds , Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , Julian Stecklina , Kees Cook , 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 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.) > mitigate it. Second, I don't see why the exact same attack can't be > done using, say, page cache, and unless I'm missing something, XPFO > doesn't protect page cache. Or network buffers, or pipe buffers, etc. My understanding is that it's much easier to feel out the linear mapping address than for the others. But yes, all of those same attack primitives are possible in other memory areas (though most are NX), and plenty of exploits have done such things. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Date: Thu, 18 Apr 2019 00:41:45 -0500 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Linus Torvalds , Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , Julian Stecklina , Kees Cook , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris hyser , Tyler Hicks , David Woodhouse , Andrew Cooper , Jon Masters , Boris Ostrovsky , iommu , X86 ML List-Id: iommu@lists.linux-foundation.org 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.) > mitigate it. Second, I don't see why the exact same attack can't be > done using, say, page cache, and unless I'm missing something, XPFO > doesn't protect page cache. Or network buffers, or pipe buffers, etc. My understanding is that it's much easier to feel out the linear mapping address than for the others. But yes, all of those same attack primitives are possible in other memory areas (though most are NX), and plenty of exploits have done such things. -- 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=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 3801FC10F0E for ; Thu, 18 Apr 2019 09:18:56 +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 E55C92183E for ; Thu, 18 Apr 2019 09:18:55 +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="R/AYdV4I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E55C92183E 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 9FF861515; Thu, 18 Apr 2019 09:18:55 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 92180D36 for ; Thu, 18 Apr 2019 05:41:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A6D46C5 for ; Thu, 18 Apr 2019 05:41:59 +0000 (UTC) Received: by mail-vk1-f196.google.com with SMTP id x194so224987vke.0 for ; Wed, 17 Apr 2019 22:41:58 -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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=R/AYdV4IFItQnfjUNNubyf9+5USGcILzz8B1DmWPKSECRCluWxSP8rnztSiAw/nHbx OgWc7upQI8/4NLGzsj8XCYD8CtK21EXPUD3kqVz8L9yqhXJs06gDEQL5f14t98XkKrDi zZLGfesRzIi7SEtmDIBJc/zWHSSeITVGpq4qWo6pCUtYoX+1nKYsEkGc/aMtjhfeYPaR zpe5obPY5UDXKnX5Ux3km1WyEqJmPrsvxZPBHysfpd+ZMjsl8a01eFzYpNC5mgWQOQvs wfgj8VJjyeSiWxP7AB+2Th18IJzOpvgz45GRbENtjjUmOZDRpabHmRe+wBMg/KPgX8r9 SNsQ== 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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=fh0qjDgvwtFZFXfaXncNzHXzs3LN4aFOjbbdzU0Nd87Ygxt/ZK3l1fP9WQ9VMMAKRq l/fx0z895Hf2qNvrASBo1XPB0B6IAWuNplzEJgnisCMfg9qf9Zx3tci3C9DsvGyvyx7y +HVZLjzVWFM2GotKd+H1D6PNai5/ZY/zgwmgFKkt+0UnsdbBcamnC4CThfwMJuZqWMoS wXfsRDLYy1Fmx4nSzaojgqgiI8yp5/zxyvVQltBonXDLOcF5u13O/urGXUJFlJZmHyIK Jx6d5y6cdlHIlPoMCOAdmblSmbxFq7tvErpXv3ezBzR2wzO1ppJvzUq9FRsKyTrch8kK hZEw== X-Gm-Message-State: APjAAAW/am0c44lXPhfB7eAobwhFVXCFxONhYTFwkjMyDIo23kI1XFLG cKFrv2U/bnWrjVtr+In8tD9ORqbWIQ+9QumLAms3zQ== X-Google-Smtp-Source: APXvYqzZLwtZBmPJJ/5v5RygK+/cFMwA6/cdqWVv/GY3jUCoHNshsVXhYcdmHi4zwosCo3mHVhlDcSu086Z/Mts0mIg= X-Received: by 2002:a1f:a4d:: with SMTP id 74mr51091145vkk.13.1555566117779; Wed, 17 Apr 2019 22:41:57 -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> In-Reply-To: Date: Thu, 18 Apr 2019 00:41:45 -0500 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Andy Lutomirski X-Mailman-Approved-At: Thu, 18 Apr 2019 09:18:54 +0000 Cc: Dave Hansen , "open list:DOCUMENTATION" , Linux-MM , Khalid Aziz , 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 , Greg Kroah-Hartman , Borislav Petkov , Boris Ostrovsky , chris hyser , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Kees Cook , 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: <20190418054145.J8UIByxBS1omoGmdgRwDPQVD6n0vQlLftSB6I5sucUs@z> 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.) > mitigate it. Second, I don't see why the exact same attack can't be > done using, say, page cache, and unless I'm missing something, XPFO > doesn't protect page cache. Or network buffers, or pipe buffers, etc. My understanding is that it's much easier to feel out the linear mapping address than for the others. But yes, all of those same attack primitives are possible in other memory areas (though most are NX), and plenty of exploits have done such things. -- 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.1 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,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 47FEAC10F0B for ; Thu, 18 Apr 2019 05:42:11 +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 155AB2083D for ; Thu, 18 Apr 2019 05:42:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PuPzAyvz"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="R/AYdV4I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 155AB2083D 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=F5IOc82MLu7YEkIZMiZwj4IyjyBXPVWwpbCY2hhfOCI=; b=PuPzAyvzgNE5xi K5OblEsFNJa+faoJGqbPKOpkJ4nHz1EeBMCGqyGKKJepsYmSzK6k1dbUhrXc2b8w9LBhmqwSQ4AW3 9bDycAi592LbVYwWaqy3g2mw/7nC5YrL3nNA1q75T9ebNIW2EUiLVFB6gsTD4B4O5j8zOb8vpXGi5 5QV41kozA/gmADIWXyJZ7jJuNl/mya228ZyCWTc+CRnOGCSRQSImBIzPh4F/L9iYxJoBvccpmpViX +HMVgx7IZ9pCSSx+FiPn21+8l882mh9heDYTVy8YOvLrubyjQBPdbfsD8x9hslZEM5PgWnVFQ2Imy dU8gu2eltwmnDGa93X6w==; 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 1hGzoC-0006eB-0R; Thu, 18 Apr 2019 05:42:04 +0000 Received: from mail-vk1-xa43.google.com ([2607:f8b0:4864:20::a43]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGzo9-0006dh-Pq for linux-arm-kernel@lists.infradead.org; Thu, 18 Apr 2019 05:42:03 +0000 Received: by mail-vk1-xa43.google.com with SMTP id x2so207711vkx.13 for ; Wed, 17 Apr 2019 22:41:58 -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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=R/AYdV4IFItQnfjUNNubyf9+5USGcILzz8B1DmWPKSECRCluWxSP8rnztSiAw/nHbx OgWc7upQI8/4NLGzsj8XCYD8CtK21EXPUD3kqVz8L9yqhXJs06gDEQL5f14t98XkKrDi zZLGfesRzIi7SEtmDIBJc/zWHSSeITVGpq4qWo6pCUtYoX+1nKYsEkGc/aMtjhfeYPaR zpe5obPY5UDXKnX5Ux3km1WyEqJmPrsvxZPBHysfpd+ZMjsl8a01eFzYpNC5mgWQOQvs wfgj8VJjyeSiWxP7AB+2Th18IJzOpvgz45GRbENtjjUmOZDRpabHmRe+wBMg/KPgX8r9 SNsQ== 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=zQ9PhXUre7lv39dhKUe3RnNugaLVkc5Fpp+aduMWHKc=; b=qKR51OICG3VzmX6PPHLrKqQ35600+GXy0MzTefmX3zHx6jgVO1yoOvdL0CgXT5m6qs BkPpAfrNelSWiuk+BFTcnSdC7zQ2IT5livpYolm0hV/Sxqz1lz5dZqJU59qdl1nUetvw 5GBPD6ROugNUXUL++e4tEgC0AZ0tHsKv/TDwuBPFjXX2TmSqUtiPwqiPbcFYu5NHm7UQ HmHvIeOAiKPTvE39uNe7woGfA9cRdaYfBgz/UTgsFuhuT98uBAqs9YeJpqQuhJr0XTRk waxdGaIbNrwLnl1iX/64HWuibFTyrXCFQUmovM58m/FtocSLR6ZQ5Vmf6jMxVhKlENyD VCVg== X-Gm-Message-State: APjAAAV98+RYfA0/M1Wtzer8GaPEaS4WdHGgW/qfM1uZtwwfZ8cV5z2e Z80EFaOgPlSvTeb4Ail9DWMdFNKEywyIUgELk6MVrg== X-Google-Smtp-Source: APXvYqzZLwtZBmPJJ/5v5RygK+/cFMwA6/cdqWVv/GY3jUCoHNshsVXhYcdmHi4zwosCo3mHVhlDcSu086Z/Mts0mIg= X-Received: by 2002:a1f:a4d:: with SMTP id 74mr51091145vkk.13.1555566117779; Wed, 17 Apr 2019 22:41:57 -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> In-Reply-To: From: Kees Cook Date: Thu, 18 Apr 2019 00:41:45 -0500 Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Andy Lutomirski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_224201_867273_7A4B2E39 X-CRM114-Status: GOOD ( 13.68 ) 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 , Khalid Aziz , 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 , Greg Kroah-Hartman , Borislav Petkov , Boris Ostrovsky , chris hyser , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Kees Cook , 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 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.) > mitigate it. Second, I don't see why the exact same attack can't be > done using, say, page cache, and unless I'm missing something, XPFO > doesn't protect page cache. Or network buffers, or pipe buffers, etc. My understanding is that it's much easier to feel out the linear mapping address than for the others. But yes, all of those same attack primitives are possible in other memory areas (though most are NX), and plenty of exploits have done such things. -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel