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 CDC60C433EF for ; Thu, 26 May 2022 10:33:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CADA8D0003; Thu, 26 May 2022 06:33:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2753F8D0002; Thu, 26 May 2022 06:33:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 117E88D0003; Thu, 26 May 2022 06:33:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 025C38D0002 for ; Thu, 26 May 2022 06:33:19 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id B8A8E60398 for ; Thu, 26 May 2022 10:33:19 +0000 (UTC) X-FDA: 79507532118.27.70B979B Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf14.hostedemail.com (Postfix) with ESMTP id 0CDC410000B for ; Thu, 26 May 2022 10:33:15 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id a15so768134ilq.12 for ; Thu, 26 May 2022 03:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zYDUOysOW0ZxZ/pfsRLXQW4yQ39IQOnULx1VRIJZPdo=; b=N/LR5YCzy58uRufBXx/aWg92n8BI0j3y/JIzrEoBhILNdzpUD9053jJbc8NN2RTWRB thf5zhN1x+LAma3cpGgYEWJDRmIRKr5nyY46GOYzGSVPwfjF9rS15r7X3bRcD8FSCwqN Hixf56AC0Z+2eH5X1WHJOb4RLh3YbWLVgBhlFzWdTxQ8AQBErDMXVdV1hKt6RLInw6vI 2RDVulbD6+1XN6XrmMH2iaxTpfOYKPhElIxCQXyRoGaUadXnOlYTgMIsK40zSfWN0RW5 eLWotul+rQdnKiBug/ahqkNqR6nFk4/B12gKxf+8Jr7GcRvidPVFMcMM47q6GPmzYsWL jrbQ== 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=zYDUOysOW0ZxZ/pfsRLXQW4yQ39IQOnULx1VRIJZPdo=; b=g2uRIk8l+eWSEpyrkM2LZQl2W9WlvCDU65ZqphBNaOtwwLxsh/RdSzZlh0V9X+EPZr wODg86PCo+RVO784HxhkPXfR56ycBkkmtfcKk6ymbuDPMfbjteYdINVFYxDR0ODhLUKm 1Azx7It7qJzkCa6HM/coNz2D/yOyQdx+Lo27uh9ek3mBw0GrM87pSbOVyr1DhulWPPcz DbgeiBfpTxsPk9SmriW8DrK8HCfCmMdP1yLBpHO7aPSxfQ94gxhNO0vblohrtEEAiSTt M4Qgav+4K+3L+sVLyglAhIzbLyWd4JZBI6rqnHvdEZiht1AyRw0NtoPZP6THsUYQYosG YkDA== X-Gm-Message-State: AOAM5308aLvOgCv6zsM7/pwd1anHUHuuBbRQpVkdtdDTV9/87liUwoYe gSNQXo7ygJ7R3F9X11ghR9k= X-Google-Smtp-Source: ABdhPJyEZz9amONlSBqu7a0QpuCWeDi3nHYdBY6SEYI6rg5t45axwsy2+zvSNI79Jc+2MuaNAmiRuw== X-Received: by 2002:a92:ca08:0:b0:2d1:c1ee:cde5 with SMTP id j8-20020a92ca08000000b002d1c1eecde5mr7368508ils.148.1653561198611; Thu, 26 May 2022 03:33:18 -0700 (PDT) Received: from n2.us-central1-a.c.spheric-algebra-350919.internal (151.16.70.34.bc.googleusercontent.com. [34.70.16.151]) by smtp.gmail.com with ESMTPSA id f13-20020a056638112d00b0032b5e4281d3sm314818jar.62.2022.05.26.03.33.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 May 2022 03:33:17 -0700 (PDT) Date: Thu, 26 May 2022 10:33:16 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Sean Christopherson 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: <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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0CDC410000B X-Stat-Signature: tz7zzix3jb9of4ydsgjgpha8znte9c8e X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="N/LR5YCz"; spf=pass (imf14.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.166.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1653561195-45629 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 Tue, May 24, 2022 at 08:22:30PM +0000, Sean Christopherson wrote: > 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. Thanks for your helpful insight. I was curious if set_memory*() helpers are used for user mappings. with some quick look ptrace() and uprobes (where updating application's text is needed) use kmap + memcpy or replace_page() instead of set_memory*() API. _lookup_address_cpa() uses init_mm.pgd when cpa.pgd is not specified and the only place that passes pgd is efi subsystem (efi_mm.pgd), which is not a userspace. So it is *obvious* that set_memory*() functions should not be used for user mappings. because that will only result in updating only init_mm's page table. Therefore answering to the first question ('do we really need to unset _PAGE_GLOBAL when we're clearing _PAGE_PRESENT in set_memory.c to avoid confusing it as _PAGE_PROTNONE?'): we don't need to consider PROT_NONE semantics in set_memory.c because we don't (shouldn't) change user mappings in it and _PAGE_PROTNONE is not used for kernel mappings. > 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. I agree that would be a good thing too. Thanks, Hyeonggon