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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 AFF5CC282DD for ; Thu, 18 Apr 2019 04:41:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 724D521872 for ; Thu, 18 Apr 2019 04:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555562511; bh=ZzJFjyGToYfbKAC7a2m7yS86J4A8OLDkslCG6xa8cQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=fRgzOan6ephZT36HS/fq+FoYbKXtu45xdpMto2F7TNuZC1eHSvB2A+o6Z5L4CYjzM 6Sw1R5m+Xs8v7Oekww2YEoD9k4GGDQesEdEeeMEBlgKOo1vk6bi0ucLPf4SGYCbHh+ QVRJP/U62xbHHze+2LvV7PILSNZDnM3Sgl11rgNE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726863AbfDRElu (ORCPT ); Thu, 18 Apr 2019 00:41:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:54936 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725987AbfDRElt (ORCPT ); Thu, 18 Apr 2019 00:41:49 -0400 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1752D21908 for ; Thu, 18 Apr 2019 04:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555562508; bh=ZzJFjyGToYfbKAC7a2m7yS86J4A8OLDkslCG6xa8cQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QVWUihYIOED3b6sf++tgY3iRdj8kiMHZVbckG4nNfCAClSFzLnTcPH+IgFSB9PrKC Z2tMpLhiQqQpdAO8Vqghyo+PaFXtDr9TPVxG3ICymGFgejmh9f9/1/nnjg3BTRsxMd IElW3sPpwA7MwJfgB7BILSJAa6MZxHiR0qJmXz6w= Received: by mail-wr1-f44.google.com with SMTP id w10so1161926wrm.4 for ; Wed, 17 Apr 2019 21:41:48 -0700 (PDT) X-Gm-Message-State: APjAAAXB2qEqFTGgtwLfzw3ZoC32LtB8JijivdO/w+IEZDGYFMBv7ePl 8NZeUVwJFV8bvmd5fjqc1C6Nmm1I+HGWn/JV8i9emQ== X-Google-Smtp-Source: APXvYqyfUEuC3mEmPG9s4i6tESlRo9oZEsPzue7aX/a76mK2HZr1+EEwlvQomlchaeb55fwDfrvGp+xyZoI6blk5d70= X-Received: by 2002:adf:efc1:: with SMTP id i1mr59073183wrp.199.1555562504832; Wed, 17 Apr 2019 21:41:44 -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: Andy Lutomirski Date: Wed, 17 Apr 2019 21:41:33 -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: Linus Torvalds Cc: Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , jsteckli@amazon.de, 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 , 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 5:00 PM Linus Torvalds wrote: > > 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. > 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. 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 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. 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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 01352C10F0E for ; Thu, 18 Apr 2019 04:41:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94CC1217D7 for ; Thu, 18 Apr 2019 04:41:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QVWUihYI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94CC1217D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 422786B0005; Thu, 18 Apr 2019 00:41:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A8866B0006; Thu, 18 Apr 2019 00:41:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24BFD6B0007; Thu, 18 Apr 2019 00:41:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id D95B96B0005 for ; Thu, 18 Apr 2019 00:41:49 -0400 (EDT) Received: by mail-pf1-f199.google.com with SMTP id e19so638921pfd.19 for ; Wed, 17 Apr 2019 21:41:49 -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=HEJvVD5uAri2/7g+yjiM7+uD6Xn5OUBCfeb7aIYw4eQ=; b=PwcXi2pv1TCeGRJb263dyek21SevZjbVKts5n6TfKKg3zeSt9I50xlAfKVSsiNDEhq D9jvt+9nS9WSyrs+sqHx17Y9zHlsRjbfn2g5a5R5YVejuF44bfJwLV8Xs05fmoMOvuZ2 v90HEnEexl699t4SEFy0SrXM7TE/6Ad89iJaQmxY3LeCw2VhoGXJw7JE+vl0IWvvvphQ YYhP6PZ1KbHaX8Y5iYlxIMmB7zIK00JyOgKTz+eGW1fyDJfTG/td6dMI16+mIQh+FKUN zVidJ9IZlYXjuGvxzPHJy3RX+C1GeMy8zQIqD0If46lSViWtoo34BIxSNkXF/PGN1kGa +F0A== X-Gm-Message-State: APjAAAVOg8+wEoyhe2jQTV6n9FpM57GJ/xIVyyhucMOZ9kUYBEvJ/o7x jNM8LBfSAX7tSIXYHx4jK8e/HgyZil8nYwbdqhJ98Yi/P2UT3/seCRQFDyF9KYG1nWVDDHWAlVl dyd+FwajCRWVfGXDWh0Emg8xH+RrjfsTTf+Y07FkJrQWFv6h3vA78zKF9x6v6JPCXYA== X-Received: by 2002:a62:7549:: with SMTP id q70mr83582123pfc.112.1555562509431; Wed, 17 Apr 2019 21:41:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqwJ9hAeU3pr/nZjJuSCuilg1MaTL58gojLULZr3U5r9W2/ltL65WoyhcoFeFIbBzdW3Hqr8 X-Received: by 2002:a62:7549:: with SMTP id q70mr83582081pfc.112.1555562508564; Wed, 17 Apr 2019 21:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555562508; cv=none; d=google.com; s=arc-20160816; b=yS1oGJ30U3E5dNIYABlOKNdTNfH6uziLJhnGIfjk2RK6A1zg5CD/OI3ih5RrxDLDkK RSnFLREn3Zft0SPM2ykHReVKMnneNB+gvBZw6oB6D70m+Tva3pF5RI+OiYUn+pj1JIOz 6mLzaE0xLv+bWIMZFckXgugiMEmdMdzuYw4/tGOXOgZ4mNP42iORhwf7xybnjd0sSv8a hPpERfIkv4yFV1A/nhpa+TGJUX9Ug9wJoQ7VTj0gJYGkvi1YiOgAb7urrxjKFxEQgFt0 okngbkqBSDuoDa/jYz7CxJeAzUbfhRk000djWJJi9Y6c9Zl8cJLoTMOOdfe4JMGH488/ z8hA== 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=HEJvVD5uAri2/7g+yjiM7+uD6Xn5OUBCfeb7aIYw4eQ=; b=IZMcVeMYM5HZie9gjPSDX4vRZk3ya53CmpG3hIiwVEdiBhTJvjdp/7Ofh7jQw6YiGI F/S//mdKmB61ZS1he3E3xiY2uWt5L8jLTK56/EdOCLP9DHDCqQt15VOYwDf+ASAB2KXY 5SoHGLI9btzjePvX/q1ElUMGg3PaPAM8bjTWv/HPw8AUqOPOUftpZbTqUxr4a1Wpzvme R0f98+ocHpHnAdMIBPFJG/acEJQJ59I0wCa0xOfYp1WRXjYXLrG++1xsIalqIvV5gg5g pFNA5GJfhsB2pXWb3y0G1bcU95sOUu4L25KOLvVLoGwGbckeCKuRdJPdLWkShrWr2ccv pL+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=QVWUihYI; spf=pass (google.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id x23si1028909plr.48.2019.04.17.21.41.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 21:41:48 -0700 (PDT) Received-SPF: pass (google.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) client-ip=198.145.29.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=QVWUihYI; spf=pass (google.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 01C89218EA for ; Thu, 18 Apr 2019 04:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555562508; bh=ZzJFjyGToYfbKAC7a2m7yS86J4A8OLDkslCG6xa8cQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QVWUihYIOED3b6sf++tgY3iRdj8kiMHZVbckG4nNfCAClSFzLnTcPH+IgFSB9PrKC Z2tMpLhiQqQpdAO8Vqghyo+PaFXtDr9TPVxG3ICymGFgejmh9f9/1/nnjg3BTRsxMd IElW3sPpwA7MwJfgB7BILSJAa6MZxHiR0qJmXz6w= Received: by mail-wr1-f46.google.com with SMTP id w16so1173366wrl.1 for ; Wed, 17 Apr 2019 21:41:47 -0700 (PDT) X-Received: by 2002:adf:efc1:: with SMTP id i1mr59073183wrp.199.1555562504832; Wed, 17 Apr 2019 21:41:44 -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: Andy Lutomirski Date: Wed, 17 Apr 2019 21:41:33 -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: Linus Torvalds Cc: Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , jsteckli@amazon.de, 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 , 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 5:00 PM Linus Torvalds wrote: > > 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. > 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. 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Date: Wed, 17 Apr 2019 21:41:33 -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: Linus Torvalds Cc: Thomas Gleixner , Nadav Amit , Ingo Molnar , Khalid Aziz , Juerg Haefliger , Tycho Andersen , jsteckli@amazon.de, 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" List-Id: iommu@lists.linux-foundation.org On Wed, Apr 17, 2019 at 5:00 PM Linus Torvalds wrote: > > 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. > 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. 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 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. 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, 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 4F1E4C10F0B for ; Thu, 18 Apr 2019 04:41:53 +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 1CB072184B for ; Thu, 18 Apr 2019 04:41:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="a/HEs4JE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CB072184B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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 DDE6210BA; Thu, 18 Apr 2019 04:41:52 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D096F10B6 for ; Thu, 18 Apr 2019 04:41:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F12FF4 for ; Thu, 18 Apr 2019 04:41:46 +0000 (UTC) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6679421903 for ; Thu, 18 Apr 2019 04:41:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555562506; bh=ZzJFjyGToYfbKAC7a2m7yS86J4A8OLDkslCG6xa8cQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=a/HEs4JEstxsEorSTVr1L93FOcseGDjRBAfiOfzmx2VnD5MZN3NHHDapV9Hwsdfz9 OKMxJ8HPfwGP/jsFOx+M/IbU16EhNKHDgGxKDCwa9lNrDogLByu5rzWFrRsScS1e6G Sks4+rbLnA5el6/MO/qtZgLp5K6QR4F173bPPPQ0= Received: by mail-wr1-f48.google.com with SMTP id g3so1127327wrx.9 for ; Wed, 17 Apr 2019 21:41:46 -0700 (PDT) X-Gm-Message-State: APjAAAWWVjjZkNugXAUE7P2N+Y7z1mpNiD/DR4vUU9akusYUEw0Tx/MY uMHlrBFYm0iwja6N+Fqun93qc3A5qoNq8WVPQysOAA== X-Google-Smtp-Source: APXvYqyfUEuC3mEmPG9s4i6tESlRo9oZEsPzue7aX/a76mK2HZr1+EEwlvQomlchaeb55fwDfrvGp+xyZoI6blk5d70= X-Received: by 2002:adf:efc1:: with SMTP id i1mr59073183wrp.199.1555562504832; Wed, 17 Apr 2019 21:41:44 -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: Andy Lutomirski Date: Wed, 17 Apr 2019 21:41:33 -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: Linus Torvalds 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 , 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 , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , 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: <20190418044133.zrgggAS2z9h_ly8nuDmjfyhZ_xX0Suz062XjXBbiQvw@z> On Wed, Apr 17, 2019 at 5:00 PM Linus Torvalds wrote: > > 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. > 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. 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 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. _______________________________________________ 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_SIGNED, DKIM_VALID,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 D3849C10F0B for ; Thu, 18 Apr 2019 04:41:58 +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 A13ED217D7 for ; Thu, 18 Apr 2019 04:41: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="nxJ5ypwc"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QVWUihYI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A13ED217D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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=ND5GphkazzkeT7zwyTetTnNgL033pyxqRhEVZTwWL4M=; b=nxJ5ypwc4WWIGx A9FRKaHT6MrWVzpK3OAZU1L95isw6kQnqJ1QW39F3RimU9GEbZtmfD3FY+qdBTv0LdZaKbFeMqzUm SBy80u6klXRhHJXSkTaOr5V0GDsYNw/20lzuGVsHyJazcp1HbOE2fec03QBZL6PocLF+gsYLl2B6G TwDdiHdFqeHBqw95CLLJ0Q7mEvHGnfxkNnAIf39Zoy+ozReda40r61YBzV3bXiWE4YYdkZo9T3+VA k6BcgiDTLBcICq8YDgYU9bvDcyNbdGLEljktBt44dc/plso9qoswzTVA4epSqCuWQc0sZIdFTLBkf pFU8vHnJteoOx2Ou+a4A==; 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 1hGyry-0001Ml-O6; Thu, 18 Apr 2019 04:41:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGyrt-0001CI-4Q for linux-arm-kernel@lists.infradead.org; Thu, 18 Apr 2019 04:41:52 +0000 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EDF9E21871 for ; Thu, 18 Apr 2019 04:41:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555562508; bh=ZzJFjyGToYfbKAC7a2m7yS86J4A8OLDkslCG6xa8cQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QVWUihYIOED3b6sf++tgY3iRdj8kiMHZVbckG4nNfCAClSFzLnTcPH+IgFSB9PrKC Z2tMpLhiQqQpdAO8Vqghyo+PaFXtDr9TPVxG3ICymGFgejmh9f9/1/nnjg3BTRsxMd IElW3sPpwA7MwJfgB7BILSJAa6MZxHiR0qJmXz6w= Received: by mail-wr1-f41.google.com with SMTP id q1so1178995wrp.0 for ; Wed, 17 Apr 2019 21:41:47 -0700 (PDT) X-Gm-Message-State: APjAAAVEE+dx9qLvErXEBkE6KW8zRnzDms02qBFq6nDAoXgyEpAYFthw NbNc3p7sMbbVCc/bGh69b0O6tMdDSwcQBPI9PD67WQ== X-Google-Smtp-Source: APXvYqyfUEuC3mEmPG9s4i6tESlRo9oZEsPzue7aX/a76mK2HZr1+EEwlvQomlchaeb55fwDfrvGp+xyZoI6blk5d70= X-Received: by 2002:adf:efc1:: with SMTP id i1mr59073183wrp.199.1555562504832; Wed, 17 Apr 2019 21:41:44 -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: Andy Lutomirski Date: Wed, 17 Apr 2019 21:41:33 -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: Linus Torvalds X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_214149_215702_1A30DF54 X-CRM114-Status: GOOD ( 23.45 ) 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 , 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 , "linux-alpha@vger.kernel.org" , Khalid Aziz , Juerg Haefliger , 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 5:00 PM Linus Torvalds wrote: > > 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. > 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. 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel