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 E2AE8C77B7D for ; Wed, 10 May 2023 16:40:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39C056B0074; Wed, 10 May 2023 12:40:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 325676B0075; Wed, 10 May 2023 12:40:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19F406B0078; Wed, 10 May 2023 12:40:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 05B336B0074 for ; Wed, 10 May 2023 12:40:41 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CDE991C701F for ; Wed, 10 May 2023 16:40:40 +0000 (UTC) X-FDA: 80774909040.13.A607560 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 39EB64001C for ; Wed, 10 May 2023 16:40:37 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="N16m6/dL"; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683736838; a=rsa-sha256; cv=none; b=7V+oaXk3d0uuOG34U54hiei8/g2fr0qy+RdrnSpFRlfJ6L5wlokRciJsfoqPXVogz6nMI4 9M7+hplm+EFh32LolOilaaTxmV6xcNcvXAc3b9uxvUNyUeZJZJxxwwlaGGeBJwK6ey6eWT WYK2w2XHOPdYbQ3FsSGlBfRjWTOkumc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="N16m6/dL"; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683736838; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8NY0JJIQROZci35Lv+keQEV1GDPb9b7mS9KRBzx8tN4=; b=hidVWvWUDgAq2/ZwrU/S4cqNx45WU01cBZIzW7rWHnKCIu/rm13eF9QFsg4K9w4lqxkXxP /98fI826UBgZvw1wzknWxTdEjiF/5eZhyPypIgrkfGA2MvV/nq+LZxbX/N0hDbzF21tklX 4/vIASXRDlokBZSnlI5uneNHxkwc4fI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683736837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8NY0JJIQROZci35Lv+keQEV1GDPb9b7mS9KRBzx8tN4=; b=N16m6/dLwAMiLQuzl2/Td3MiM0SpgptcGGU2HF0nDQWnKboVoG2bNcMX8zFJMEyI8Szjpo 1334KCIhhH/a9gmnRf0caD2xyoZHxZAtOy+7uYApS3rzldYvL5pbrw8nJKfmNC2GbG04bs QuBAiU9Fe5o1Ku6S8RzyTmNqeHJ0rzc= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-393-nv74_88SNu-GBewCOa0ZpA-1; Wed, 10 May 2023 12:40:34 -0400 X-MC-Unique: nv74_88SNu-GBewCOa0ZpA-1 Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-643fdfb437aso23739823b3a.0 for ; Wed, 10 May 2023 09:40:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683736833; x=1686328833; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8NY0JJIQROZci35Lv+keQEV1GDPb9b7mS9KRBzx8tN4=; b=UtynuDPniwO/25zvPmYDaJshUhaSAU7wKV6sgSJEJCNoQ2tYxpveY0bwODMVXr2LQe MSKGZ+bSShARiyidDJWlHy3v8PO3KO8T8OppUBWuD1RZlBQbbkJu3bMdK9PZinMc5bop rlHgcGHI9NcfEOY7lsv/II2k7FylvJkhaiUJDz3L/C9Rw3bxIFMWePN8eOA79brqtODE pA9KDRzTgWj/je1wxh9moafGoQ8ILT3BvICXu/C9cUFmZ1UN3scTAVXCjtAFvmvEl3pV fl5kEBZlkYpZSeaxs3Wf0iDrxPL1Bn81aFF+kaXhqkXP0k640sk1okOyuzc/XZTMxfS7 CTrg== X-Gm-Message-State: AC+VfDwLb51JzCdE7MG6bhVNZyfqeO4QTVuv4v6zQJEQtnMgPk7b9bFz 6eUV52jH5A9RIv0r//d16p5h2VSd0AEQNfPvbrOe2/Z+2NWXjrrSkSi7TKgL7SSNktzGRhFSnFS kKHFA3cSFTUs= X-Received: by 2002:a17:90b:1188:b0:250:32dc:3369 with SMTP id gk8-20020a17090b118800b0025032dc3369mr21521610pjb.15.1683736833000; Wed, 10 May 2023 09:40:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6KmVpd3q4EvAEWG9cN6AIc7RLq0o7jc4GG/UBzSx5JcKue7oCjZjly+TneE2m+hsmUGhCWgw== X-Received: by 2002:a17:90b:1188:b0:250:32dc:3369 with SMTP id gk8-20020a17090b118800b0025032dc3369mr21521590pjb.15.1683736832601; Wed, 10 May 2023 09:40:32 -0700 (PDT) Received: from ?IPV6:2001:4958:15a0:30:5835:5bd3:f0c8:e5ef? ([2001:4958:15a0:30:5835:5bd3:f0c8:e5ef]) by smtp.gmail.com with ESMTPSA id p19-20020a63f453000000b005287b22ea8esm3432907pgk.88.2023.05.10.09.40.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 09:40:32 -0700 (PDT) Message-ID: Date: Wed, 10 May 2023 18:40:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Ruihan Li , linux-mm@kvack.org Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Pasha Tatashin , Matthew Wilcox , Andrew Morton , Christoph Hellwig , Greg Kroah-Hartman , stable@vger.kernel.org References: <20230510085527.57953-1-lrh2000@pku.edu.cn> <20230510085527.57953-4-lrh2000@pku.edu.cn> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 3/4] mm: page_table_check: Make it dependent on !DEVMEM In-Reply-To: <20230510085527.57953-4-lrh2000@pku.edu.cn> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 4zp3whaoix797pcte7pwhm1ofimrngr4 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 39EB64001C X-HE-Tag: 1683736837-499506 X-HE-Meta: U2FsdGVkX18KZ1zgo6kSS/PZRC5iFNYO45DRii9HfA2ovCqgxKiaRsBNqyMfWfvPLWemRnEr9OHB/oSbaTadta9ink2P+wAFlYevk/nznFTTH79Mg4DzJbLz1uHJdU58qJq2s7Uh8zlsnLIz5PEm5qqaqG6QzEqdJlhSuy0h+Z7fKTRo1ls/1SzBGDfSjzqUZ9jBqqXVMPfLUQ4CrrOxTF7HFtPjKkI0grei3hkNNX4YIOuyHw8EhzE0Xnc/W2L0AHwAYbyrBgR/b8kFxne1ZwSBL37A1BOOjLaqkZRipdCT2W69W6WvhFmsSjW8rrhFJYAIvcKaBAzj2C75ivVLYvqankPrTNKCmcUNuXwdanPrjVR1IaYVZ8MN24fCxNMpa/BN366M2bzU8J3MH3Z8beyG/ssWryzTsgZDoBVo+vJV++YEJU90oEEB8egJ82d8NXW4+VXWbZHHOUsmckhWQbuwd86GdbTRRecD9UBaTFwumQNGjllhN5UTnOCnRCoy7UeIOYPNHQLhJqabvZV3Prb67vBD2b8jCq36W2XoK+hQK4+E0qL6JL8gYuj8thZVoX2ubQMLun9jbkdiG1oCkXDN4EX8nJe8WOmAfTqOwUCMdVSHq/EDnJcudq1S6E0VnOLgItNVDdNDF/KLDPSORZliKPdOeqJKYM9yjZr3/JSaONRTZrclQlwQcVGd4IGgiNdHj1UVzT1AyJ7f5nhMVph2cgmLAN+w+UW9INed6cdAKWRM0+6xBCg3N+BkvlJvDqdBlNhknlccnrrduZFFy8bND9N/lHpjcnPJH6kELmY9Q5wO60b7/9nRD7z6fROpzV0vz3YefqBF3txRSalDMU4WddpCCnEjJLnJoMSrcdCXZeMI+edTs19n7sg2z50OMEj3lRpEKACYnkZG35KKjx9TnNEQR3leBQhkZC6xH610mgAZOJdD4Z3d35M9TcSLiCScgdphp8hgYlsbs3r 7lkeb5Fq w6m48lwwko/GvA2znn6J5ro46u/miK1veXFDWF++uZ3W7SdGsXlZDq91tV7ceeVVMkYjaU+auSXPw+yAXUgJAN77AX4Na6t2longcgoJRx6yGWDs6xjY/wmPXPAjDSGFiO960Uw3NILbZ1KNuZj3IhErJ9sAYL+SEb4HmQCflCpm4O2LsioKCjki/4Im7Z8mqxf7V8Qtjaj7IcnxGF7Pn2/vCxqZEDpnyOeAq+fYPrUWK2RihNtrMu7u0pqF5uu4kbA8H9T1T2FSC8l27y6jobg5iaZzUK+TbssmRoFhkg8BWCYCsB8u9WXMalA9c8qZ4++Ojm9D/dQ4OX2dLChS6UUuLwslvAkcpOKqa87c1HbKj7iKkXPUgpZJm4Zw7UYm4BFT+6p5dFlZFeknywVwN3YUHaJI7DzlJfz3JtTzboHUoqmlJU56kKLCGedV0bCLg7EiYbp7RE6ids//O5cMzCAGGkJjse7Z8YdCh4G0ucqt+B0/3QkZvfIXI2F0vxtIQ+Hje/v4Dcwx3x5LByg4w8gBEjJnuYrMYfJLOZ5R96KzX25JYWMIZGYwOTg== 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 10.05.23 10:55, Ruihan Li wrote: > The special device /dev/mem enables users to map arbitrary physical > memory regions into the user space, which can conflict with the double > mapping detection logic used by the page table check. For instance, > pages may change their properties (e.g., from anonymous pages to named > pages) while they are still being mapped in the user space via /dev/mem, > leading to "corruption" detected by the page table check. > > To address this issue, the PAGE_TABLE_CHECK config option is now > dependent on !DEVMM. This ensures that the page table check cannot be > enabled when /dev/mem is used. It should be noted that /dev/mem itself > is a significant security issue, and its conflict with a hardening > technique is understandable. > > Cc: # 5.17 > Signed-off-by: Ruihan Li > --- > Documentation/mm/page_table_check.rst | 18 ++++++++++++++++++ > mm/Kconfig.debug | 2 +- > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/Documentation/mm/page_table_check.rst b/Documentation/mm/page_table_check.rst > index cfd8f4117..b04f29230 100644 > --- a/Documentation/mm/page_table_check.rst > +++ b/Documentation/mm/page_table_check.rst > @@ -52,3 +52,21 @@ Build kernel with: > > Optionally, build kernel with PAGE_TABLE_CHECK_ENFORCED in order to have page > table support without extra kernel parameter. > + > +Implementation notes > +==================== > + > +We specifically decided not to use VMA information in order to avoid relying on > +MM states (except for limited "struct page" info). The page table check is a > +separate from Linux-MM state machine that verifies that the user accessible > +pages are not falsely shared. > + > +As a result, special devices that violate the model cannot live with > +PAGE_TABLE_CHECK. Currently, /dev/mem is the only known example. Given it > +allows users to map arbitrary physical memory regions into the userspace, any > +pages may change their properties (e.g., from anonymous pages to named pages) > +while they are still being mapped in the userspace via /dev/mem, leading to > +"corruption" detected by the page table check. Therefore, the PAGE_TABLE_CHECK > +config option is now dependent on !DEVMEM. It's worth noting that /dev/mem > +itself is a significant security issue, and its conflict with a hardening > +technique is understandable. > diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug > index a925415b4..37f3d5b20 100644 > --- a/mm/Kconfig.debug > +++ b/mm/Kconfig.debug > @@ -97,7 +97,7 @@ config PAGE_OWNER > > config PAGE_TABLE_CHECK > bool "Check for invalid mappings in user page tables" > - depends on ARCH_SUPPORTS_PAGE_TABLE_CHECK > + depends on ARCH_SUPPORTS_PAGE_TABLE_CHECK && !DEVMEM > select PAGE_EXTENSION > help > Check that anonymous page is not being mapped twice with read write That might disable it in a lot of environments I'm afraid. I wonder if we could allow it for STRICT_DEVMEM. Hm ... -- Thanks, David / dhildenb