Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3116059yba; Mon, 22 Apr 2019 20:25:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqywQBSjizXZmM9wdedmGDqtkkwlbZuWaTPsehgbuADd0DGSCy2Mf0nB2rWx1hW30iz8heJE X-Received: by 2002:a17:902:6f17:: with SMTP id w23mr3986610plk.29.1555989908644; Mon, 22 Apr 2019 20:25:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555989908; cv=none; d=google.com; s=arc-20160816; b=Q1ghNnRCWL03QcifgoUi2r2mHRqTyA3pkzqzzDS2zZle7EpYu88ub6rlbuYdtXNWlc bDWxxIClaxol8GtUCesTVS+sNwABpKKtT1b3tbyW7sf2UJG3UIg14yuamBYEfRuCzfmV V+AbPM7ITj7JTxnh7I4Oiwr5yjKW8BZc9+ZPDepSENLuH/7I+8nQqj+XcoBxbfwdgtDB 5xt97HG023LF+SoyctTXBkUNd4ADxT3cl3uc3HoRQNWHEWLRraopQ32VYIJS7R2oB/w+ BEndG2ChPPdCSy3xJt+MoNoEWQTGON6AFMYfgeFYCscQwapuaKjECdqFuou1qzHcUFVc F4yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Apsh13b43ex5kM603MFVFBzVRJeAAR6IMS53yCHVuRM=; b=bnKvAHEXj+FivBTEm6S2yh8HNUcgTkjtYeu/6gzMgDNSVycUeOlv64MjTmjlcvXUcP +dvi/n/wr9ktkFQQEGyGT/WjOQL22H4LsVRoEQJ2zUFx2WaDBiBh3H124Kru/tAm5vuw UH8RgfCMGkDVbjNeWQmGjX6iyHAn6D8XkRGdOsONA2J8u+ngyCJawpDE0tsudebeN2Mp CZepXTxiprJQMGQ0IEIRV14tqMcDUXXV0/TiPfXdwK1tj++Rm+b+wxoZxtUqfKfLA9Ig Oj+KNneGYmaZXxB3DuFAw8KgdDhY7PDTv4oOcdVFzcNEC0X8ayI3QdnFRWXltuJpXwLW 5QQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Vl0fYQ0U; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j4si14835701pfr.272.2019.04.22.20.24.44; Mon, 22 Apr 2019 20:25:08 -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=@google.com header.s=20161025 header.b=Vl0fYQ0U; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727940AbfDVWXr (ORCPT + 99 others); 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-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