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.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 7E55CC282DF for ; Wed, 17 Apr 2019 16:15:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C5D921871 for ; Wed, 17 Apr 2019 16:15:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555517730; bh=rOQwJJPGGkMVzU6K62glKu4UuVWXcNyseEcIx5c1xG8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=DLF9eJGgC4E1JSwvNahhLhIhK8kFonV6njuROiKzTFtlUFnBRw7OcpZ8POT0GILF5 /bpDLYZypuMOtNMusdPG9HmMZZg4vhsfPBeK4xXkJ/aQ0psBbicML3KzjLOCLXjMsJ b9DkbK9Z9cOM4TMIkxVImrUMmaCtbmCmwZjaN84E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732704AbfDQQP3 (ORCPT ); Wed, 17 Apr 2019 12:15:29 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:45772 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729395AbfDQQP2 (ORCPT ); Wed, 17 Apr 2019 12:15:28 -0400 Received: by mail-wr1-f68.google.com with SMTP id s15so32682052wra.12; Wed, 17 Apr 2019 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=nyS/WViclzZJjR30HVMMB/ma7fcLYSTWP9QxF2Fshf4EJq6uRarq3jSaxiVNfV92fh zEZfmA69o8F7gNO5JT6uv0zE0OJeE7BWbIRv09fAQTN2l+N2dnFwJ9Lfuiiy6+74FoDp uGRo9f5/Goa9H9R9Ca2oLvyjv31O0I5e5WLdLO3tmvoyjg1wNvw+8b2zxVEfd9gJSTwJ +SSg2n/omewPli8xLPnvSElOhwgHU9I/P33Tw7RfhZ2LRLr+x5PTn04fXGfMHG1ZHR4/ XB7f4UjQbIdtenugCUJSD8W8ywk7H6JVByBN8MjE8ZURVuqLb51s1gVwQaBsfh/AY/u/ 6ICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=nBR+wtjJDdfshmdLRlUr6HJ3s3sJNaMlD/cPBjdwVglBPYCKFrAaDyohXcLTHW69r7 eASUxXylTxAMhwwqGmu6MfufZ6eZu9tYd9qUtKU/evVu/zRlWKILIgPaC8ojkOj3/Nxh AxFSZxj9WF4tnwKeBMS1ADslhqQnkOHF3BEIXOZtkJwkdLat8F6D6Zvw8T6DVAoRAyDz sjis53MhqFOeh8euiUM14P6zJUJhsOILf8Xl4qsuF+ufNUzBdq0plMPjdLGAdSB5YiwC PTehD+rKnCZ1S/DJUlhJtUbiabVAXOltmdCkLXQFT9pUEjBfIRztmeE6HWoaaUjWbmSL A0sg== X-Gm-Message-State: APjAAAXqpgtV+XHu5MDOih9bYLs8MRsw7gNiQSYn6qEBMMgwHqT2fGUr fnp1dzY8CNaMdF3T/yaLEqM= X-Google-Smtp-Source: APXvYqy35ID2kalnRZopmGnEWCBLThqKczYiLY/rC35gAIxUEa+THgEb4y2voVmHavCnFbNEpnRFQQ== X-Received: by 2002:adf:dbce:: with SMTP id e14mr59140093wrj.249.1555517726742; Wed, 17 Apr 2019 09:15:26 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id y1sm154976060wrd.34.2019.04.17.09.15.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:15:25 -0700 (PDT) Date: Wed, 17 Apr 2019 18:15:22 +0200 From: Ingo Molnar To: Khalid Aziz Cc: juergh@gmail.com, tycho@tycho.ws, jsteckli@amazon.de, keescook@google.com, konrad.wilk@oracle.com, Juerg Haefliger , deepa.srinivasan@oracle.com, chris.hyser@oracle.com, tyhicks@canonical.com, dwmw@amazon.co.uk, andrew.cooper3@citrix.com, jcm@redhat.com, boris.ostrovsky@oracle.com, iommu@lists.linux-foundation.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, Khalid Aziz , Linus Torvalds , Andrew Morton , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Arjan van de Ven , Greg Kroah-Hartman Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Message-ID: <20190417161042.GA43453@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Sorry, had to trim the Cc: list from hell. Tried to keep all the mailing lists and all x86 developers. ] * Khalid Aziz wrote: > From: Juerg Haefliger > > This patch adds basic support infrastructure for XPFO which protects > against 'ret2dir' kernel attacks. The basic idea is to enforce > exclusive ownership of page frames by either the kernel or userspace, > unless explicitly requested by the kernel. Whenever a page destined for > userspace is allocated, it is unmapped from physmap (the kernel's page > table). When such a page is reclaimed from userspace, it is mapped back > to physmap. Individual architectures can enable full XPFO support using > this infrastructure by supplying architecture specific pieces. I have a higher level, meta question: Is there any updated analysis outlining why this XPFO overhead would be required on x86-64 kernels running on SMAP/SMEP CPUs which should be all recent Intel and AMD CPUs, and with kernel that mark all direct kernel mappings as non-executable - which should be all reasonably modern kernels later than v4.0 or so? I.e. the original motivation of the XPFO patches was to prevent execution of direct kernel mappings. Is this motivation still present if those mappings are non-executable? (Sorry if this has been asked and answered in previous discussions.) Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Date: Wed, 17 Apr 2019 18:15:22 +0200 Message-ID: <20190417161042.GA43453@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Khalid Aziz Cc: juergh@gmail.com, tycho@tycho.ws, jsteckli@amazon.de, keescook@google.com, konrad.wilk@oracle.com, Juerg Haefliger , deepa.srinivasan@oracle.com, chris.hyser@oracle.com, tyhicks@canonical.com, dwmw@amazon.co.uk, andrew.cooper3@citrix.com, jcm@redhat.com, boris.ostrovsky@oracle.com, iommu@lists.linux-foundation.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, Khalid Aziz , Linus Torvalds , Andrew Morton , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Dave List-Id: iommu@lists.linux-foundation.org [ Sorry, had to trim the Cc: list from hell. Tried to keep all the mailing lists and all x86 developers. ] * Khalid Aziz wrote: > From: Juerg Haefliger > > This patch adds basic support infrastructure for XPFO which protects > against 'ret2dir' kernel attacks. The basic idea is to enforce > exclusive ownership of page frames by either the kernel or userspace, > unless explicitly requested by the kernel. Whenever a page destined for > userspace is allocated, it is unmapped from physmap (the kernel's page > table). When such a page is reclaimed from userspace, it is mapped back > to physmap. Individual architectures can enable full XPFO support using > this infrastructure by supplying architecture specific pieces. I have a higher level, meta question: Is there any updated analysis outlining why this XPFO overhead would be required on x86-64 kernels running on SMAP/SMEP CPUs which should be all recent Intel and AMD CPUs, and with kernel that mark all direct kernel mappings as non-executable - which should be all reasonably modern kernels later than v4.0 or so? I.e. the original motivation of the XPFO patches was to prevent execution of direct kernel mappings. Is this motivation still present if those mappings are non-executable? (Sorry if this has been asked and answered in previous discussions.) Thanks, Ingo 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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT 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 51776C282DC for ; Wed, 17 Apr 2019 16:15:30 +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 1C8602173C for ; Wed, 17 Apr 2019 16:15:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nyS/WVic" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C8602173C 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 DF62C1170; Wed, 17 Apr 2019 16:15:29 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9FD3B116D for ; Wed, 17 Apr 2019 16:15:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C28886F for ; Wed, 17 Apr 2019 16:15:28 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id s15so32682051wra.12 for ; Wed, 17 Apr 2019 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=nyS/WViclzZJjR30HVMMB/ma7fcLYSTWP9QxF2Fshf4EJq6uRarq3jSaxiVNfV92fh zEZfmA69o8F7gNO5JT6uv0zE0OJeE7BWbIRv09fAQTN2l+N2dnFwJ9Lfuiiy6+74FoDp uGRo9f5/Goa9H9R9Ca2oLvyjv31O0I5e5WLdLO3tmvoyjg1wNvw+8b2zxVEfd9gJSTwJ +SSg2n/omewPli8xLPnvSElOhwgHU9I/P33Tw7RfhZ2LRLr+x5PTn04fXGfMHG1ZHR4/ XB7f4UjQbIdtenugCUJSD8W8ywk7H6JVByBN8MjE8ZURVuqLb51s1gVwQaBsfh/AY/u/ 6ICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=R3VJNRZZhZfmPskbYEb7altITSnQ/NMCiNjOePzFCbljKRH+FCbhRQJbWTv6bzDbsn 6tQiOziAoHejdk/D4j+5FfS0X9ifiA1XgJ8YSKNX+7fDGdEymU4XIC99EcWPcd33PPZE wrAFrgwmjvISfG8XsyeBivJlDDSBSsisiUxgOXeD7+p5xo605qPlvg74YzxYZuLLNtHs WWlwvMc+bE0KuDOGR+g758Ismt9VQQRp50lg0+dUSMxBe6Lxax6e4i05AtkLqpotoVn9 1sWck/Z9T2LVQ1bhMdBJ9tb7lp2YGXn/QAssmzS7Mma3wjt63zLrSnHOOxbgornrMLr1 +2Zg== X-Gm-Message-State: APjAAAVXlVGXNBsT6FEizNiemIeoxicPncztZC3vyr67UaNNUQDSYWkS sb320Hw58akxu/1vBymfayw= X-Google-Smtp-Source: APXvYqy35ID2kalnRZopmGnEWCBLThqKczYiLY/rC35gAIxUEa+THgEb4y2voVmHavCnFbNEpnRFQQ== X-Received: by 2002:adf:dbce:: with SMTP id e14mr59140093wrj.249.1555517726742; Wed, 17 Apr 2019 09:15:26 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id y1sm154976060wrd.34.2019.04.17.09.15.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:15:25 -0700 (PDT) Date: Wed, 17 Apr 2019 18:15:22 +0200 From: Ingo Molnar To: Khalid Aziz Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Message-ID: <20190417161042.GA43453@gmail.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Dave Hansen , linux-doc@vger.kernel.org, linux-mm@kvack.org, deepa.srinivasan@oracle.com, "H. Peter Anvin" , Thomas Gleixner , tycho@tycho.ws, x86@kernel.org, iommu@lists.linux-foundation.org, jsteckli@amazon.de, Arjan van de Ven , Peter Zijlstra , konrad.wilk@oracle.com, jcm@redhat.com, Greg Kroah-Hartman , Borislav Petkov , Andy Lutomirski , boris.ostrovsky@oracle.com, chris.hyser@oracle.com, linux-arm-kernel@lists.infradead.org, Khalid Aziz , juergh@gmail.com, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, tyhicks@canonical.com, linux-security-module@vger.kernel.org, Juerg Haefliger , keescook@google.com, Andrew Morton , Linus Torvalds , dwmw@amazon.co.uk 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: <20190417161522.2Bq_dIpLgstghE0Xrp8uniKQSAqVrBiOdMdClQVh0kc@z> [ Sorry, had to trim the Cc: list from hell. Tried to keep all the mailing lists and all x86 developers. ] * Khalid Aziz wrote: > From: Juerg Haefliger > > This patch adds basic support infrastructure for XPFO which protects > against 'ret2dir' kernel attacks. The basic idea is to enforce > exclusive ownership of page frames by either the kernel or userspace, > unless explicitly requested by the kernel. Whenever a page destined for > userspace is allocated, it is unmapped from physmap (the kernel's page > table). When such a page is reclaimed from userspace, it is mapped back > to physmap. Individual architectures can enable full XPFO support using > this infrastructure by supplying architecture specific pieces. I have a higher level, meta question: Is there any updated analysis outlining why this XPFO overhead would be required on x86-64 kernels running on SMAP/SMEP CPUs which should be all recent Intel and AMD CPUs, and with kernel that mark all direct kernel mappings as non-executable - which should be all reasonably modern kernels later than v4.0 or so? I.e. the original motivation of the XPFO patches was to prevent execution of direct kernel mappings. Is this motivation still present if those mappings are non-executable? (Sorry if this has been asked and answered in previous discussions.) Thanks, Ingo _______________________________________________ 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=0.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 4BFCAC282DA for ; Wed, 17 Apr 2019 16:15:40 +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 1DF7320674 for ; Wed, 17 Apr 2019 16:15:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="C+yy8vfZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nyS/WVic" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DF7320674 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dqwBduuhOezAAkAq8hl4C8gDXwnbtcv6F28Gx0RBhXU=; b=C+yy8vfZ95m3xP E08OnkOQ2jBT9n9NUiLe+ua11AWBJgfPvZbyNqPaCec4191GVR1VvTwuufQY2wG2NEPYEMjyRCTqr aNOU09/Xr1NNK0pX7VStZN3/xzfGU8+ekMDsVbD1gsWJbpuV5agPMYVuFCGp5KeJdy69v8H0Oike2 bG2fd4+uTj/2ejteDC2veyZkcl3IcdAajEwjndDhn1WjUKJ3pnf97lBPrISeg3zLR1tNd9Is2BWkz k3KWNnNJKEULyPFSKGHMAwlY2cdfd9ADMIsbGu2yDwuR/d++CbTa8c/Z+zbdx+ZXARNjFoiH8WxQ6 7N8PwbCiOz5b9g8roANA==; 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 1hGnDi-0002rK-59; Wed, 17 Apr 2019 16:15:34 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGnDe-0002qY-3I for linux-arm-kernel@lists.infradead.org; Wed, 17 Apr 2019 16:15:32 +0000 Received: by mail-wr1-x444.google.com with SMTP id w10so32760732wrm.4 for ; Wed, 17 Apr 2019 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=nyS/WViclzZJjR30HVMMB/ma7fcLYSTWP9QxF2Fshf4EJq6uRarq3jSaxiVNfV92fh zEZfmA69o8F7gNO5JT6uv0zE0OJeE7BWbIRv09fAQTN2l+N2dnFwJ9Lfuiiy6+74FoDp uGRo9f5/Goa9H9R9Ca2oLvyjv31O0I5e5WLdLO3tmvoyjg1wNvw+8b2zxVEfd9gJSTwJ +SSg2n/omewPli8xLPnvSElOhwgHU9I/P33Tw7RfhZ2LRLr+x5PTn04fXGfMHG1ZHR4/ XB7f4UjQbIdtenugCUJSD8W8ywk7H6JVByBN8MjE8ZURVuqLb51s1gVwQaBsfh/AY/u/ 6ICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2E2gGWXwlEXHD0EdhjliuzLa0L4LUy3dnmNjJuBPY1M=; b=KVDTkEdOBaWhpNzpBmmUxcNWYKCTHuc0X/1/970YQFfVMPJ3qZ9UGXydNOf8Ieoovh /P/sp0rXYcDFpAPb48CLzWzZlftOuGX4Z0HgAmY2Q1Bej+lWbWA5TOlnU3Q/JRq511Lz xKou7LYK558wAVtp5p8V5n0myb0k1Llhrcuas7z3sXjolVx3zn+49Xu8nDrcOxiUlr1v OlOQEt0PU4NUbfl53E0v8oRPWm2tCJkZAlS7DGJT9Ya5z4La8QB6gAa/oEUAVu+VdwVb eh+H7nvjjfIQr3w+7L7VFfV5DZGui3TGVrp4l1cJkZro10Z/w0Le94ooPT9Iue9s0jBT /FEA== X-Gm-Message-State: APjAAAUx2tmAIuNA8oAaTCz+lJStavg+wCTyo5CwakxIOsyMXuRmX5nY cSGnn5WZJ8yeFBnUNfBrUJo= X-Google-Smtp-Source: APXvYqy35ID2kalnRZopmGnEWCBLThqKczYiLY/rC35gAIxUEa+THgEb4y2voVmHavCnFbNEpnRFQQ== X-Received: by 2002:adf:dbce:: with SMTP id e14mr59140093wrj.249.1555517726742; Wed, 17 Apr 2019 09:15:26 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id y1sm154976060wrd.34.2019.04.17.09.15.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:15:25 -0700 (PDT) Date: Wed, 17 Apr 2019 18:15:22 +0200 From: Ingo Molnar To: Khalid Aziz Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Message-ID: <20190417161042.GA43453@gmail.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_091530_166865_61EE5444 X-CRM114-Status: GOOD ( 14.80 ) 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 , linux-doc@vger.kernel.org, linux-mm@kvack.org, deepa.srinivasan@oracle.com, "H. Peter Anvin" , Thomas Gleixner , tycho@tycho.ws, x86@kernel.org, iommu@lists.linux-foundation.org, jsteckli@amazon.de, Arjan van de Ven , Peter Zijlstra , konrad.wilk@oracle.com, jcm@redhat.com, Greg Kroah-Hartman , Borislav Petkov , Andy Lutomirski , boris.ostrovsky@oracle.com, chris.hyser@oracle.com, linux-arm-kernel@lists.infradead.org, Khalid Aziz , juergh@gmail.com, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, tyhicks@canonical.com, linux-security-module@vger.kernel.org, Juerg Haefliger , keescook@google.com, Andrew Morton , Linus Torvalds , dwmw@amazon.co.uk 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 [ Sorry, had to trim the Cc: list from hell. Tried to keep all the mailing lists and all x86 developers. ] * Khalid Aziz wrote: > From: Juerg Haefliger > > This patch adds basic support infrastructure for XPFO which protects > against 'ret2dir' kernel attacks. The basic idea is to enforce > exclusive ownership of page frames by either the kernel or userspace, > unless explicitly requested by the kernel. Whenever a page destined for > userspace is allocated, it is unmapped from physmap (the kernel's page > table). When such a page is reclaimed from userspace, it is mapped back > to physmap. Individual architectures can enable full XPFO support using > this infrastructure by supplying architecture specific pieces. I have a higher level, meta question: Is there any updated analysis outlining why this XPFO overhead would be required on x86-64 kernels running on SMAP/SMEP CPUs which should be all recent Intel and AMD CPUs, and with kernel that mark all direct kernel mappings as non-executable - which should be all reasonably modern kernels later than v4.0 or so? I.e. the original motivation of the XPFO patches was to prevent execution of direct kernel mappings. Is this motivation still present if those mappings are non-executable? (Sorry if this has been asked and answered in previous discussions.) Thanks, Ingo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel