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_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 0C5B1C282DA for ; Wed, 17 Apr 2019 23:58:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C027820872 for ; Wed, 17 Apr 2019 23:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555545507; bh=BN1ZZXdzmYfqgnAQ5ZzEyFPan2Z6Qebjaw9X+M6aDOU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=VR9u///zYY6YX4KNgCswtmm82lWuaC9455+I8yiVaVIzKSD+R9jZ15s/Nxo0Urqe0 BdK5e3Zor3abSU9oaWdklI+g8ebF4dywhmjf+QTH3PNUJdP0kUS3KrrG2dYvAS9XLT O4PObggV26HKZ4tVRxIkjBFSRP6CHImNxGl+C7kU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387704AbfDQX60 (ORCPT ); Wed, 17 Apr 2019 19:58:26 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:39361 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729331AbfDQX60 (ORCPT ); Wed, 17 Apr 2019 19:58:26 -0400 Received: by mail-lf1-f67.google.com with SMTP id d12so145808lfk.6 for ; Wed, 17 Apr 2019 16:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=IBLCLtPuOlIJGx6ETpn93rimEqBz5Au/0GjooFZAo0KIJTxoTsJPz413yAtvfmWoXY BqvjzirjujDpTm8Z8RGtzbE47EZiPUSxIfegDrH1aTumTX5oM8C5bVyiexfx7ifgxxPB UMawmkwQ/X7ZweYBYxIOjMj+Jba1Zio7Xb4vw= 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=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=g8xnzWLK1myzwx1ODUqPJtcvGk7AeAEd91EMIyG+mftn5SgbPDSXARQPtRVp1Rp7wg AYFhgCJqTwK6bq73BSjxpJfeQvaU1AmImyTA+K2InsGzE0hpKSa7jyRSBC7nAiH9sfxC UzBOkWN/Vvy8BqXXQz2csy8MJYuE1UwmaX2Jwdir0BVktUd/WyKdD7s5AQJr1bOf+ORo RGJoa1uf8wmkij6E25mpDCH0i7qEm9mo1Fj3n8lbVYSqoItizH3GubGsWsiySaXl6Lry /D65vWn9T7YLJ0dAfVgPFF34KKnEVDIFZSx/9ry40lhDCfG/YxX0spbxSrhaaWo/h4Jl KyLA== X-Gm-Message-State: APjAAAWq9GXh6CGtN5RjvYseMyiuzGJQxdADY1a1hucmHAof85dNZtYO Ip0STa4hfVNn6PVMckv0Kdf+Kvg83Rk= X-Google-Smtp-Source: APXvYqxYkjEHST5iJ2cXORmE3uwq6FsaVc0ek4vTTjucxYq2QSKw2ROepXtUR85N3/ACvode1vzIgQ== X-Received: by 2002:ac2:5085:: with SMTP id f5mr20948510lfm.71.1555545503580; Wed, 17 Apr 2019 16:58:23 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id p14sm83538lfk.6.2019.04.17.16.58.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 16:58:23 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id v22so255453lje.9 for ; Wed, 17 Apr 2019 16:58:23 -0700 (PDT) X-Received: by 2002:a2e:5dd2:: with SMTP id v79mr48356924lje.22.1555545190479; Wed, 17 Apr 2019 16:53:10 -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: Linus Torvalds Date: Wed, 17 Apr 2019 16:52:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Thomas Gleixner Cc: Nadav Amit , Ingo Molnar , Khalid Aziz , juergh@gmail.com, Tycho Andersen , jsteckli@amazon.de, Kees Cook , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris.hyser@oracle.com, 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 , Andy Lutomirski , 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 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of course protected by SMEP. > > The attack utilizes the kernel linear mapping of the physical > memory. I.e. user space address 0x43210 has a kernel equivalent at > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid > kernel address and that is mapped X --> game over. SMEP does not help > there. Oh, agreed. But that would simply be a kernel bug. We should only map kernel pages executable when we have kernel code in them, and we should certainly not allow those pages to be mapped writably in user space. That kind of "executable in kernel, writable in user" would be a horrendous and major bug. So i think it's a non-issue. > From the top of my head I'd say this is a non issue as those kernel address > space mappings _should_ be NX, but we got bitten by _should_ in the past:) I do agree that bugs can happen, obviously, and we might have missed something. But in the context of XPFO, I would argue (*very* strongly) that the likelihood of the above kind of bug is absolutely *miniscule* compared to the likelihood that we'd have something wrong in the software implementation of XPFO. So if the argument is "we might have bugs in software", then I think that's an argument _against_ XPFO rather than for it. Linus 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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 BD839C282DA for ; Thu, 18 Apr 2019 00:01:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FB48214DA for ; Thu, 18 Apr 2019 00:01:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IBLCLtPu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FB48214DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E48A16B0005; Wed, 17 Apr 2019 20:01:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCA066B0006; Wed, 17 Apr 2019 20:01:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6D896B0007; Wed, 17 Apr 2019 20:01:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by kanga.kvack.org (Postfix) with ESMTP id 591B36B0005 for ; Wed, 17 Apr 2019 20:01:18 -0400 (EDT) Received: by mail-lj1-f199.google.com with SMTP id i127so97773lji.1 for ; Wed, 17 Apr 2019 17:01:18 -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=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=UJrhthMomBlEGcCUJhJvZfguz6ebS0hRN4mSPfbeKnfBzOrHYfDqeQHgGpnBymS779 kuRULkkOQuEZeN5AOzimZSwPj6rzALVzdl39twCwxyiuTFxRqtzstqY7yfymp3j5qq2O YbP4ayXoIvrVOwtPtKW91jM/3JWmUScND/m0cwwQWk0XuXlt92zAlEL6uX8anG2PmEi5 s55/9PGJgxOSJw/K3+G/x11Duela1tCrMYS2D24BjxUi48xs/cqP3UmLN09e4L1q2Yyj M4ufkR9nrdcQp34Z8sb23IEwJ8PHMs6V28aZ7M+erufVxzhF/CHX2Q8qZaUrdKokJWFa A+OQ== X-Gm-Message-State: APjAAAU/GqH4CST/TmJEzHVXEKookYwkrU+WUEDCZEJHTgXWphRVZzQR p0tLpFJ5EtR4VNOxJHkGLe6uKqbWfRQsEysySsyQU6YBb0a2TFW9wB/YkUpvkicHL5svHMUtTRf araybhAwKXVUZ695hcfPj9CO5/Un0O+69VZy060Lq5gQbP//QmOYrJbj/4td25XUKdw== X-Received: by 2002:a2e:74f:: with SMTP id i15mr43517898ljd.156.1555545677526; Wed, 17 Apr 2019 17:01:17 -0700 (PDT) X-Received: by 2002:a2e:74f:: with SMTP id i15mr43517869ljd.156.1555545676528; Wed, 17 Apr 2019 17:01:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555545676; cv=none; d=google.com; s=arc-20160816; b=SBW43cTplBQa3oTEm1Vh6Yww+K00shVpE+idbZhuGauCv6hVE1Nd9YlXEhfk5FBVeW xp3riVGZlpInn9qOweX/4Zm8WFc+MIzDl2gYcgkiO86kDMakbdSqzLs8mC1BbF55ae28 0jZorRGIogGrm7ouboKz3O2nQbq1vSyIa7x52nyzApOxmyqhynLOcLVZCMkGTZkMWF+V CW7ykwiq0a9OKEdnyLEgcuIOmNw4dMYyhi7frQrPbhlhcl1+/F6xBvysS2o1VJcGcL3f 4xOgL5lw/tM5QWWghGJC3wuBrF1xvW6jnX4ABXPaf82cojkEOb/ZX0f9jg7LNAF3hfm2 nwkg== 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=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=SsXaeec/yQ1gVDEyaHolQavFTiHK8NS7+b0syGp7s2tEDLHPmahMTQ6xTqqnE1yRw4 Xj1NoxfQCBRO+WcIVD3rut0704jmablrVzCkWKE/Su7tG16oeE5sUPwKN5z60RCMKlz6 m0HcHCAiCX74YWUOihkV5KGPD003ZkEUoCoQHtNJtCfUwUnlQlss+5rS+xYwoXMQG5lg Q9+uskn4YLX7jpvF7ZX7Xj5XciuX7X48VkNriUXUiwAdlmcGifNavmLjCgLC8doT51Bk lJ82OAWP5wfFIxluQZuzI24AjswqaJ4rbM9CYJPk2xB9igbXXCKRrsdeIsosfCs8oZOZ rB7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=IBLCLtPu; spf=pass (google.com: domain of torvalds@linuxfoundation.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id b26sor139214ljj.10.2019.04.17.17.01.16 for (Google Transport Security); Wed, 17 Apr 2019 17:01:16 -0700 (PDT) Received-SPF: pass (google.com: domain of torvalds@linuxfoundation.org designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=IBLCLtPu; spf=pass (google.com: domain of torvalds@linuxfoundation.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=IBLCLtPuOlIJGx6ETpn93rimEqBz5Au/0GjooFZAo0KIJTxoTsJPz413yAtvfmWoXY BqvjzirjujDpTm8Z8RGtzbE47EZiPUSxIfegDrH1aTumTX5oM8C5bVyiexfx7ifgxxPB UMawmkwQ/X7ZweYBYxIOjMj+Jba1Zio7Xb4vw= X-Google-Smtp-Source: APXvYqxckqXxWlE6Wltpoi1lHlzLq6zt+ZMYFt2/sYcWqh3sOaeuN0MfOnur0wwMmec/bEQ0FKwSIw== X-Received: by 2002:a2e:22c4:: with SMTP id i187mr48167621lji.94.1555545675741; Wed, 17 Apr 2019 17:01:15 -0700 (PDT) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com. [209.85.208.180]) by smtp.gmail.com with ESMTPSA id t23sm65957ljc.13.2019.04.17.17.01.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 17:01:15 -0700 (PDT) Received: by mail-lj1-f180.google.com with SMTP id q66so269512ljq.7 for ; Wed, 17 Apr 2019 17:01:15 -0700 (PDT) X-Received: by 2002:a2e:5dd2:: with SMTP id v79mr48356924lje.22.1555545190479; Wed, 17 Apr 2019 16:53:10 -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: Linus Torvalds Date: Wed, 17 Apr 2019 16:52:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Thomas Gleixner Cc: Nadav Amit , Ingo Molnar , Khalid Aziz , juergh@gmail.com, Tycho Andersen , jsteckli@amazon.de, Kees Cook , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris.hyser@oracle.com, 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 , Andy Lutomirski , 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 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of course protected by SMEP. > > The attack utilizes the kernel linear mapping of the physical > memory. I.e. user space address 0x43210 has a kernel equivalent at > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid > kernel address and that is mapped X --> game over. SMEP does not help > there. Oh, agreed. But that would simply be a kernel bug. We should only map kernel pages executable when we have kernel code in them, and we should certainly not allow those pages to be mapped writably in user space. That kind of "executable in kernel, writable in user" would be a horrendous and major bug. So i think it's a non-issue. > From the top of my head I'd say this is a non issue as those kernel address > space mappings _should_ be NX, but we got bitten by _should_ in the past:) I do agree that bugs can happen, obviously, and we might have missed something. But in the context of XPFO, I would argue (*very* strongly) that the likelihood of the above kind of bug is absolutely *miniscule* compared to the likelihood that we'd have something wrong in the software implementation of XPFO. So if the argument is "we might have bugs in software", then I think that's an argument _against_ XPFO rather than for it. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Date: Wed, 17 Apr 2019 16:52:54 -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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: Nadav Amit , Ingo Molnar , Khalid Aziz , juergh@gmail.com, Tycho Andersen , jsteckli@amazon.de, Kees Cook , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris.hyser@oracle.com, Tyler Hicks , David Woodhouse , Andrew Cooper , Jon Masters , Boris Ostrovsky , iommu , X86 ML , "linux-alpha@vger.kernel.org" , "open list:DOCUMENTATION" , Linux List-Id: iommu@lists.linux-foundation.org On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of course protected by SMEP. > > The attack utilizes the kernel linear mapping of the physical > memory. I.e. user space address 0x43210 has a kernel equivalent at > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid > kernel address and that is mapped X --> game over. SMEP does not help > there. Oh, agreed. But that would simply be a kernel bug. We should only map kernel pages executable when we have kernel code in them, and we should certainly not allow those pages to be mapped writably in user space. That kind of "executable in kernel, writable in user" would be a horrendous and major bug. So i think it's a non-issue. > From the top of my head I'd say this is a non issue as those kernel address > space mappings _should_ be NX, but we got bitten by _should_ in the past:) I do agree that bugs can happen, obviously, and we might have missed something. But in the context of XPFO, I would argue (*very* strongly) that the likelihood of the above kind of bug is absolutely *miniscule* compared to the likelihood that we'd have something wrong in the software implementation of XPFO. So if the argument is "we might have bugs in software", then I think that's an argument _against_ XPFO rather than for it. Linus 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 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 C626AC282DA for ; Thu, 18 Apr 2019 00:00:46 +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 908EB214DA for ; Thu, 18 Apr 2019 00:00:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IBLCLtPu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 908EB214DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=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 5A402E9E; Thu, 18 Apr 2019 00:00:46 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EA922E9D for ; Thu, 18 Apr 2019 00:00:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEEBC108 for ; Thu, 18 Apr 2019 00:00:43 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id f23so299252ljc.0 for ; Wed, 17 Apr 2019 17:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=IBLCLtPuOlIJGx6ETpn93rimEqBz5Au/0GjooFZAo0KIJTxoTsJPz413yAtvfmWoXY BqvjzirjujDpTm8Z8RGtzbE47EZiPUSxIfegDrH1aTumTX5oM8C5bVyiexfx7ifgxxPB UMawmkwQ/X7ZweYBYxIOjMj+Jba1Zio7Xb4vw= 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=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=Zv7LFmgg9oTkWq1n12LMP6JNxmWpEGzLz+niGeB0zYaPxbeT7p4FTqPl1JHYEK68OB r4ZUnHgtyL1bC7vQ4XdPv/lzrU1SEYOZEjaJYG1W9ej7P/QNewiLRb4Ppyyn1NNMJZOO eld4f3OBvsB4+yeX42wYD+UyH8LQoI6+zle43fq8XJc/cCsVVQXbIIIb057CiS07XRDZ mPudVgPRmPG6wxu4OdL82nEf93ff97trOhtP4736y1odo8iN7AfxlUwj6oPbsHh3C4p2 6Di8CnU99xFuAvyMTypmkoOtxEQxhSjMc7cIzNndxCPoJqgOB0t7852mjUqEc8/n2MGg otkg== X-Gm-Message-State: APjAAAXoVhKBA4eu20AaHzAHSW4068kX8wex0z5GpTnTsq0eXrVyqoPL +TtNbM2dbWs66zTkm8M8kNkc2r1/yWK9AQ== X-Google-Smtp-Source: APXvYqzcvKPAN/utmx4aTD/zy2e37ApbRHExg7FMIcbqueYW3HLsh0n+tqQOObRwGS2s3msmfI1Cng== X-Received: by 2002:a2e:87d2:: with SMTP id v18mr1358232ljj.4.1555545641677; Wed, 17 Apr 2019 17:00:41 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id z8sm62733ljc.50.2019.04.17.17.00.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 17:00:41 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id q66so268509ljq.7 for ; Wed, 17 Apr 2019 17:00:41 -0700 (PDT) X-Received: by 2002:a2e:5dd2:: with SMTP id v79mr48356924lje.22.1555545190479; Wed, 17 Apr 2019 16:53:10 -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: Linus Torvalds Date: Wed, 17 Apr 2019 16:52:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Thomas Gleixner Cc: Dave Hansen , "open list:DOCUMENTATION" , Linux-MM , Khalid Aziz , deepa.srinivasan@oracle.com, "H. Peter Anvin" , Ingo Molnar , Tycho Andersen , X86 ML , LSM List , jsteckli@amazon.de, Arjan van de Ven , Peter Zijlstra , Konrad Rzeszutek Wilk , Jon Masters , Greg Kroah-Hartman , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , chris.hyser@oracle.com, "linux-alpha@vger.kernel.org" , Khalid Aziz , juergh@gmail.com, Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Kees Cook , Andrew Morton , 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: , 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: <20190417235254.tsBsWyiqR6CZrESa0BUzwnIIXDzheAy9jhAsfp6OK_c@z> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of course protected by SMEP. > > The attack utilizes the kernel linear mapping of the physical > memory. I.e. user space address 0x43210 has a kernel equivalent at > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid > kernel address and that is mapped X --> game over. SMEP does not help > there. Oh, agreed. But that would simply be a kernel bug. We should only map kernel pages executable when we have kernel code in them, and we should certainly not allow those pages to be mapped writably in user space. That kind of "executable in kernel, writable in user" would be a horrendous and major bug. So i think it's a non-issue. > From the top of my head I'd say this is a non issue as those kernel address > space mappings _should_ be NX, but we got bitten by _should_ in the past:) I do agree that bugs can happen, obviously, and we might have missed something. But in the context of XPFO, I would argue (*very* strongly) that the likelihood of the above kind of bug is absolutely *miniscule* compared to the likelihood that we'd have something wrong in the software implementation of XPFO. So if the argument is "we might have bugs in software", then I think that's an argument _against_ XPFO rather than for it. Linus _______________________________________________ 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_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 167DEC282DA for ; Wed, 17 Apr 2019 23:59:59 +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 D4E9920872 for ; Wed, 17 Apr 2019 23:59:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="am6E/KlZ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IBLCLtPu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4E9920872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org 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=q223vaBiFfPlQdEr6nlyf8zKq8YVfu9gQoed/jrIg1Q=; b=am6E/KlZp2Rfb9 4l9Fgyujz7dqOCsssh7xScnGR+ROpm16PA9W6J0wvGtvlXEdhm6v8pBd2F1eKoYODZ7AE1PRvDFNp VXJt18111fkyOWxwx5rKh1KXSwRkIGD3kwKBVjRARuktisSiXAmjH+h6NBTekmxZVqe+fWYl10q0k pCFfJ9VCJx58rOjBXUbaOqae4EcMeDNBafNCXtOuMHMz6mByc22Ef6oENGK01yINfoddvlQ49TBKb WUfRF6yADrJu988TZ0bZTfHCjzf0hEzm49vXHeTZGl5JCYk5TMhJ7WGIJ52iee+SDeu5ybiCKqOdQ KG8uy6J2Y9NClV+BCuYw==; 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 1hGuT3-000300-Gw; Wed, 17 Apr 2019 23:59:53 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGuT0-0002zh-2K for linux-arm-kernel@lists.infradead.org; Wed, 17 Apr 2019 23:59:51 +0000 Received: by mail-lf1-x142.google.com with SMTP id j20so157632lfh.2 for ; Wed, 17 Apr 2019 16:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=IBLCLtPuOlIJGx6ETpn93rimEqBz5Au/0GjooFZAo0KIJTxoTsJPz413yAtvfmWoXY BqvjzirjujDpTm8Z8RGtzbE47EZiPUSxIfegDrH1aTumTX5oM8C5bVyiexfx7ifgxxPB UMawmkwQ/X7ZweYBYxIOjMj+Jba1Zio7Xb4vw= 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=+kn5mtINPt4na060bar/tC0RHNfqAb7J/PmuZQ0Dyi8=; b=AUUOKwGMNZQKCA8qwfhX9bDv2SEDMgdK6eRQWZ/4P8Eh3vGX7ec/AvYqRRrmiFY7Hw 5OfEyhLzTEeV7N8CMx1n9isgiy6H+VtNM44mjw4yiQQ4C4LzS2pSTU8xNLRRfLTJmPe+ l4RCs5+Xj1hGWQqEWfy7AHluXeAtBHaN3NP4mZ8bmd1VECRcztYRo+lVhnhjXnRKeH8f ZwwHLZhvzxMDO1gzajMFxImuWKzGs1czu/zyewauvQjr+vVcZdu12/zi/Pb1UoWGobZR lrdyiF+/YtOt7qyszDgbCDWkijaZDNoyyIDDDGKlM+PKJG9vrUuHstftNf8YlvfWEu+a VZKw== X-Gm-Message-State: APjAAAWlO5zP+AB/eDY7MM48zzQsOfBBVUFvGqmYLPaVDg0MA10n+BvW T7y8CvUas8WLVbkZYrhi3vgfj/ShuwI= X-Google-Smtp-Source: APXvYqxOLeBmp32vyaMg8PoC72jLzQM+DvTS7hqYtbn7oR092i4KIVSrKZ1gRGmsNx7HY01Ae9coNw== X-Received: by 2002:a19:ca02:: with SMTP id a2mr20102403lfg.88.1555545587671; Wed, 17 Apr 2019 16:59:47 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id r19sm58943lja.83.2019.04.17.16.59.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 16:59:47 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id f23so297669ljc.0 for ; Wed, 17 Apr 2019 16:59:47 -0700 (PDT) X-Received: by 2002:a2e:5dd2:: with SMTP id v79mr48356924lje.22.1555545190479; Wed, 17 Apr 2019 16:53:10 -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: Linus Torvalds Date: Wed, 17 Apr 2019 16:52:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Thomas Gleixner X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_165950_121057_94AB378A X-CRM114-Status: GOOD ( 14.47 ) 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 , Ingo Molnar , Tycho Andersen , X86 ML , LSM List , jsteckli@amazon.de, Arjan van de Ven , Peter Zijlstra , Konrad Rzeszutek Wilk , Jon Masters , Greg Kroah-Hartman , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , chris.hyser@oracle.com, "linux-alpha@vger.kernel.org" , Khalid Aziz , juergh@gmail.com, Andrew Cooper , Linux List Kernel Mailing , Tyler Hicks , iommu , Juerg Haefliger , Kees Cook , Andrew Morton , 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 4:42 PM Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Linus Torvalds wrote: > > > With SMEP, user space pages are always NX. > > We talk past each other. The user space page in the ring3 valid virtual > address space (non negative) is of course protected by SMEP. > > The attack utilizes the kernel linear mapping of the physical > memory. I.e. user space address 0x43210 has a kernel equivalent at > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid > kernel address and that is mapped X --> game over. SMEP does not help > there. Oh, agreed. But that would simply be a kernel bug. We should only map kernel pages executable when we have kernel code in them, and we should certainly not allow those pages to be mapped writably in user space. That kind of "executable in kernel, writable in user" would be a horrendous and major bug. So i think it's a non-issue. > From the top of my head I'd say this is a non issue as those kernel address > space mappings _should_ be NX, but we got bitten by _should_ in the past:) I do agree that bugs can happen, obviously, and we might have missed something. But in the context of XPFO, I would argue (*very* strongly) that the likelihood of the above kind of bug is absolutely *miniscule* compared to the likelihood that we'd have something wrong in the software implementation of XPFO. So if the argument is "we might have bugs in software", then I think that's an argument _against_ XPFO rather than for it. Linus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel