Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp2167182rwn; Fri, 9 Sep 2022 09:24:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR4oZFHWTkSfUl749vynnCVaaovMAK6aN+NadbdIvJJXZj0FjyJlv69swUVlUCAvPJYncctt X-Received: by 2002:a63:5549:0:b0:434:b9db:ba1 with SMTP id f9-20020a635549000000b00434b9db0ba1mr12728619pgm.89.1662740648997; Fri, 09 Sep 2022 09:24:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662740648; cv=none; d=google.com; s=arc-20160816; b=iXqrcOvbR7ZOeb15v9lg0BhObAMFj9oWqr3HWcLufqC/LdFEMj63BNSecbpf1yCjta zD1xBEBHhSPQbJbbQP5SYMB8/d58R21l5G6FYE1zZ9rzqfRL19eeWhs5DAEOklAjXPO9 psqcgK7z++ExxYTGGo0f2LZrTaLt8QOM/t5IYPSpISlQXFu6PoMuDetW0VC4/6/JtXp2 XOxIbK54GHcYtqvXMdoaPMBed1XAotJXvoSLL/AlfiMjj2hluIQOv34/GqrIa3DDJa8i qravs7EP88XMOeTAJ+DLNwbHubMC9tl+RKawCNtOSy3vV5DlxFzXrhaF2V0st4hCUrPB 0v2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=WiFj5B68EDqDa2lwf8qblTt1C7E/7pyuLWBRHXSvH7c=; b=qzZPnwYLAdNEVeerZ+amIosncsW+6z+EC2LkyNJpfVfs8g2TdsX47Zc8TTjMDmuo10 ZOX1EhAoyMp5oUU7DcTYP8dvkFp4ySM2lgWS9JPYTnIPMM0olD42gOAhTBDcfV9rzDGc FbW3kfAlhnlPVcZw+DA1jzY9e96UioTycq5w4YxE2oUPk6HTjLMTNFk6SzTR3q8MkeHG OUiUn9EBdorv7CFUSPw+Cm6tp8PnSuXGlY8zLZ1jFjy+vYZOmWAZNXUci6AQmyeHHdad 6OZlNQoDOf678wfP62WQRvx8QUxGsVHX7LbHg9SJ+vgunZjTdoEAQHtCDfir+LUWsEfx 3iDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RlcZfVp9; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e4-20020a630f04000000b00434efdb1c29si973011pgl.326.2022.09.09.09.23.56; Fri, 09 Sep 2022 09:24:08 -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 header.s=Intel header.b=RlcZfVp9; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231669AbiIIQID (ORCPT + 99 others); Fri, 9 Sep 2022 12:08:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbiIIQIB (ORCPT ); Fri, 9 Sep 2022 12:08:01 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D98E412B35D for ; Fri, 9 Sep 2022 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662739680; x=1694275680; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HLOCowi08irFEhmbasnUIkWwZGfyH3C0HY33bJ60MTk=; b=RlcZfVp9b+iaZlQHTGhwIcryNrHA0EV9lFd99ppCHtqiInGJoGI4o5h1 KxP5dDfAAhvWgqeacM9wmOo8tB0PdqOnLJXewCtY8ptJiSCEgtYrUqMwU uHX/O56qjIiR9TE/lZ+EXxFYCwF7HQ9hmalWh01/QzkplunSRDBGI0Mg7 DMaFV5R8vChv9xMnu2vbejngxAi2xHs14l9wUeR2XZljdA2N+0txFFez8 NopsHx+Uphc0uv+s9zoY2PW+Q6QlE/nftroHGCbEZMoOqvOcs4ETsMz88 1O6aXeirMP3Vk/jn05WoQlesuXVi7FOdH9lAtLjtMvAHHShQV0Fy010Zu A==; X-IronPort-AV: E=McAfee;i="6500,9779,10465"; a="383804133" X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="383804133" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2022 09:07:56 -0700 X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="683686842" Received: from araj-dh-work.jf.intel.com (HELO araj-dh-work) ([10.165.157.158]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2022 09:07:56 -0700 Date: Fri, 9 Sep 2022 16:08:02 +0000 From: Ashok Raj To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jacon Jun Pan , Ashok Raj Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Message-ID: References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com> <20220904003952.fheisiloilxh3mpo@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220904003952.fheisiloilxh3mpo@box.shutemov.name> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE 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 Sun, Sep 04, 2022 at 03:39:52AM +0300, Kirill A. Shutemov wrote: > On Thu, Sep 01, 2022 at 05:45:08PM +0000, Ashok Raj wrote: > > Hi Kirill, > > > > On Tue, Aug 30, 2022 at 04:00:53AM +0300, Kirill A. Shutemov wrote: > > > Linear Address Masking[1] (LAM) modifies the checking that is applied to > > > 64-bit linear addresses, allowing software to use of the untranslated > > > address bits for metadata. > > > > We discussed this internally, but didn't bubble up here. > > > > Given that we are working on enabling Shared Virtual Addressing (SVA) > > within the IOMMU. This permits user to share VA directly with the device, > > and the device can participate even in fixing page-faults and such. > > > > IOMMU enforces canonical addressing, since we are hijacking the top order > > bits for meta-data, it will fail sanity check and we would return a failure > > back to device on any page-faults from device. > > > > It also complicates how device TLB and ATS work, and needs some major > > improvements to detect device capability to accept tagged pointers, adjust > > the devtlb to act accordingly. > > > > > > Both are orthogonal features, but there is an intersection of both > > that are fundamentally incompatible. > > > > Its even more important, since an application might be using SVA under the > > cover provided by some library that's used without their knowledge. > > > > The path would be: > > > > 1. Ensure both LAM and SVM are incompatible by design, without major > > changes. > > - If LAM is enabled already and later SVM enabling is requested by > > user, that should fail. and Vice versa. > > - Provide an API to user to ask for opt-out. Now they know they > > must sanitize the pointers before sending to device, or the > > working set is already isolated and needs no work. > > The patch below implements something like this. It is PoC, build-tested only. > > To be honest, I hate it. It is clearly a layering violation. It feels > dirty. But I don't see any better way as we tie orthogonal features > together. > > Also I have no idea how to make forced PASID allocation if LAM enabled. > What the API has to look like? > > Any comments? Looking through it, it seems to be sane enough.. I feel dirty too :-) but don't see a better way. I'm Ccing JasonG since we are reworking the IOMMU interfaces right now, and Jacob who is in the middle of some refactoring. > > > 2. I suppose for any syscalls that take tagged pointers you would maybe > > relax checks for how many bits to ignore for canonicallity. This is > > required so user don't need to do the same for everything sanitization > > before every syscall. > > I'm not quite follow this. For syscalls that allow tagged pointers, we do > untagged_addr() now. Not sure what else needed. > > > If you have it fail, the library might choose a less optimal path if one is > > available. > > > > Cheers, > > Ashok > > diff --git a/arch/x86/include/uapi/asm/prctl.h b/arch/x86/include/uapi/asm/prctl.h > index a31e27b95b19..e5c04ced36c9 100644 > --- a/arch/x86/include/uapi/asm/prctl.h > +++ b/arch/x86/include/uapi/asm/prctl.h > @@ -23,5 +23,6 @@ > #define ARCH_GET_UNTAG_MASK 0x4001 > #define ARCH_ENABLE_TAGGED_ADDR 0x4002 > #define ARCH_GET_MAX_TAG_BITS 0x4003 > +#define ARCH_ENABLE_TAGGED_ADDR_FORCED 0x4004 > > #endif /* _ASM_X86_PRCTL_H */ > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > index 337f80a0862f..7d89a2fd1a55 100644 > --- a/arch/x86/kernel/process_64.c > +++ b/arch/x86/kernel/process_64.c > @@ -774,7 +774,8 @@ static bool lam_u48_allowed(void) > #define LAM_U48_BITS 15 > #define LAM_U57_BITS 6 > > -static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits) > +static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits, > + bool forced) > { > int ret = 0; > > @@ -793,6 +794,11 @@ static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits) > goto out; > } > > + if (pasid_valid(mm->pasid) && !forced) { > + ret = -EBUSY; > + goto out; > + } > + > if (!nr_bits) { > ret = -EINVAL; > goto out; > @@ -910,7 +916,9 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > return put_user(task->mm->context.untag_mask, > (unsigned long __user *)arg2); > case ARCH_ENABLE_TAGGED_ADDR: > - return prctl_enable_tagged_addr(task->mm, arg2); > + return prctl_enable_tagged_addr(task->mm, arg2, false); > + case ARCH_ENABLE_TAGGED_ADDR_FORCED: > + return prctl_enable_tagged_addr(task->mm, arg2, true); > case ARCH_GET_MAX_TAG_BITS: { > int nr_bits; > > diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c > index 106506143896..a6ec17de1937 100644 > --- a/drivers/iommu/iommu-sva-lib.c > +++ b/drivers/iommu/iommu-sva-lib.c > @@ -4,6 +4,7 @@ > */ > #include > #include > +#include > > #include "iommu-sva-lib.h" > > @@ -32,6 +33,15 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) > return -EINVAL; > > mutex_lock(&iommu_sva_lock); > + > + /* Serialize against LAM enabling */ > + mutex_lock(&mm->context.lock); > + > + if (mm_lam_cr3_mask(mm)) { > + ret = -EBUSY; > + goto out; > + } > + > /* Is a PASID already associated with this mm? */ > if (pasid_valid(mm->pasid)) { > if (mm->pasid < min || mm->pasid >= max) > @@ -45,6 +55,7 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max) > else > mm_pasid_set(mm, pasid); > out: > + mutex_unlock(&mm->context.lock); > mutex_unlock(&iommu_sva_lock); > return ret; > } > -- > Kiryl Shutsemau / Kirill A. Shutemov