Received: by 2002:a05:6500:1b45:b0:1f5:f2ab:c469 with SMTP id cz5csp847014lqb; Wed, 17 Apr 2024 12:28:27 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXrWBZp5OdSiSdBBp90KqRd+iEfHm5Mq3O8klS3Rl6TKgB4dEb72HvHhXI0sGmx8+aNAYOexjPhbxGkfqcOqFGp3OAmXBKls7Xjh/1KvA== X-Google-Smtp-Source: AGHT+IGZGSvoP+DHGNGZ+RV2wmKgAQAE/4KWFa0Pf4cZ/dxEEq9rAap1mh+LlEcoC+BrZTpCqB+9 X-Received: by 2002:a17:902:d68b:b0:1e3:e4ff:7054 with SMTP id v11-20020a170902d68b00b001e3e4ff7054mr457219ply.38.1713382107457; Wed, 17 Apr 2024 12:28:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713382107; cv=pass; d=google.com; s=arc-20160816; b=JI/kfriB0NIBEb0ZD4F7Ai+ZEfsAEh21+ENaJOJZMalfGzxBpdPC6Zi+Po9HXUpfUE mkxPiWg2Qd+/0GnhnUCzhNAQ2/edqyLq+1jLEod/i85n1O0d6BbphYP76LdYbkC7g9TF C91K2ARnMKosT3H0Z1M2EKgIaCqnTX62yUvhSGP5CSCTCSOzIm2gNihZ4ix8NqzdfR2R OMWnjZf5UcCjD/V0UKzHM1f8sW12L1xOnTYSdKFebuSCEYujULT+qlC1wgpb8eQmtR6u TE7zOmzVn2nqIMKiEJ73TFzuwxmxNBwhz72Cw2fXi34ZQs6SdyZIa6jUrFzqOLSN78aG Yn/Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=Ian3ROIXX/Wi51a3xW5sv9PCZzatN1IXxVDjvA9s1M0=; fh=mO/uDy+Hi4LnECOEJ4Epip7jKH8afEu3y8tARz5Ph4Q=; b=l8abJsvyt2ZJDqxD+v6VGKicQllPTI+JzvTWUZJGHk8+GUYi5/ML7Lxx0Qvgylwexy S16FdcwrQlmfCbMsU9efww3ZW7FD2H9zlLaoDPrzCajiHRsdd8swb9ZylufB71IlMOqO LJc9DUE3fmj822i3JzuERmZXteaFQEquteE0IxoTT681LB/LXLtVpP79l6uw5qSERJ3c RHACYr4EtMFSYqXAxs8jM4Z15kfciwLvw/QcG1tV6B/JkrfIoUUizO+Nmau1nzhTjdZz 6CQPLGKDfJ8QsPMN4HNdnqrqbDMbOQBGApPVIS+FdaQJEj+YChujqQckB/kpKbazs+4Q ftBQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="UTz/98JQ"; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-149119-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-149119-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id ay1-20020a1709028b8100b001e43e672bb4si11624556plb.544.2024.04.17.12.28.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Apr 2024 12:28:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-149119-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="UTz/98JQ"; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-149119-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-149119-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 37317B220B3 for ; Wed, 17 Apr 2024 19:27:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BA35C25760; Wed, 17 Apr 2024 19:26:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UTz/98JQ" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3965824B34 for ; Wed, 17 Apr 2024 19:26:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713382015; cv=none; b=SzMKphRXZ5b72SZkfiVa7PEjIAPwgfXiN2mBqWMw3PgngV1/TpSEo0weZ6eXT/oyUcs5Wfp1ClifT+7ocQI0ST/BvkmJFIZaSieslgJEB01WLXVUTPSn3ypbZEhWfAp4a9ygFgHqPJFQr1GO7Z/Qo94Yblr4oBvaR3hUlwy34bE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713382015; c=relaxed/simple; bh=Q5GqEMAnWtgXoPYRq6Bg4wUmdm4KD8bF3uxwjrIn0jA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ha3J7DiLei1LCQkRMJkC2AQs8KyBAAaM9Y906NxAj4gIlQPOVybbelvXVCenysLegq1oand7yKemBji/tVAOAgwKTv/mIgl/RBkX9oCODRnmD0NnEHfdAWNkDYfub+x6kXle6mxXII5688ZlNL3aFgMuQHZvHpgPxVTcQ6kE2qc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UTz/98JQ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713382009; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Ian3ROIXX/Wi51a3xW5sv9PCZzatN1IXxVDjvA9s1M0=; b=UTz/98JQxCUOPxg++QwVeaOFIJNsa6thcZ0Yxx5CE9WcRI5APZXJaqO961lDv93ILHwoKF Brue3T1APTZg8QI+ObUQbgbX1/ejpM+U69XawcB9NtR3hHVyg4kJ1vDtV+aCfPowYTaCJK R2tmG65+Po1nI+lF9VOVIo4DPG+O9j8= Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-542-SA992IC8MPqCLDiSahBGjg-1; Wed, 17 Apr 2024 15:26:47 -0400 X-MC-Unique: SA992IC8MPqCLDiSahBGjg-1 Received: by mail-oo1-f71.google.com with SMTP id 006d021491bc7-5aa68b37021so28326eaf.0 for ; Wed, 17 Apr 2024 12:26:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713382006; x=1713986806; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ian3ROIXX/Wi51a3xW5sv9PCZzatN1IXxVDjvA9s1M0=; b=CYY4hFfmgyHTTmospNuo5+ZYRjeHBC74pg/TWYmm6+2YhZOpxftNVYSDz8APqglBNN dnlIoNv+SgyGEnQSoAN3LhlLN3Yjt7P9hfZUDd616fiMN4CvGdDJlbGmDEff73nOyLW/ aa1zp9hfFC4jmO+scFrEau+rFip0KpmlqyPig+25w9wzN2zEvF/W2Tqa0gD6brSZaUGl QqGsv/j9FLZODI8xPBnAGoIYDiSs8hbkX/xyuMBKzbhp69erfo3iAvgVk/t8Je9nzC9Z +Ulu7y+wMK3c3POaXRGJNLF4OS9Cn0p1ikli14qG4uCAf5bIcrkDEG2XFSWOCgPch3mZ 1Vlw== X-Gm-Message-State: AOJu0Yxv/1O7V9CSPnXO5lJfbT9tO9s3NRxqGWShEfyIQAyltSjEp2cQ 7TM8ekUItjmy4DTZzO8p7dVf4Jet3Olx3rYV1EIcOygLYwkasXuWmG7QtvOAUPtR7xT3WOWLiRa u4dMOUXX5tawNBwB5k6WMrpC7zLjR5zezZXQ0th3Vdyi0oXjO8UnNbBprgGUIUwWbahT5LRs5BE 7VGO+SyaToMuYrOyicYJ7rlDd/LKl4SeDfE/vIyiZ2XUk= X-Received: by 2002:a05:6359:4589:b0:186:54b2:4141 with SMTP id no9-20020a056359458900b0018654b24141mr367576rwb.1.1713382005476; Wed, 17 Apr 2024 12:26:45 -0700 (PDT) X-Received: by 2002:a05:6359:4589:b0:186:54b2:4141 with SMTP id no9-20020a056359458900b0018654b24141mr367537rwb.1.1713382004772; Wed, 17 Apr 2024 12:26:44 -0700 (PDT) Received: from x1n.redhat.com (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id kd9-20020a056214400900b0069b42d51d3bsm8465915qvb.103.2024.04.17.12.26.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Apr 2024 12:26:44 -0700 (PDT) From: Peter Xu To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Nadav Amit , Axel Rasmussen , peterx@redhat.com, Pasha Tatashin Subject: [PATCH v3] mm/page_table_check: Support userfault wr-protect entries Date: Wed, 17 Apr 2024 15:26:43 -0400 Message-ID: <20240417192643.2671335-1-peterx@redhat.com> X-Mailer: git-send-email 2.44.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Allow page_table_check hooks to check over userfaultfd wr-protect criteria upon pgtable updates. The rule is no co-existance allowed for any writable flag against userfault wr-protect flag. This should be better than c2da319c2e, where we used to only sanitize such issues during a pgtable walk, but when hitting such issue we don't have a good chance to know where does that writable bit came from [1], so that even the pgtable walk exposes a kernel bug (which is still helpful on triaging) but not easy to track and debug. Now we switch to track the source. It's much easier too with the recent introduction of page table check. There are some limitations with using the page table check here for userfaultfd wr-protect purpose: - It is only enabled with explicit enablement of page table check configs and/or boot parameters, but should be good enough to track at least syzbot issues, as syzbot should enable PAGE_TABLE_CHECK[_ENFORCED] for x86 [1]. We used to have DEBUG_VM but it's now off for most distros, while distros also normally not enable PAGE_TABLE_CHECK[_ENFORCED], which is similar. - It conditionally works with the ptep_modify_prot API. It will be bypassed when e.g. XEN PV is enabled, however still work for most of the rest scenarios, which should be the common cases so should be good enough. - Hugetlb check is a bit hairy, as the page table check cannot identify hugetlb pte or normal pte via trapping at set_pte_at(), because of the current design where hugetlb maps every layers to pte_t... For example, the default set_huge_pte_at() can invoke set_pte_at() directly and lose the hugetlb context, treating it the same as a normal pte_t. So far it's fine because we have huge_pte_uffd_wp() always equals to pte_uffd_wp() as long as supported (x86 only). It'll be a bigger problem when we'll define _PAGE_UFFD_WP differently at various pgtable levels, because then one huge_pte_uffd_wp() per-arch will stop making sense first.. as of now we can leave this for later too. This patch also removes commit c2da319c2e altogether, as we have something better now. [1] https://lore.kernel.org/all/000000000000dce0530615c89210@google.com/ Cc: Pasha Tatashin Signed-off-by: Peter Xu --- v2: - Rename __page_table_check_pxx() to page_table_check_pxx_flags(), meanwhile move the pte check out of the loop [Pasha] - Fix build issues reported from the bot, also added SWP_DEVICE_WRITE which was overlooked before v3: - Add missing doc update [Pasha] --- Documentation/mm/page_table_check.rst | 9 ++++++- arch/x86/include/asm/pgtable.h | 18 +------------ mm/page_table_check.c | 39 +++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 18 deletions(-) diff --git a/Documentation/mm/page_table_check.rst b/Documentation/mm/page_table_check.rst index c12838ce6b8d..5bd1d987d76d 100644 --- a/Documentation/mm/page_table_check.rst +++ b/Documentation/mm/page_table_check.rst @@ -14,7 +14,7 @@ Page table check performs extra verifications at the time when new pages become accessible from the userspace by getting their page table entries (PTEs PMDs etc.) added into the table. -In case of detected corruption, the kernel is crashed. There is a small +In case of most detected corruption, the kernel is crashed. There is a small performance and memory overhead associated with the page table check. Therefore, it is disabled by default, but can be optionally enabled on systems where the extra hardening outweighs the performance costs. Also, because page table check @@ -22,6 +22,13 @@ is synchronous, it can help with debugging double map memory corruption issues, by crashing kernel at the time wrong mapping occurs instead of later which is often the case with memory corruptions bugs. +It can also be used to do page table entry checks over various flags, dump +warnings when illegal combinations of entry flags are detected. Currently, +userfaultfd is the only user of such to sanity check wr-protect bit against +any writable flags. Illegal flag combinations will not directly cause data +corruption in this case immediately, but that will cause read-only data to +be writable, causing data corrupt when the page content is later modified. + Double mapping detection logic ============================== diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 273f7557218c..65b8e5bb902c 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -388,23 +388,7 @@ static inline pte_t pte_wrprotect(pte_t pte) #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP static inline int pte_uffd_wp(pte_t pte) { - bool wp = pte_flags(pte) & _PAGE_UFFD_WP; - -#ifdef CONFIG_DEBUG_VM - /* - * Having write bit for wr-protect-marked present ptes is fatal, - * because it means the uffd-wp bit will be ignored and write will - * just go through. - * - * Use any chance of pgtable walking to verify this (e.g., when - * page swapped out or being migrated for all purposes). It means - * something is already wrong. Tell the admin even before the - * process crashes. We also nail it with wrong pgtable setup. - */ - WARN_ON_ONCE(wp && pte_write(pte)); -#endif - - return wp; + return pte_flags(pte) & _PAGE_UFFD_WP; } static inline pte_t pte_mkuffd_wp(pte_t pte) diff --git a/mm/page_table_check.c b/mm/page_table_check.c index af69c3c8f7c2..388bcf60d8b5 100644 --- a/mm/page_table_check.c +++ b/mm/page_table_check.c @@ -7,6 +7,8 @@ #include #include #include +#include +#include #undef pr_fmt #define pr_fmt(fmt) "page_table_check: " fmt @@ -182,6 +184,31 @@ void __page_table_check_pud_clear(struct mm_struct *mm, pud_t pud) } EXPORT_SYMBOL(__page_table_check_pud_clear); +/* Whether the swap entry cached writable information */ +static inline bool swap_cached_writable(swp_entry_t entry) +{ + unsigned type = swp_type(entry); + +#ifdef CONFIG_DEVICE_PRIVATE + if (type == SWP_DEVICE_EXCLUSIVE_WRITE || type == SWP_DEVICE_WRITE) + return true; +#endif +#ifdef CONFIG_MIGRATION + if (type == SWP_MIGRATION_WRITE) + return true; +#endif + + return false; +} + +static inline void page_table_check_pte_flags(pte_t pte) +{ + if (pte_present(pte) && pte_uffd_wp(pte)) + WARN_ON_ONCE(pte_write(pte)); + else if (is_swap_pte(pte) && pte_swp_uffd_wp(pte)) + WARN_ON_ONCE(swap_cached_writable(pte_to_swp_entry(pte))); +} + void __page_table_check_ptes_set(struct mm_struct *mm, pte_t *ptep, pte_t pte, unsigned int nr) { @@ -190,6 +217,8 @@ void __page_table_check_ptes_set(struct mm_struct *mm, pte_t *ptep, pte_t pte, if (&init_mm == mm) return; + page_table_check_pte_flags(pte); + for (i = 0; i < nr; i++) __page_table_check_pte_clear(mm, ptep_get(ptep + i)); if (pte_user_accessible_page(pte)) @@ -197,11 +226,21 @@ void __page_table_check_ptes_set(struct mm_struct *mm, pte_t *ptep, pte_t pte, } EXPORT_SYMBOL(__page_table_check_ptes_set); +static inline void page_table_check_pmd_flags(pmd_t pmd) +{ + if (pmd_present(pmd) && pmd_uffd_wp(pmd)) + WARN_ON_ONCE(pmd_write(pmd)); + else if (is_swap_pmd(pmd) && pmd_swp_uffd_wp(pmd)) + WARN_ON_ONCE(swap_cached_writable(pmd_to_swp_entry(pmd))); +} + void __page_table_check_pmd_set(struct mm_struct *mm, pmd_t *pmdp, pmd_t pmd) { if (&init_mm == mm) return; + page_table_check_pmd_flags(pmd); + __page_table_check_pmd_clear(mm, *pmdp); if (pmd_user_accessible_page(pmd)) { page_table_check_set(pmd_pfn(pmd), PMD_SIZE >> PAGE_SHIFT, -- 2.44.0