Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3262745iob; Mon, 16 May 2022 17:30:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyExT7OoJr3VJelzXe1kGpyydI3TJNokEfzlZVz3dOijltUk4mGYF23DWrJ9f5pIQLz+8Rp X-Received: by 2002:a17:902:d4c1:b0:161:a444:cbb1 with SMTP id o1-20020a170902d4c100b00161a444cbb1mr1310285plg.142.1652747420843; Mon, 16 May 2022 17:30:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652747420; cv=none; d=google.com; s=arc-20160816; b=TqHVpxOdvjaK76i0RIs+HPsW8+km3yELBuQ+8ZIkO9y7iBzraSJ8//t5szzQtpbHhJ Dv9zP7cFYLHSVYPjxqJOiPKtsh/0xSeOd6pTxFEHym+xmy4DCa6I7mU5CB7clAy/Vwnf 86/1anrbavD8EwFEE/MYBnDM/uQH31t9RnRpsrRGxH7zSh+9oCJbD80e8dFPVcVk5Ves 8gW6WyPfwbD0BlEEi/qGzWRXB9mHAckSYxrZs8Tp2arrtEJ9Oha173ZrrIp3OF08LiIv PBc4cFzhrNRD9ZXcWC5W7ZcnWK8vONXN69jBWVzUQipKk/Vmf3rRaOJdHYCoX+0q+cIe Hg8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3ACVB3Y0E0YBB7tPTLWC9kOdJEJz9VBk49uvnZGm168=; b=wQa6EOsvGxbhklgtX048us8DLmF+HjVuk0siZq7m1MRSCuNiTrrJHOiejwGI0I4PV1 e9TVxQ3jRGOgfhCZqE+JnA9Q0rwmh1OKF6YoaeJefjmqQpo41AhDIvxeGF+h1i1x2CZv dJ68jywVuXHMvMqLtEY5SVjNe8WbXb78pfP4c6OdMZq6JRjDPjLjc0/si1FdZQ3ku2VE pX2uR0irrZsjOp7C6L79lmCyg1I+jDTGoEVBagPhuJ0VqOiTpj0+5/Z+GMKGqjkMwKdq I5PBiFzeRKcvS6aGIv8ZMNT2JAPBRl19yyhO/Ta+vZiCvX+vGhHmqv3d3t+Uo9icl3iQ j70A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=qGydRqSW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lp17-20020a17090b4a9100b001dc4e0e712asi1042051pjb.125.2022.05.16.17.30.09; Mon, 16 May 2022 17:30:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=qGydRqSW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343585AbiEPU45 (ORCPT + 99 others); Mon, 16 May 2022 16:56:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349016AbiEPU4T (ORCPT ); Mon, 16 May 2022 16:56:19 -0400 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EB69BB0 for ; Mon, 16 May 2022 13:30:43 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id 202so15115259pgc.9 for ; Mon, 16 May 2022 13:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ACVB3Y0E0YBB7tPTLWC9kOdJEJz9VBk49uvnZGm168=; b=qGydRqSWRmHEQXYWmP7xMI27DcIFY/huv3iAZeyWMrXsevjA/vluKjedm9wtt9X32P iUvChArCrzR4ORotZg6i6NqXMMeXQ5c0xG80tUiASZRn6cwEMkpCy+spDWjB/0AmYeSe 9y33tA/Zw1YcrbeOz3ij6n39xxkrUCu7fQYZvNDNJ/+7QTq/o47w94oCDPsvP/jLiIWq 3GgfFkC9tcKnoewv3pgIJX1LVvsI/MOFs1pIJziXrfIqYY38MkQGstWWozTQtPWcJbea TpOIcniKYiC3q8XlKKDX/TlRQRn6fsBB/qWp+q79LMsO+hn9bBhXZPy994JoFyC2Vfll gXTQ== 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=3ACVB3Y0E0YBB7tPTLWC9kOdJEJz9VBk49uvnZGm168=; b=gw5SGJh19Ilzon6UGpx68XPQLnOyp+labpz6cr8c7J2lLVxP/1CNhw+XLd7svDg2bf ZqU7AJf7d939XW/oBHz1DQNVF++GQ8Acus69tyMckFZGbnWlSBcWLV6QV6rr9T7CwvGA NBB+TCuww/2qJorzfR59GL4Dnw46pcawrYeoNeAvc2ehwvVX9vWHiIaTUbFUGyST6oK5 sJVdBc1OxzEnoX51YkTpgmRmZDz65cyOk5Act55lJOxttfPe9K2toICJ6vnH9ctq0KnW mrkpylNGGqua6tMF4ww6DT7bnILgpYIsS7yDZtON0vvXsNfF++CdS407KlOLnjpTZd4V cv0g== X-Gm-Message-State: AOAM533a99/3BKC9eqCmBlBkM+6eKXmLnaInyjB1N0mPyQKTpqQ9+Wf+ 3WhaWyEOEQbs/jJT+qvo4xTXWWLeosn2tfzVGh1ayw== X-Received: by 2002:a62:a105:0:b0:50d:c97b:3084 with SMTP id b5-20020a62a105000000b0050dc97b3084mr18768863pff.61.1652733042575; Mon, 16 May 2022 13:30:42 -0700 (PDT) MIME-Version: 1.0 References: <20220422224508.440670-1-jane.chu@oracle.com> <20220422224508.440670-3-jane.chu@oracle.com> In-Reply-To: <20220422224508.440670-3-jane.chu@oracle.com> From: Dan Williams Date: Mon, 16 May 2022 13:30:31 -0700 Message-ID: Subject: Re: [PATCH v9 2/7] x86/mce: relocate set{clear}_mce_nospec() functions To: Jane Chu Cc: Borislav Petkov , Christoph Hellwig , Dave Hansen , Peter Zijlstra , Andy Lutomirski , david , "Darrick J. Wong" , linux-fsdevel , Linux NVDIMM , Linux Kernel Mailing List , X86 ML , Vishal L Verma , Dave Jiang , Alasdair Kergon , Mike Snitzer , device-mapper development , "Weiny, Ira" , Matthew Wilcox , Vivek Goyal Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 22, 2022 at 3:46 PM Jane Chu wrote: > > Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c > file where they belong. > > While at it, fixup a function name in a comment. > > Reviewed-by: Christoph Hellwig > Reviewed-by: Dan Williams > Signed-off-by: Jane Chu > --- > arch/x86/include/asm/set_memory.h | 52 ------------------------------- > arch/x86/mm/pat/set_memory.c | 49 ++++++++++++++++++++++++++++- > include/linux/set_memory.h | 8 ++--- > 3 files changed, 52 insertions(+), 57 deletions(-) > > diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h > index 78ca53512486..b45c4d27fd46 100644 > --- a/arch/x86/include/asm/set_memory.h > +++ b/arch/x86/include/asm/set_memory.h > @@ -86,56 +86,4 @@ bool kernel_page_present(struct page *page); > > extern int kernel_set_to_readonly; > > -#ifdef CONFIG_X86_64 > -/* > - * Prevent speculative access to the page by either unmapping > - * it (if we do not require access to any part of the page) or > - * marking it uncacheable (if we want to try to retrieve data > - * from non-poisoned lines in the page). > - */ > -static inline int set_mce_nospec(unsigned long pfn, bool unmap) > -{ > - unsigned long decoy_addr; > - int rc; > - > - /* SGX pages are not in the 1:1 map */ > - if (arch_is_platform_page(pfn << PAGE_SHIFT)) > - return 0; > - /* > - * We would like to just call: > - * set_memory_XX((unsigned long)pfn_to_kaddr(pfn), 1); > - * but doing that would radically increase the odds of a > - * speculative access to the poison page because we'd have > - * the virtual address of the kernel 1:1 mapping sitting > - * around in registers. > - * Instead we get tricky. We create a non-canonical address > - * that looks just like the one we want, but has bit 63 flipped. > - * This relies on set_memory_XX() properly sanitizing any __pa() > - * results with __PHYSICAL_MASK or PTE_PFN_MASK. > - */ > - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63)); > - > - if (unmap) > - rc = set_memory_np(decoy_addr, 1); > - else > - rc = set_memory_uc(decoy_addr, 1); > - if (rc) > - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); > - return rc; > -} > -#define set_mce_nospec set_mce_nospec > - > -/* Restore full speculative operation to the pfn. */ > -static inline int clear_mce_nospec(unsigned long pfn) > -{ > - return set_memory_wb((unsigned long) pfn_to_kaddr(pfn), 1); > -} > -#define clear_mce_nospec clear_mce_nospec > -#else > -/* > - * Few people would run a 32-bit kernel on a machine that supports > - * recoverable errors because they have too much memory to boot 32-bit. > - */ > -#endif > - > #endif /* _ASM_X86_SET_MEMORY_H */ > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > index abf5ed76e4b7..978cf5bd2ab6 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -1816,7 +1816,7 @@ static inline int cpa_clear_pages_array(struct page **pages, int numpages, > } > > /* > - * _set_memory_prot is an internal helper for callers that have been passed > + * __set_memory_prot is an internal helper for callers that have been passed > * a pgprot_t value from upper layers and a reservation has already been taken. > * If you want to set the pgprot to a specific page protocol, use the > * set_memory_xx() functions. > @@ -1925,6 +1925,53 @@ int set_memory_wb(unsigned long addr, int numpages) > } > EXPORT_SYMBOL(set_memory_wb); > > +/* > + * Prevent speculative access to the page by either unmapping > + * it (if we do not require access to any part of the page) or > + * marking it uncacheable (if we want to try to retrieve data > + * from non-poisoned lines in the page). > + */ > +int set_mce_nospec(unsigned long pfn, bool unmap) > +{ > + unsigned long decoy_addr; > + int rc; > + > + if (!IS_ENABLED(CONFIG_64BIT)) > + return 0; > + > + /* SGX pages are not in the 1:1 map */ > + if (arch_is_platform_page(pfn << PAGE_SHIFT)) > + return 0; > + /* > + * We would like to just call: > + * set_memory_XX((unsigned long)pfn_to_kaddr(pfn), 1); > + * but doing that would radically increase the odds of a > + * speculative access to the poison page because we'd have > + * the virtual address of the kernel 1:1 mapping sitting > + * around in registers. > + * Instead we get tricky. We create a non-canonical address > + * that looks just like the one we want, but has bit 63 flipped. > + * This relies on set_memory_XX() properly sanitizing any __pa() > + * results with __PHYSICAL_MASK or PTE_PFN_MASK. > + */ > + decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63)); > + > + if (unmap) > + rc = set_memory_np(decoy_addr, 1); > + else > + rc = set_memory_uc(decoy_addr, 1); > + if (rc) > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); > + return rc; > +} > + > +/* Restore full speculative operation to the pfn. */ > +int clear_mce_nospec(unsigned long pfn) > +{ > + return set_memory_wb((unsigned long) pfn_to_kaddr(pfn), 1); > +} > +EXPORT_SYMBOL_GPL(clear_mce_nospec); > + > int set_memory_x(unsigned long addr, int numpages) > { > if (!(__supported_pte_mask & _PAGE_NX)) > diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h > index f36be5166c19..683a6c3f7179 100644 > --- a/include/linux/set_memory.h > +++ b/include/linux/set_memory.h > @@ -42,14 +42,14 @@ static inline bool can_set_direct_map(void) > #endif > #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */ > > -#ifndef set_mce_nospec > +#ifdef CONFIG_X86_64 Jane, I just noticed that this makes set_mce_nospec() and clear_mce_nospec() x86_64-only. If / when more architectures add support for these helpers they will need to go back to the "#ifndef $symbol" scheme to allow asm/set_memory.h to indicate the availability of the arch-local helper.