Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2450272pxb; Mon, 23 Aug 2021 22:36:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0//0zXHo7njwHs/lY0IBeZV1aPCCN9KWm/3W9h+KFlJVDYvutTPV9QtTdlagUfBmn/Y/v X-Received: by 2002:aa7:d147:: with SMTP id r7mr41001578edo.148.1629783388550; Mon, 23 Aug 2021 22:36:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629783388; cv=none; d=google.com; s=arc-20160816; b=KzuWVfhUP4tF6Rm22xDnp9xB45trstihKF9YmX3tTlOB0AKaAOCQIhj47UK7SV2/0q urvSzt0qlrtKQwRV9sUVo/W5KsUP5gPsISFlS00cPRes3Uq6yGx+2FMCN7IUIEMDgFGW N7D2S4krgBheQw5+vW992ugEc4nriSuY1rEPs2bnRNGvO8PcdlzAQZu7zcjPziOTOkv0 4X9bGiLfhlijthuJN5tGWg5QgMrpm8JAtXWmqKhYvTVdqCp0jj9EJrGcx7hfE/s4fWCe s5pNGWBrWH7+jM6aPbYaRqGU+NltvACilSG2U7rXz+DgXlnKCUKUJt/icv1QYkDYBT7O WtOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=UfCl+JVoy2R6wx1DytMRudnKiR+tf7eTN7VTJ9Bq3Do=; b=sqoCUsqbQ/s2krcF6rH1l1oelsK1SrWqp2t6GB8Ys8NQ3KKogMfBuSQz9P8yRxLNei EaIkK7yonc8Ecjxu6o9nyfemFwJ96hNuLw6zfa2hO7m0Rwg/GDVSdgmRk+I2dnXm+opr 7Hjd+ZaR1gbCVeajV9tThnyHg+7lDgE4ICNsp3pULI9fB7DVKRqav8Tr88Tv1NwN7ZfR jh/eMX6Z9eIm54GB3p8WYHdlICcs7ooRMRyPpOVze2tTOI2o23Rv3xnLslHqqNuQDKg6 ZvQmYqk/ftpa86dyhsePUpR8meBZxMk6IkS4l39YSF/6lnfN2L4WGQUJcEllm73qQtMg b97w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iJ6vYi02; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b64si3107854edf.145.2021.08.23.22.36.05; Mon, 23 Aug 2021 22:36:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iJ6vYi02; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232103AbhHXFfa (ORCPT + 99 others); Tue, 24 Aug 2021 01:35:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229885AbhHXFf3 (ORCPT ); Tue, 24 Aug 2021 01:35:29 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03262C061575 for ; Mon, 23 Aug 2021 22:34:46 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id b9so7169410plx.2 for ; Mon, 23 Aug 2021 22:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UfCl+JVoy2R6wx1DytMRudnKiR+tf7eTN7VTJ9Bq3Do=; b=iJ6vYi02LKmh06hrXbT039cxyLX8yY1I6/pHi1hIhvNnlB0iJjISto9DzYva66j7F6 e5Mldrh5f4E3u8683DUqv4l9i2zgRgStG7aR0Xan7+diGdFbEpeR2KikG19BcoOModaz 6dCD1OxXO3VzkgBPs2r/9aepDrXthlGSKhJHZaIfoKGiJMPiDyMs+UKG1aFu2tpftFel XjvQcDpDvgCqczHc07qT7wz7fqyAnBWJFvZHwb2odJeB/7DfxGIhk3U8e/E+HSMDr765 wY8L554qfVDe3lsjmRZKaznT4yulCMOcvTBb7oN4Q0Myn93Gq994EmOTDjhRjfIyxgUF uiqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UfCl+JVoy2R6wx1DytMRudnKiR+tf7eTN7VTJ9Bq3Do=; b=GhPbvOzZ4HbxPulQmKInZCqQR4nUEHubPlEXeBWymiSFs1isNDlgWOz93TFru4/xkf LDGpEUgbWfjxmt7zssoI0NtYsceRNWsL4VVIqR6LYp9oCTiQI1OulYHBznp87dLGMd/0 aPdMweicABxHlUPpUD0PNH7woNDszEsQrYfOHO0ZoSK7xI5s/lDS2Eup63ey40VZwO/+ NnhhEx6GF3xdzisqHB9wprXFwD7c3x0TNvvE2ZNggKrDVXim5nzeCPEAG3f21MITA0HW k/L4cJ0tImpPbOX5nYL3rhEY6AWGHmlZsjVdbUImSAHMJWtI3CQhdFmWghBmB46Mrg48 1Oxg== X-Gm-Message-State: AOAM533s+RkosnxNLbULGtNDAKU4BNKDB0gO5Adjpx5v95r1x/ANEmKi F3OqBVpaZZqRBPG4/XvVjNA= X-Received: by 2002:a17:90a:ba93:: with SMTP id t19mr2610287pjr.4.1629783285412; Mon, 23 Aug 2021 22:34:45 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id p24sm2546774pfh.136.2021.08.23.22.34.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 22:34:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [RFC PATCH 4/4] x86/mm: write protect (most) page tables From: Nadav Amit In-Reply-To: Date: Mon, 23 Aug 2021 22:34:42 -0700 Cc: Linux-MM , Andrew Morton , Andy Lutomirski , Dave Hansen , Ira Weiny , Kees Cook , Mike Rapoport , Peter Zijlstra , Rick Edgecombe , Vlastimil Babka , x86@kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 7bit Message-Id: <05242256-4B5F-4AD6-B7DA-46A583335E5C@gmail.com> References: <20210823132513.15836-1-rppt@kernel.org> <20210823132513.15836-5-rppt@kernel.org> To: Mike Rapoport X-Mailer: Apple Mail (2.3654.120.0.1.13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry for sending twice. The mail app decided to use HTML for some reason. On Aug 23, 2021, at 10:32 PM, Nadav Amit wrote: > > On Aug 23, 2021, at 6:25 AM, Mike Rapoport wrote: > > From: Mike Rapoport > > Allocate page table using __GFP_PTE_MAPPED so that they will have 4K PTEs > in the direct map. This allows to switch _PAGE_RW bit each time a page > table page needs to be made writable or read-only. > > The writability of the page tables is toggled only in the lowest level page > table modifiction functions and immediately switched off. > > The page tables created early in the boot (including the direct map page > table) are not write protected. > > [ snip ] > +static void pgtable_write_set(void *pg_table, bool set) > +{ > + int level = 0; > + pte_t *pte; > + > + /* > + * Skip the page tables allocated from pgt_buf break area and from > + * memblock > + */ > + if (!after_bootmem) > + return; > + if (!PageTable(virt_to_page(pg_table))) > + return; > + > + pte = lookup_address((unsigned long)pg_table, &level); > + if (!pte || level != PG_LEVEL_4K) > + return; > + > + if (set) { > + if (pte_write(*pte)) > + return; > + > + WRITE_ONCE(*pte, pte_mkwrite(*pte)); I think that the pte_write() test (and the following one) might hide latent bugs. Either you know whether the PTE is write-protected or you need to protect against nested/concurrent calls to pgtable_write_set() by disabling preemption/IRQs. Otherwise, you risk in having someone else write-protecting the PTE after it is write-unprotected and before it is written - causing a crash, or write-unprotecting it after it is protected - which circumvents the protection. Therefore, I would think that instead you should have: VM_BUG_ON(pte_write(*pte)); // (or WARN_ON_ONCE()) In addition, if there are assumptions on the preemptability of the code, it would be nice to have some assertions. I think that the code assumes that all calls to pgtable_write_set() are done while holding the page-table lock. If that is the case, perhaps adding some lockdep assertion would also help to confirm the correctness. [ I put aside the lack of TLB flushes, which make the whole matter of delivered protection questionable. I presume that once PKS is used, this is not an issue. ]