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 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 E1943C4360F for ; Fri, 5 Apr 2019 15:46:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 85BCB2184B for ; Fri, 5 Apr 2019 15:46:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="sUuIMJJ7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85BCB2184B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 241DC6B0008; Fri, 5 Apr 2019 11:46:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CB586B000D; Fri, 5 Apr 2019 11:46:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01D6A6B0269; Fri, 5 Apr 2019 11:46:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yw1-f72.google.com (mail-yw1-f72.google.com [209.85.161.72]) by kanga.kvack.org (Postfix) with ESMTP id CF78A6B0008 for ; Fri, 5 Apr 2019 11:46:06 -0400 (EDT) Received: by mail-yw1-f72.google.com with SMTP id x66so4792759ywx.1 for ; Fri, 05 Apr 2019 08:46:06 -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:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aW5eO1Y1EqwbPPw39yD2qVZTCtUucALBP6ZcE8RoydE=; b=tPWN+m+d1rSPfXdoZDv0q0d4iET2xlBYqfonZxbdXgiqOgsthmoZKpECzoNVPSkaTv DT0CLD9j/y8fmrs9rIwo7icrSKmBLq3eQyP9jSrsy9kgdFMGZkwCbn1CB9qNYzMzBQ4w ToPX3u0nsZqR+AXZ9R+Q0XLLR1CCb2kKrp9k+5yovl6ycbYvzD0S+bfcLFcIh3Koq3Nh eWjKGHzKDB3J3Mb+GSUapu2K3WgPQ/gmphZN5A766EywBlulXI68DJ3K5l1znre3/0UV 1reIR9uJwhFnRbIWsgY/U0y/+gAHG0d8TKQxOkfqWZ7+sShpsYy/BBoRYtC3EkTO6S3y ddtQ== X-Gm-Message-State: APjAAAWMkkPKKd2w3YGOWtiiepqFvlFy0parusRve3SjdHslNAOOf6PB NCr5ybkT36vbHz9IOBZ4OetnndLhJJl/Ll9ZbaO4mTNcJQ7I6e/hKiMRaleQwHkAKJnlxZEjlqL kOWAozQyAgZ7srP5JBImPnyCM9SW/q9EnBwzIX1+eCwZ9ox9JT9VDwlycGF31GeCXTA== X-Received: by 2002:a81:378a:: with SMTP id e132mr10922107ywa.137.1554479166472; Fri, 05 Apr 2019 08:46:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqzfVtqSRbRINUix+q2uCNjmE20Q2ipF0gaqHAYGNdmvjWbnKSGY4rvmBqV+KJNpFshgfOz5 X-Received: by 2002:a81:378a:: with SMTP id e132mr10922016ywa.137.1554479165414; Fri, 05 Apr 2019 08:46:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554479165; cv=none; d=google.com; s=arc-20160816; b=l2ONdCjKSEhh3sK5wdiPltdYeb7KSzWn3D27JBQrku5cD81C7OQrmvTKnFtF8Scvn0 C5ST/Csq1SxOycpzLClz1Oyk30Hjblkw1IQkVSlrGJnU+360rFQduvw1KtIeUxTmaRnb IqCrhnmt/r0AUu28q7MqWAuTbVD19IcxOQVV6gM6wLiVPg6H6KnmHa5UuhoouAw6THHi 7CEpSnXAPAwaXklCJ+TyYXyS12BSAhtrEIYUx8HmQZ+5Ozqlz6j63nCard2eSLGCQxCT 81x4DDs6hh6V6L+7ssK1BSw/2Lz9gawbLr5y59ItP+mjxFxTpTvKYN5XuuLLzWSPyhkY 8EUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:from:references:cc:to :subject:dkim-signature; bh=aW5eO1Y1EqwbPPw39yD2qVZTCtUucALBP6ZcE8RoydE=; b=pvjGj0FjMfCsOfzxxntnjVQUYdxFiT22Mi4dUZTd6pLoewWshc24ji5PRCSU90rJVM 1zqLrEI4BUz/WoQ2RfNydSPI/14HOt34lXDgln5hHjhgp/oUbv5VPpCIQwJ5jI+oopCa sDWT5bKmJuEJvr4wW6IVpCOABJsprKfQcWXphVoOtfwWiVpFP/dH8vo47zoEU9E9N5i8 je67v6qQ7rcrM/RbKnNGpPA6rfCRv0T9fEy+u6HH232N2LUA8ZrowqNQ7kgxgekFNWs8 ke6IogOXl1Q5sAE4V9XLSjTyejAb6MmEYO6tQGTun+mkwI60hDN/vXpf57tzI1jIWY/8 Lygw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=sUuIMJJ7; spf=pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.85 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from userp2120.oracle.com (userp2120.oracle.com. [156.151.31.85]) by mx.google.com with ESMTPS id j2si3384285ybm.394.2019.04.05.08.46.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 08:46:05 -0700 (PDT) Received-SPF: pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.85 as permitted sender) client-ip=156.151.31.85; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=sUuIMJJ7; spf=pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.85 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35FhrLK026668; Fri, 5 Apr 2019 15:45:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=aW5eO1Y1EqwbPPw39yD2qVZTCtUucALBP6ZcE8RoydE=; b=sUuIMJJ70LKZCsyXOAF45n8HvPFH4UW3fh0oycGVdLivZfpUXrUw1KKLCZi785NH89m/ yApQkgSt3xhCZmm01LdEACVxdeUxXM18nHTYZcoTlnr+cHKNyHVcqMjlD29JSn5qSLS0 2Z5O2MFRjQeGU3kRhNzkohxnVzJHX88G4/32Dm7SCP7syRYYwk35b7UJl2beMBOAc1Ua w8u5dZYY01gtoKQJ1G0Kn0CVKjrKdR3MtCLcd1jtAMGcJPHAqUBcLk/2/Mi8NVr9OjC7 bcsVzP/Tj8DTC7eMxmKZ2WySnfdXWQKPXogVEL4yGagQ7+bCNrr830/w/gUmWEgKVBsK dA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2rj13qnjdv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 15:45:01 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35FhQPb044273; Fri, 5 Apr 2019 15:45:00 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2rp35rxevv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 15:45:00 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x35FidGg024942; Fri, 5 Apr 2019 15:44:39 GMT Received: from [192.168.1.16] (/24.9.64.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Apr 2019 08:44:38 -0700 Subject: Re: [RFC PATCH v9 12/13] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only) To: Dave Hansen , Thomas Gleixner Cc: Andy Lutomirski , Juerg Haefliger , Tycho Andersen , jsteckli@amazon.de, Andi Kleen , liran.alon@oracle.com, Kees Cook , Konrad Rzeszutek Wilk , deepa.srinivasan@oracle.com, chris hyser , Tyler Hicks , "Woodhouse, David" , Andrew Cooper , Jon Masters , Boris Ostrovsky , kanth.ghatraju@oracle.com, Joao Martins , Jim Mattson , pradeep.vincent@oracle.com, John Haxby , "Kirill A. Shutemov" , Christoph Hellwig , steven.sistare@oracle.com, Laura Abbott , Peter Zijlstra , Aaron Lu , Andrew Morton , alexander.h.duyck@linux.intel.com, Amir Goldstein , Andrey Konovalov , aneesh.kumar@linux.ibm.com, anthony.yznaga@oracle.com, Ard Biesheuvel , Arnd Bergmann , arunks@codeaurora.org, Ben Hutchings , Sebastian Andrzej Siewior , Borislav Petkov , brgl@bgdev.pl, Catalin Marinas , Jonathan Corbet , cpandya@codeaurora.org, Daniel Vetter , Dan Williams , Greg KH , Roman Gushchin , Johannes Weiner , "H. Peter Anvin" , Joonsoo Kim , James Morse , Jann Horn , Juergen Gross , Jiri Kosina , James Morris , Joe Perches , Souptick Joarder , Joerg Roedel , Keith Busch , Konstantin Khlebnikov , Logan Gunthorpe , marco.antonio.780@gmail.com, Mark Rutland , Mel Gorman , Michal Hocko , Michal Hocko , Mike Kravetz , Ingo Molnar , "Michael S. Tsirkin" , Marek Szyprowski , Nicholas Piggin , osalvador@suse.de, "Paul E. McKenney" , pavel.tatashin@microsoft.com, Randy Dunlap , richard.weiyang@gmail.com, Rik van Riel , David Rientjes , Robin Murphy , Steven Rostedt , Mike Rapoport , Sai Praneeth Prakhya , "Serge E. Hallyn" , Steve Capper , thymovanbeers@gmail.com, Vlastimil Babka , Will Deacon , Matthew Wilcox , yang.shi@linux.alibaba.com, yaojun8558363@gmail.com, Huang Ying , zhangshaokun@hisilicon.com, iommu@lists.linux-foundation.org, X86 ML , linux-arm-kernel , "open list:DOCUMENTATION" , LKML , Linux-MM , LSM List , Khalid Aziz References: <4495dda4bfc4a06b3312cc4063915b306ecfaecb.1554248002.git.khalid.aziz@oracle.com> <91f1dbce-332e-25d1-15f6-0e9cfc8b797b@oracle.com> <26b00051-b03c-9fce-1446-52f0d6ed52f8@intel.com> From: Khalid Aziz Organization: Oracle Corp Message-ID: Date: Fri, 5 Apr 2019 09:44:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <26b00051-b03c-9fce-1446-52f0d6ed52f8@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9218 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050106 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9218 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050107 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 4/5/19 8:44 AM, Dave Hansen wrote: > On 4/5/19 12:17 AM, Thomas Gleixner wrote: >>> process. Is that an acceptable trade-off? >> You are not seriously asking whether creating a user controllable ret2= dir >> attack window is a acceptable trade-off? April 1st was a few days ago.= >=20 > Well, let's not forget that this set at least takes us from "always > vulnerable to ret2dir" to a choice between: >=20 > 1. fast-ish and "vulnerable to ret2dir for a user-controllable window" > 2. slow and "mitigated against ret2dir" >=20 > Sounds like we need a mechanism that will do the deferred XPFO TLB > flushes whenever the kernel is entered, and not _just_ at context switc= h > time. This permits an app to run in userspace with stale kernel TLB > entries as long as it wants... that's harmless. That sounds like a good idea. This TLB flush only needs to be done at kernel entry when there is a pending flush posted for that cpu. What this does is move the cost of TLB flush from next context switch to kernel entry and does not add any more flushes than what we are doing with these xpfo patches. So the overall performance impact might not change much. It seems worth coding up. Thanks, Khalid From mboxrd@z Thu Jan 1 00:00:00 1970 From: Khalid Aziz Subject: Re: [RFC PATCH v9 12/13] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only) Date: Fri, 5 Apr 2019 09:44:32 -0600 Message-ID: References: <4495dda4bfc4a06b3312cc4063915b306ecfaecb.1554248002.git.khalid.aziz@oracle.com> <91f1dbce-332e-25d1-15f6-0e9cfc8b797b@oracle.com> <26b00051-b03c-9fce-1446-52f0d6ed52f8@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <26b00051-b03c-9fce-1446-52f0d6ed52f8-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Dave Hansen , Thomas Gleixner Cc: Catalin Marinas , Will Deacon , steven.sistare-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, Christoph Hellwig , Tycho Andersen , Andi Kleen , aneesh.kumar-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org, James Morris , David Rientjes , anthony.yznaga-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, Rik van Riel , Nicholas Piggin , Mike Rapoport , Andy Lutomirski , Greg KH , Randy Dunlap , LKML , Souptick Joarder , Jiri Kosina , Joe Perches , arunks-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Andrew Morton , "Woodhouse, David" , Mark Rutland , "open list:DOCUMENTATION" List-Id: iommu@lists.linux-foundation.org On 4/5/19 8:44 AM, Dave Hansen wrote: > On 4/5/19 12:17 AM, Thomas Gleixner wrote: >>> process. Is that an acceptable trade-off? >> You are not seriously asking whether creating a user controllable ret2dir >> attack window is a acceptable trade-off? April 1st was a few days ago. > > Well, let's not forget that this set at least takes us from "always > vulnerable to ret2dir" to a choice between: > > 1. fast-ish and "vulnerable to ret2dir for a user-controllable window" > 2. slow and "mitigated against ret2dir" > > Sounds like we need a mechanism that will do the deferred XPFO TLB > flushes whenever the kernel is entered, and not _just_ at context switch > time. This permits an app to run in userspace with stale kernel TLB > entries as long as it wants... that's harmless. That sounds like a good idea. This TLB flush only needs to be done at kernel entry when there is a pending flush posted for that cpu. What this does is move the cost of TLB flush from next context switch to kernel entry and does not add any more flushes than what we are doing with these xpfo patches. So the overall performance impact might not change much. It seems worth coding up. Thanks, Khalid 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 37552C4360F for ; Fri, 5 Apr 2019 15:47:23 +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 00FBF21855 for ; Fri, 5 Apr 2019 15:47:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="sUuIMJJ7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 00FBF21855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com 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 B2D9D22C6; Fri, 5 Apr 2019 15:47:22 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1135722C1 for ; Fri, 5 Apr 2019 15:46:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A24BFD for ; Fri, 5 Apr 2019 15:46:22 +0000 (UTC) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35FhrLK026668; Fri, 5 Apr 2019 15:45:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=aW5eO1Y1EqwbPPw39yD2qVZTCtUucALBP6ZcE8RoydE=; b=sUuIMJJ70LKZCsyXOAF45n8HvPFH4UW3fh0oycGVdLivZfpUXrUw1KKLCZi785NH89m/ yApQkgSt3xhCZmm01LdEACVxdeUxXM18nHTYZcoTlnr+cHKNyHVcqMjlD29JSn5qSLS0 2Z5O2MFRjQeGU3kRhNzkohxnVzJHX88G4/32Dm7SCP7syRYYwk35b7UJl2beMBOAc1Ua w8u5dZYY01gtoKQJ1G0Kn0CVKjrKdR3MtCLcd1jtAMGcJPHAqUBcLk/2/Mi8NVr9OjC7 bcsVzP/Tj8DTC7eMxmKZ2WySnfdXWQKPXogVEL4yGagQ7+bCNrr830/w/gUmWEgKVBsK dA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2rj13qnjdv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 15:45:01 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35FhQPb044273; Fri, 5 Apr 2019 15:45:00 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2rp35rxevv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 15:45:00 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x35FidGg024942; Fri, 5 Apr 2019 15:44:39 GMT Received: from [192.168.1.16] (/24.9.64.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Apr 2019 08:44:38 -0700 Subject: Re: [RFC PATCH v9 12/13] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only) To: Dave Hansen , Thomas Gleixner References: <4495dda4bfc4a06b3312cc4063915b306ecfaecb.1554248002.git.khalid.aziz@oracle.com> <91f1dbce-332e-25d1-15f6-0e9cfc8b797b@oracle.com> <26b00051-b03c-9fce-1446-52f0d6ed52f8@intel.com> From: Khalid Aziz Organization: Oracle Corp Message-ID: Date: Fri, 5 Apr 2019 09:44:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <26b00051-b03c-9fce-1446-52f0d6ed52f8@intel.com> Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9218 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050106 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9218 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050107 Cc: Catalin Marinas , Will Deacon , steven.sistare@oracle.com, Christoph Hellwig , Tycho Andersen , Andi Kleen , aneesh.kumar@linux.ibm.com, James Morris , David Rientjes , anthony.yznaga@oracle.com, Rik van Riel , Nicholas Piggin , Mike Rapoport , Andy Lutomirski , Greg KH , Randy Dunlap , LKML , Souptick Joarder , Jiri Kosina , Joe Perches , arunks@codeaurora.org, Andrew Morton , "Woodhouse, David" , Mark Rutland , "open list:DOCUMENTATION" , Keith Busch , Joao Martins , "H. Peter Anvin" , brgl@bgdev.pl, Konrad Rzeszutek Wilk , jsteckli@amazon.de, Joerg Roedel , Kees Cook , zhangshaokun@hisilicon.com, Boris Ostrovsky , chris hyser , linux-arm-kernel , Khalid Aziz , Aaron Lu , Steve Capper , James Morse , Joonsoo Kim , Mike Kravetz , Michal Hocko , alexander.h.duyck@linux.intel.com, Jonathan Corbet , Matthew Wilcox , Konstantin Khlebnikov , kanth.ghatraju@oracle.com, Huang Ying , "Paul E. McKenney" , Ben Hutchings , "Serge E. Hallyn" , Arnd Bergmann , Andrey Konovalov , Steven Rostedt , Borislav Petkov , Dan Williams , osalvador@suse.de, Ard Biesheuvel , iommu@lists.linux-foundation.org, Andrew Cooper , Logan Gunthorpe , Roman Gushchin , "Kirill A. Shutemov" , Michal Hocko , "Michael S. Tsirkin" , Peter Zijlstra , Daniel Vetter , Sebastian Andrzej Siewior , Amir Goldstein , Linux-MM , deepa.srinivasan@oracle.com, cpandya@codeaurora.org, X86 ML , yaojun8558363@gmail.com, Ingo Molnar , Jon Masters , thymovanbeers@gmail.com, Laura Abbott , pradeep.vincent@oracle.com, pavel.tatashin@microsoft.com, Jann Horn , Vlastimil Babka , Jim Mattson , Juergen Gross , marco.antonio.780@gmail.com, yang.shi@linux.alibaba.com, Juerg Haefliger , Mel Gorman , Tyler Hicks , John Haxby , LSM List , Johannes Weiner , liran.alon@oracle.com, Robin Murphy 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: <20190405154432.RdzZmpODQH9MazUcaIVBj3vg0uVCSvQZBH6oR4HsKVQ@z> On 4/5/19 8:44 AM, Dave Hansen wrote: > On 4/5/19 12:17 AM, Thomas Gleixner wrote: >>> process. Is that an acceptable trade-off? >> You are not seriously asking whether creating a user controllable ret2dir >> attack window is a acceptable trade-off? April 1st was a few days ago. > > Well, let's not forget that this set at least takes us from "always > vulnerable to ret2dir" to a choice between: > > 1. fast-ish and "vulnerable to ret2dir for a user-controllable window" > 2. slow and "mitigated against ret2dir" > > Sounds like we need a mechanism that will do the deferred XPFO TLB > flushes whenever the kernel is entered, and not _just_ at context switch > time. This permits an app to run in userspace with stale kernel TLB > entries as long as it wants... that's harmless. That sounds like a good idea. This TLB flush only needs to be done at kernel entry when there is a pending flush posted for that cpu. What this does is move the cost of TLB flush from next context switch to kernel entry and does not add any more flushes than what we are doing with these xpfo patches. So the overall performance impact might not change much. It seems worth coding up. Thanks, Khalid _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu