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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4992C433F5 for ; Tue, 24 May 2022 20:22:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 227778D0003; Tue, 24 May 2022 16:22:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BCC08D0001; Tue, 24 May 2022 16:22:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A0368D0003; Tue, 24 May 2022 16:22:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EAEC88D0001 for ; Tue, 24 May 2022 16:22:35 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A6D7034385 for ; Tue, 24 May 2022 20:22:35 +0000 (UTC) X-FDA: 79501759470.16.5125285 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf31.hostedemail.com (Postfix) with ESMTP id D9A8E2002F for ; Tue, 24 May 2022 20:22:00 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id a38so14343387pgl.9 for ; Tue, 24 May 2022 13:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YUnVxa5pnWd8D3oQLkMmXCsz6an77MCtCR1yPtv/LsQ=; b=VSYu/WzfHyNKrcVPPaxgRUerwl88cq5BG0EKH4DrtupwYUlU8DEcGjsDzAizLKW2Qt Le6afW2RDgD/ZQ2H87iYUqm7AjSq0acsYfxJ3NwWSWp5/B8TkjNrubmA6StzF2yl2c30 gLeLi4cktX2vCJGBi3ZXJC8vVhiakpEeT3Q0O4dX1EsczAPYVxcMz0JZANKldm284Ndj wi8HRuAzvK0C3BqyFhMdsXlblK9pb/TzDvFopEHEWz50TrWSIq2o06x5lB3fbgPHArgI 8rmfpApZ1rz+nMfUBzLSUXlTf4HLS7SHuw+b191b/2mmWeMJSHpPUMjVAoT0u44Rb29M cO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YUnVxa5pnWd8D3oQLkMmXCsz6an77MCtCR1yPtv/LsQ=; b=zEYPg+l2kavo2b4DHAHUVC6O4I24/v86uo3leAN4Mkzz80BLafZjwR1bagXxkrTl1T a4QSEYbklRLBFPIJskmIBIXVGdsMgGHnt5kBX0SUD5FXU4sTncxjJveQbCBb6Q1A36LS zIAH84dtMcUj9oLH9DVwfcw8dYx76ezqPcP4wN+XRhiLS7lLRDJjl4HbVSGAvcE2ZcSM f7KzeKVCm6CtBZCdMRb4oy13Xl1nmD7e99Zhpc+4AvPVMVfYXlakN+1CwP5hsH3bb/lZ 5cu9/2wSFMEleGsVqtehc5tEyFhuFxeV6eds1YFYzYd3sPhCfMrULyV6X803cUZ3vSIT neqA== X-Gm-Message-State: AOAM530U8LQHJcuaVHcuU+K3zAvXMwSsYLov3ug7kzydo3Rvb90oD25W xd0z7zr1OfpEp1Lz5dXaT15YxA== X-Google-Smtp-Source: ABdhPJzEzSBOJ49SjfPAIvrDv96S6UMkcFYGOSpHrtGFcUUoN1+ex5IU8zKRocw1wS2WuYmbveO09g== X-Received: by 2002:a63:4387:0:b0:3c6:9490:4e4b with SMTP id q129-20020a634387000000b003c694904e4bmr25290534pga.438.1653423754123; Tue, 24 May 2022 13:22:34 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h186-20020a62dec3000000b0050dc7628191sm9847289pfg.107.2022.05.24.13.22.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 13:22:33 -0700 (PDT) Date: Tue, 24 May 2022 20:22:30 +0000 From: Sean Christopherson To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Dave Hansen , Mel Gorman , Tom Lendacky , Rick Edgecombe , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , "Kirill A. Shutemov" , Tianyu Lan , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz, akpm@linux-foundation.org, willy@infradead.org Subject: Re: Is _PAGE_PROTNONE set only for user mappings? Message-ID: References: <20220506051940.156952-1-42.hyeyoo@gmail.com> <56f89895-601e-44c9-bda4-5fae6782e27e@amd.com> <5fe161cb-6c55-6c4d-c208-16c77e115d3f@amd.com> <8c2735ac-0335-6e2a-8341-8266d5d13c30@intel.com> <20220512103748.GH3441@techsingularity.net> <3f2f7c09-ddf3-6052-9860-8554a4ff2798@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: zcqiw3kgc6bro6a45e5s4stwh9jx6tbg X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="VSYu/Wzf"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of seanjc@google.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D9A8E2002F X-HE-Tag: 1653423720-876966 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 Sun, May 22, 2022, Hyeonggon Yoo wrote: > On Mon, May 16, 2022 at 07:04:32AM -0700, Dave Hansen wrote: > > I was thinking of something more along the lines of taking the > > set_memory.c code and ensuring that it never sets (or even observes) > > _PAGE_BIT_GLOBAL on a _PAGE_USER mapping. > > Yeah that would be a bit more explicit solution. > > > There was also a question of > > if set_memory.c is ever used on userspace mappings. It would be good to > > validate whether it's possible in-tree today and if not, enforce that > > _PAGE_USER PTEs should never even be observed with set_memory.c. > > Simply adding dump_stack() tells me my kernel on my machine does not use > set_memory.c for userspace mappings but Hmm I'll take a look. vc_slow_virt_to_phys() uses lookup_address_in_pgd() with user mappings, but that code is all but guaranteed to be buggy, e.g. doesn't guard against concurrent modifications to user mappings. show_fault_oops() can also call into lookup_address_in_pgd() with a user mapping, though at that point the kernel has bigger problems since it's executing from user memory. And up until commits 44187235cbcc ("KVM: x86/mmu: fix potential races when walking host page table") and 643d95aac59a ("Revert "x86/mm: Introduce lookup_address_in_mm()""), KVM had a similar bug. Generally speaking, set_memory.c is not equipped to play nice with user mappings. It mostly "works", but there are races galore. IMO, hardening set_memory.c to scream if it's handed a user address or encounters _PAGE_USER PTEs would be a very good thing.