From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58469ECAAA1 for ; Fri, 9 Sep 2022 16:08:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96EEA6B0071; Fri, 9 Sep 2022 12:07:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91E5D6B0072; Fri, 9 Sep 2022 12:07:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E63B8D0001; Fri, 9 Sep 2022 12:07:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 702546B0071 for ; Fri, 9 Sep 2022 12:07:59 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2AE63160E1D for ; Fri, 9 Sep 2022 16:07:59 +0000 (UTC) X-FDA: 79893028278.22.64C0134 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf17.hostedemail.com (Postfix) with ESMTP id 44FC040082 for ; Fri, 9 Sep 2022 16:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662739678; x=1694275678; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HLOCowi08irFEhmbasnUIkWwZGfyH3C0HY33bJ60MTk=; b=kWIAJTUXQ5TPCIfqlVLXFkJyc9aYkfvhBZiVHZlyndX89z5+WIY8w3A+ vCQYi59JQJpoQlDXAwwzqrGtKL3RqpBz7Ui6AwmKbgZf7ynGLJ2um5Ae9 EEPjK1ajNnTRoKm160+rR+kVScl35/zbEij03Uc+c1x8+Fdgn6L7RoqD0 JGqWVzUNvqYAE5wNA527HiNtigypGtMxUEVWXNLCSZMpcDuc6/oAxz7PZ d68CXhiuujg5ZYvE2fK/eP/hPymKeWlARg4l3uEgxsMupzAiyBhznPlxj VeXfQxCaZQUllf1QQudIBinWYnsVY1P1iCw7sEKPu1WRjQCUn+ywN0YkU g==; X-IronPort-AV: E=McAfee;i="6500,9779,10465"; a="361464356" X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="361464356" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.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> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662739678; a=rsa-sha256; cv=none; b=X4VlAcXeSBiehNEV6+I724RqUqskgmjOUgU9hEdgxFKiJBXlqenBaL9VYIVTNaZqf3h57G s5i/1Lml2dWiTRVyBY2eCDXjD8BaCilLpQWXiPZ7uuxceXe5zYFxu4mGKCdlB5pBArY5gQ SKPy8/+wBGiGVum3aF8u5Q91M/+/1hM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=kWIAJTUX; spf=none (imf17.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=ashok_raj@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662739678; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WiFj5B68EDqDa2lwf8qblTt1C7E/7pyuLWBRHXSvH7c=; b=A0wPJ+8tVFiI4YGaq6XW5leGZNkZOsNwwqr3MfwDwQ2aiGnwD35IbcdF5W3uQKVEKWcLf7 2Yy4XOzjpzDMvol7FHaRr0gv/nbESENxxH45XGuYkBTBLITztKNYWIn7Dm6TEDKPmNmGWD TalYZEjmc2k25PLPhaov1PX9pcM6a4A= X-Rspamd-Server: rspam03 X-Rspam-User: X-Stat-Signature: expyr4e4gdma4x5t3xcd18n7nzs1rhsy X-Rspamd-Queue-Id: 44FC040082 Authentication-Results: imf17.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=kWIAJTUX; spf=none (imf17.hostedemail.com: domain of ashok_raj@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=ashok_raj@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-HE-Tag: 1662739678-272456 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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