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 83172C433F5 for ; Wed, 20 Apr 2022 17:09:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDBFB6B0071; Wed, 20 Apr 2022 13:09:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8BF46B0073; Wed, 20 Apr 2022 13:09:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2B646B0074; Wed, 20 Apr 2022 13:09:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id C3BC56B0071 for ; Wed, 20 Apr 2022 13:09:28 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 96DC326388 for ; Wed, 20 Apr 2022 17:09:28 +0000 (UTC) X-FDA: 79377893616.22.22C3281 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf27.hostedemail.com (Postfix) with ESMTP id 4DD6840018 for ; Wed, 20 Apr 2022 17:09:27 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id t11so4809214eju.13 for ; Wed, 20 Apr 2022 10:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AAgH39aqYNkZFEmodz4sdJEW8mfR6G5OOFNZA9oagFY=; b=Qakj4tsgGstygvOiA9O5uUiBRICg8fcpw/1UHUJrVZbFOhFCY0TdFI1pvox2kHpZgH JSzFyfkKv3KQLl1eyfhgd31h1VFGLKj9W2N5FNE4Kcj9UoxMgvXJLLBEqqVzwmdYbd9K AGPuZhTJW91gSkIGkaT46ezQqI3t2yyIfZUpbYiYay9oonrQOZgK7DTxYF1Ei0q0eyvt JHMswMR1rslz6HHA4TrJgDw2A5tzuAcJZt+1E2kCRnEIojalj0MUOYBF9ZlGDB3lvFnh FZrlwygxooC5bPWiA5moln7z2YrRO/koHDOPaG3aph3BreOUNXqGGpDm3CAjBhODORn0 cxEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AAgH39aqYNkZFEmodz4sdJEW8mfR6G5OOFNZA9oagFY=; b=dB1gsiahjw4oeu1ttT1jJspKEqwLBT+t4R4oDPib1PLEyP4xm0qgTW7yxAXHIkUMq8 5BVof26dJrM415cNSNnVXHE7yRq2CLx7Y6ylWZjkbMXrlq77VfASFp1MbTdBXqD8psS1 otLeRqz/phnim3UXT7TSCB+rO4E9N2qSFUzuRQskor1qSW0SoArHuF7Y6HXaadt9W10p CTRkU5NUUXLGrdp5Q9Ci1IejixLzNIQ2BB2BxoXN6k1G7e/vBCKidXor6r6mJ0KcDs4k BD8aFQOivKKM9cI/qOgsp593rd0Q8uO5Wsuiji3czAIK/qFXuUZW56s96SE6G1qJ2yW5 E7FQ== X-Gm-Message-State: AOAM533a1T2W00UT3PDprdvn8LPCLmwTBb6aZ4manP+I0HZYwzKfA6mT 1rsOxzoCUJ4jHlik6JUC6iKsdkpQTGFEvluIrRULmw== X-Google-Smtp-Source: ABdhPJyY9jAsgVicM8NGt7TWLzng0j4SkCK0Eh+NgNRIs5YdqcuU/etlcZJHfeXkYbVjr1I5apItKjFwDo3ZegsFvbI= X-Received: by 2002:a17:906:4cd8:b0:6db:372:c4ba with SMTP id q24-20020a1709064cd800b006db0372c4bamr18923831ejt.57.1650474566609; Wed, 20 Apr 2022 10:09:26 -0700 (PDT) MIME-Version: 1.0 References: <20220418034444.520928-1-tongtiangen@huawei.com> <20220418034444.520928-4-tongtiangen@huawei.com> <073cb6a6-3dbc-75d4-dbfe-a5299a6b0510@arm.com> <16a2620e-986a-6a8f-24eb-d0f7e9c91f24@arm.com> In-Reply-To: <16a2620e-986a-6a8f-24eb-d0f7e9c91f24@arm.com> From: Pasha Tatashin Date: Wed, 20 Apr 2022 13:08:50 -0400 Message-ID: Subject: Re: [PATCH -next v4 3/4] arm64: mm: add support for page table check To: Anshuman Khandual Cc: Tong Tiangen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Andrew Morton , Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , LKML , linux-mm , Linux ARM , linux-riscv@lists.infradead.org, Kefeng Wang , Guohanjun Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=Qakj4tsg; dmarc=none; spf=pass (imf27.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4DD6840018 X-Stat-Signature: wzeqqg5aszrxg4uw35kxaepichee6a5t X-HE-Tag: 1650474567-876753 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 Wed, Apr 20, 2022 at 1:05 AM Anshuman Khandual wrote: > > > > On 4/19/22 18:49, Pasha Tatashin wrote: > > On Tue, Apr 19, 2022 at 6:22 AM Anshuman Khandual > > wrote: > >> > >> > >> On 4/18/22 09:14, Tong Tiangen wrote: > >>> +#ifdef CONFIG_PAGE_TABLE_CHECK > >>> +static inline bool pte_user_accessible_page(pte_t pte) > >>> +{ > >>> + return pte_present(pte) && (pte_user(pte) || pte_user_exec(pte)); > >>> +} > >>> + > >>> +static inline bool pmd_user_accessible_page(pmd_t pmd) > >>> +{ > >>> + return pmd_present(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); > >>> +} > >>> + > >>> +static inline bool pud_user_accessible_page(pud_t pud) > >>> +{ > >>> + return pud_present(pud) && pud_user(pud); > >>> +} > >>> +#endif > >> Wondering why check for these page table entry states when init_mm > >> has already being excluded ? Should not user page tables be checked > >> for in entirety for all updates ? what is the rationale for filtering > >> out only pxx_user_access_page entries ? > > > > The point is to prevent false sharing and memory corruption issues. > > The idea of PTC to be simple and relatively independent from the MM > > state machine that catches invalid page sharing. I.e. if an R/W anon > > Right, this mechanism here is truly interdependent validation, which is > orthogonal to other MM states. Although I was curious, if mm_struct is > not 'init_mm', what percentage of its total page table mapped entries > will be user accessible ? These new helpers only filter out entries that > could potentially create false sharing leading upto memory corruption ? Yes, the intention is to filter out the false sharing scenarios. Allows crashing the system prior to memory corruption or memory leaking. > > I am wondering if there is any other way such filtering could have been > applied without adding all these new page table helpers just for page > table check purpose. > > > page is accessible by user land, that page can never be mapped into > > another process (internally shared anons are treated as named > > mappings). > > Right. > > > > > Therefore, we try not to rely on MM states, and ensure that when a > > page-table entry is accessible by user it meets the required > > assumptions: no false sharing, etc. > > Right, filtering reduces the page table entries that needs interception > during update (set/clear), but was just curious is there another way of > doing it, without adding page table check specific helpers on platforms > subscribing PAGE_TABLE_CHECK ? > It makes sense to limit the scope of PTC only to user accessible pages, and not try to catch other bugs. This keeps it reasonably small, and also lowers runtime overhead so it can be used in production as well. IMO the extra helpers are not very intrusive, and generic enough that in the future might be used elsewhere as well. > > > > For example, one bug that was caught with PTC was where a driver on an > > unload would put memory on a freelist but memory is still mapped in > > user page table. > > Should not page's refcount (that it is being used else where) prevented > releases into free list ? But page table check here might just detect > such scenarios even before page gets released. Usually yes. However, there are a number of recent bugs related to refcount [1][2][3]. This is why we need a stronger checker. The particular bug, however, did not rely on refcount. The driver allocated a kernel page for a ringbuffer, upon request shared it with a userspace by mapping it into the user address space, and later when the driver was unloaded, it never removed the mapping from the user address space. Thus, even though the page was freed when the driver was unloaded, the mapping stayed in the user page table. [1] https://lore.kernel.org/all/xr9335nxwc5y.fsf@gthelen2.svl.corp.google.com [2] https://lore.kernel.org/all/1582661774-30925-2-git-send-email-akaher@vmware.com [3] https://lore.kernel.org/all/20210622021423.154662-3-mike.kravetz@oracle.com