Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1945323rwb; Mon, 7 Nov 2022 07:30:10 -0800 (PST) X-Google-Smtp-Source: AMsMyM4GCCYZppYuH9FUgLXyvMlvw5vKYhRO9JyYfSzN0hSV72rjQAhqbvPTkzeV9GIwp3qsyf5X X-Received: by 2002:a63:5fd6:0:b0:46f:fdc1:4086 with SMTP id t205-20020a635fd6000000b0046ffdc14086mr28281705pgb.154.1667835010380; Mon, 07 Nov 2022 07:30:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667835010; cv=none; d=google.com; s=arc-20160816; b=DPDqlo7DhQEJez1grNA+t2gm6/h2VUMRNz1gJvbxfHQAv4SVIHC19z6fgUkzhNek32 j9RE+c0xHMqG43T5hvOnBOMkNi0tgd4J0dJzKvl3u6XISybBzv1iVEz6pjekwv39J0gF lC0AerrvRWJA1cDy7REW2BDl2VWItov2hOHKXygYDgZrj7vziO0FCO4XuJ2YXiBBuR3q 6lN/J70AfSpwMKHujzRLKDnSvjp2G/VgokwFzUnoL/MO8OBBZF8Q/KnTL7DA7Kt5/egY wVhZTS21UNSQ77fas93HXN4R9fseI8V3g3rNSmkrefPL6/AG7fiigDI72QXeKs/QNz6s igqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=dF7JPGaNeMuPH6wJXQ7t82Ybiq8JSa1ne5G/OzypJsk=; b=IIRHmSz0Ejq+F4N7P3vUWsslhr77huuA1BlpbeU2gDsZk6I1T7d24gS9X5ZvIL5k6x MEItUgdOg9/2tXia3GpDRhjw/aV2TmjWqciL4NoKzEGF/t1hKXmsG45QafEwf/h/P8mO OR6ReHoCPm2sIYY34EvuxnNDc1JZe4dRZkLVnI41D2fARiMVynYIuSvMMFUpIWFLebMN 97N+NiCYkDgnXWJe0PLihpiymdBwsWC8FHQyomx6ZME6U/D9YqviDgw79kDEoXIQLdaH vqYsvFOXT1e5iflhiEa4IRYZuC5M92AC5KhmsBHx5wbNafMp2I94rRV7UrtVcOaqQbrG 8ebA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YgzYQ13J; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d9-20020a631d09000000b004614aa5f31csi9960507pgd.255.2022.11.07.07.29.58; Mon, 07 Nov 2022 07:30:10 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=YgzYQ13J; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232402AbiKGOvK (ORCPT + 92 others); Mon, 7 Nov 2022 09:51:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232222AbiKGOvI (ORCPT ); Mon, 7 Nov 2022 09:51:08 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7554C1BEB9 for ; Mon, 7 Nov 2022 06:51:06 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2415AB81217 for ; Mon, 7 Nov 2022 14:51:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D361EC433D7; Mon, 7 Nov 2022 14:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667832663; bh=RQF6DcpueeAn/U7ivkg2nCuDs++5yALpTWm0b1zzxGc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YgzYQ13JxuI90RZ1M7xc3VnCQqQN/crcFmQjiJeYd1Fw8obFllxKSq7FZh8RqXZ52 ygxmgve4PxQGecUVubnOQGZAhe/ei6FiT6j0ibRtvFy5DjxVF8gbv3cVjj0b9y9Rvd LLCpuGlDY8LIs74sHC44ywd9vzfdmdIB4dQz7t86Cnbq7rI7HvewqeTzFYiNb2mKAj JLelAQYvs29pe3Bi75zxDZqR5DDcDoFYX8gWYs2M8258mVgVkRvhQ4gpGR6vAIDpN9 l1UwFUgYeS60XMuVO5gFHpcROcKYUV8fVWKCB7T5Xmk8zcfCSkGVpUSYn45cJqJF0f 1D4+t202ieTvw== Message-ID: Date: Mon, 7 Nov 2022 06:50:51 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCHv11 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check Content-Language: en-US To: "Kirill A. Shutemov" , Dave Hansen , Peter Zijlstra Cc: x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Bharata B Rao , Jacob Pan , Ashok Raj , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20221025001722.17466-1-kirill.shutemov@linux.intel.com> <20221025001722.17466-6-kirill.shutemov@linux.intel.com> From: Andy Lutomirski In-Reply-To: <20221025001722.17466-6-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 10/24/22 17:17, Kirill A. Shutemov wrote: > untagged_addr() is a helper used by the core-mm to strip tag bits and > get the address to the canonical shape. In only handles userspace > addresses. The untagging mask is stored in mmu_context and will be set > on enabling LAM for the process. > > The tags must not be included into check whether it's okay to access the > userspace address. > > Strip tags in access_ok(). > > get_user() and put_user() don't use access_ok(), but check access > against TASK_SIZE directly in assembly. Strip tags, before calling into > the assembly helper. > > Signed-off-by: Kirill A. Shutemov > Tested-by: Alexander Potapenko > Acked-by: Peter Zijlstra (Intel) > --- > arch/x86/include/asm/mmu.h | 3 +++ > arch/x86/include/asm/mmu_context.h | 11 ++++++++ > arch/x86/include/asm/uaccess.h | 42 +++++++++++++++++++++++++++--- > arch/x86/kernel/process.c | 3 +++ > 4 files changed, 56 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h > index 002889ca8978..2fdb390040b5 100644 > --- a/arch/x86/include/asm/mmu.h > +++ b/arch/x86/include/asm/mmu.h > @@ -43,6 +43,9 @@ typedef struct { > > /* Active LAM mode: X86_CR3_LAM_U48 or X86_CR3_LAM_U57 or 0 (disabled) */ > unsigned long lam_cr3_mask; > + > + /* Significant bits of the virtual address. Excludes tag bits. */ > + u64 untag_mask; > #endif > > struct mutex lock; > diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h > index 69c943b2ae90..5bd3d46685dc 100644 > --- a/arch/x86/include/asm/mmu_context.h > +++ b/arch/x86/include/asm/mmu_context.h > @@ -100,6 +100,12 @@ static inline unsigned long mm_lam_cr3_mask(struct mm_struct *mm) > static inline void dup_lam(struct mm_struct *oldmm, struct mm_struct *mm) > { > mm->context.lam_cr3_mask = oldmm->context.lam_cr3_mask; > + mm->context.untag_mask = oldmm->context.untag_mask; > +} > + > +static inline void mm_reset_untag_mask(struct mm_struct *mm) > +{ > + mm->context.untag_mask = -1UL; > } > > #else > @@ -112,6 +118,10 @@ static inline unsigned long mm_lam_cr3_mask(struct mm_struct *mm) > static inline void dup_lam(struct mm_struct *oldmm, struct mm_struct *mm) > { > } > + > +static inline void mm_reset_untag_mask(struct mm_struct *mm) > +{ > +} > #endif > > #define enter_lazy_tlb enter_lazy_tlb > @@ -138,6 +148,7 @@ static inline int init_new_context(struct task_struct *tsk, > mm->context.execute_only_pkey = -1; > } > #endif > + mm_reset_untag_mask(mm); > init_new_context_ldt(mm); > return 0; > } > diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h > index 8bc614cfe21b..c6062c07ccd2 100644 > --- a/arch/x86/include/asm/uaccess.h > +++ b/arch/x86/include/asm/uaccess.h > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -21,6 +22,30 @@ static inline bool pagefault_disabled(void); > # define WARN_ON_IN_IRQ() > #endif > > +#ifdef CONFIG_X86_64 > +/* > + * Mask out tag bits from the address. > + * > + * Magic with the 'sign' allows to untag userspace pointer without any branches > + * while leaving kernel addresses intact. > + */ > +#define untagged_addr(mm, addr) ({ \ > + u64 __addr = (__force u64)(addr); \ > + s64 sign = (s64)__addr >> 63; \ > + __addr &= (mm)->context.untag_mask | sign; \ > + (__force __typeof__(addr))__addr; \ > +}) > + I think this implementation is correct, but I'm wondering if there are any callers of untagged_addr that actually need to preserve kernel addresses. Are there? (There certainly *were* back when we had set_fs().) I'm also mildly uneasy about a potential edge case. Naively, one would expect: untagged_addr(current->mm, addr) + size == untagged_addr(current->mm, addr + size) at least for an address that is valid enough to be potentially dereferenced. This isn't true any more for size that overflows into the tag bit range. I *think* we're okay though -- __access_ok requires that addr <= limit - size, so any range that overflows into tag bits will be rejected even if the entire range consists of valid (tagged) user addresses. So: Acked-by: Andy Lutomirski