Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1122779ybh; Tue, 10 Mar 2020 15:15:37 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuGERkke7K0u8Pr6T/GF1shv6sAOLlIumMsMSWxBs/KZusk9BlCx/DweWQaFUIxL7aw4xGE X-Received: by 2002:a9d:2c44:: with SMTP id f62mr19704560otb.7.1583878537497; Tue, 10 Mar 2020 15:15:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583878537; cv=none; d=google.com; s=arc-20160816; b=Wz1DNzv+Tx8i/FMqdOsz2uNe618nr0I9o9r9OeF5Zcqg73TVp0WD6tQUA5eZMbdhkU jRbV+21c9QURfWHnLCh7mzuqt3roXaMO7eSVaZyyINlGehuDpG6fWBMpqIiBgWZ7cgj3 zsWwKEbaq/p2jItA7qge3YoE5q5x2FmbixF2EmJJA0Oa+vN5yj+S1PRWHTsCMBKmIcN5 GBtb634aUOdIQJzys1gYwpIAQ+Bqf9W0CbqiyrB8TSM72gTpegYZelf8Q7AYEXIcOLxQ 0IKmeVx9K5jyAH1eCOAxHV+9kUnZeuiwwyIlir2m3gJ/kCLq7ZucMoPxG2F043aoQ0dz HRSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=qC8GAUuR4P3Ihh/wBkWywJtv6lirNyfGJk8EnvJshE8=; b=rnuRsscOk4rxr+rE1DWaBdPN3XPP+7FoI20+ctiaEuAthc9axbzbUbpkIoFxVJVOTD ++zRf5iNnqiyNk/bdxtjKcbwVPgQw8jAmbfFFmczrMyGkB+h6DV/z2h5Ftvaig+9TfoV 0P7BBprRUEhm2yz4FMjqE6Lcgi5t2YqbsmkdSbGIIwIfV3S8ud1ehRD6ojCY9xlYwYmB myn32TNG9QgvdBU0jA6PrjFNQmP/FaWWBYIynnxklx0TlPCHGsOM+HL0v17qqPtUrT3K TPpVeBqrBJrke0RdqsDdqMwLhVwtZ3bUZOyRmfP3Iz2ujye6eqoHp7Ag+VZh8EnJO8pU MB4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=jZvVnCBe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t130si94179oib.202.2020.03.10.15.15.25; Tue, 10 Mar 2020 15:15:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=jZvVnCBe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727749AbgCJWOo (ORCPT + 99 others); Tue, 10 Mar 2020 18:14:44 -0400 Received: from mail-pj1-f49.google.com ([209.85.216.49]:54891 "EHLO mail-pj1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbgCJWOo (ORCPT ); Tue, 10 Mar 2020 18:14:44 -0400 Received: by mail-pj1-f49.google.com with SMTP id np16so1012791pjb.4 for ; Tue, 10 Mar 2020 15:14:43 -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=qC8GAUuR4P3Ihh/wBkWywJtv6lirNyfGJk8EnvJshE8=; b=jZvVnCBeMjLVo4/ypI5WH9f5cD9fa7eRyo8ChnGZP7Dy3c4fuAfswYtWukOMt2pPlG nkm6sguxpkwMfvNGcU1Qy4zQqYY5SfWaD4wNcelQ1Bp9Zk5CEf4AU6vGZtS8u84BUrNR 8cxGzN4+e3V618fVyF8mri1OxOKhkWOdPNJll5Yt+fCR/e/HX833UB1L7nbfvO1RoO5O +9ggd/8ngqGTlbUrgQdPpGf0Lu5XxEhbLcSX9D34glSy2kywmCkAHkrzlu8QxzUharIN EeyUkwy1W7f0siKUmpsWZaQ1kuJGS2qHbGNcTsqBcGsg8ndO5DyTSC2qM1DWfTlrh2lT Qwkw== 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=qC8GAUuR4P3Ihh/wBkWywJtv6lirNyfGJk8EnvJshE8=; b=nsy80g51nHLiY94+DyIVZJgb4tGAy1YYMJlALG7GIb2FzumdV/1P0SM6mv7aSo3CAf 88QRrCIkYIq0thU8PtQeosFkib895iRaEoKoFJ1fdsO9pksZ6TMnUNQwR0963Ycd103Q a3XaS3e53/k79dbgd+TVKOYy+e5coeYkeWadGZ+TmLymlLJfXt1uZkqU17Owwu/PH14t nqe//CBllAY7+n8Eciozzrv4dAxUuWUxMJZibbQfKqCr1OVnePMnBuDLe+AJjdGxsJQh LSR8lj0swECPDCQT9nbCS307aig5V8Xo7d3Y4NkfbmkJtEw0rkmXMqC6JBEo+U8ETvOi HpzA== X-Gm-Message-State: ANhLgQ1mYCwlnv18JGmzFHb6ullkG/YtnhUZqm21vwHcULXdLJ6zT7C9 0L75pCF7wVUXIAAPB14CjHE= X-Received: by 2002:a17:902:db83:: with SMTP id m3mr117436pld.166.1583878483130; Tue, 10 Mar 2020 15:14:43 -0700 (PDT) Received: from google.com ([2620:15c:211:1:3e01:2939:5992:52da]) by smtp.gmail.com with ESMTPSA id o2sm42464515pfh.26.2020.03.10.15.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 15:14:41 -0700 (PDT) Date: Tue, 10 Mar 2020 15:14:40 -0700 From: Minchan Kim To: Jann Horn Cc: Michal Hocko , Linux-MM , kernel list , Daniel Colascione , Dave Hansen , "Joel Fernandes (Google)" Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings? Message-ID: <20200310221440.GA72963@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jann, On Tue, Mar 10, 2020 at 07:08:28PM +0100, Jann Horn wrote: > Hi! > > From looking at the source code, it looks to me as if using > MADV_PAGEOUT on a CoW anonymous mapping will page out the page if > possible, even if other processes still have the same page mapped. Is > that correct? > > If so, that's probably bad in environments where many processes (with > different privileges) are forked from a single zygote process (like > Android and Chrome), I think? If you accidentally call it on a CoW > anonymous mapping with shared pages, you'll degrade the performance of > other processes. And if an attacker does it intentionally, they could > use that to aid with exploiting race conditions or weird > microarchitectural stuff (e.g. the new https://lviattack.eu/lvi.pdf > talks about "the assumption that attackers can provoke page faults or > microcode assists for (arbitrary) load operations in the victim > domain"). > > Should madvise_cold_or_pageout_pte_range() maybe refuse to operate on > pages with mapcount>1, or something like that? Or does it already do > that, and I just missed the check? Originally, patchset had the mapcount check to filer out shared page due to performance concern, not security stuff. However, the code was removed because reviewer asked me "let the shared pages rely on general LRU" because shared pages would have higher chance to be touched compared to private pages so naturally, they will keep in the memory. It did make sense for me. I am not familiar with the security stuff but if it's really vulnerable and everyone agree on that, it's easy to add mapcount check there. Thanks.