Message ID | 20230403111020.3136-3-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2223596vqo; Mon, 3 Apr 2023 04:22:01 -0700 (PDT) X-Google-Smtp-Source: AKy350bTR3bq/r8XpD8+s+idqd+qLvU78Ase751UI7avjP4Pyq+gRe9rjywIon7Qiib3SoNzvi0q X-Received: by 2002:a17:906:43d8:b0:878:6b39:6d2a with SMTP id j24-20020a17090643d800b008786b396d2amr34817747ejn.46.1680520920986; Mon, 03 Apr 2023 04:22:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680520920; cv=none; d=google.com; s=arc-20160816; b=CEla9Oqwz5yOPHumEz+TDArI1mmLzZ2jIAmCMKvE4zcU3TgYkDacNlxZG/NsjRftGh SLAmW73BjoJc8lYJKuiFe+7B8hut13vWXo3IQzMocRk4OxPGuZDvRgYqketnif46sdGd 8tDaatSF4LXaEwB4mNrv+Y0nWQt6m6gLpA/6Pl0QgXIaiy8pjW8Fxkw5BTVuNnnIVME3 UWgngFqirsqPMagbe7YSLX67RIzXHWQA9whQoIrV3tUGIY/E7BPghNznMi9ZLWUvtT3p qqNkL79AO9oc2UDVJshAl8Qh+8tYo/KdEUIB6ZnHniqrF21gUKhjdKUEX99dMyJ8MdwE oWtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=2ZZPio4gxdEoamdf66m4ZkAgKXndyxzZY41yZ24m+DE=; b=U0EzXhjTSJAYsC3Rx5c6wZgPaWf2fn6avLZNcIgmCbKz5EZSIa8DzDLNhj6EtIiIR4 V1f0j5awDeswoJTCDndIoi15emDFMnLyqIKyS2jsRcfmiPFX9BdA7oq1LZjm6LfvBaET rJTXxVX125wFJq8zoRByvyJ92u+GbYJF5aY0vHf0/KqdkEv0q/2Q7DX3jolhegm616zK cyZWYLrK6fB2GBDOrA9itZSbFLvpFUMxqfvKw1Lr5uyCeL2KaJmSWe2CvxLkSkq1l/zd Am3M7xeEA1Fsyx/Nw9DpdCYWhuzac+xZ3r4C+PVafv9xlVwwgQ3a4/fiDzk5LVIUDl5z PV3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YB+wS6qP; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h24-20020a1709067cd800b0093b6e51aba2si7532451ejp.199.2023.04.03.04.21.36; Mon, 03 Apr 2023 04:22:00 -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=YB+wS6qP; 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 S232152AbjDCLLU (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 3 Apr 2023 07:11:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231951AbjDCLLK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 3 Apr 2023 07:11:10 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B26CB35A9 for <linux-kernel@vger.kernel.org>; Mon, 3 Apr 2023 04:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680520232; x=1712056232; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=i6n3D4JZD6jPRhROHlLAaHVSb3yrYur06jnlZ91gKLc=; b=YB+wS6qPVTikLkQg7M14hCFeTApAQ2tyH0UAbduFWdSYcMkRfARNkunD 3kj1VUM/c+RCJL5irsALtzB/he/241FfkvQtOW2pHmSh13cPD6X6+JKj+ raaICOooXOOuzXXOpuOR6nJvAfKWv+K1nmCRqTTscjLuw0aJanarVFVyZ ADFkYz7Dv0hvbCdh5WGlGtQVBAOofeLMNf6ClWxK37hTeNvJ4miii3KNF a2eh4BDccyibHy0Ohr4EN1ylOWvraJgYV/FEHF82cFnQeUShMw0qApRrc q+v6AJsbL0Q1Kda3nT0aVTkboleEID9vK4wNl67GDY/df+pnQplwfqSdl Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10668"; a="341895521" X-IronPort-AV: E=Sophos;i="5.98,314,1673942400"; d="scan'208";a="341895521" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2023 04:10:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10668"; a="663165543" X-IronPort-AV: E=Sophos;i="5.98,314,1673942400"; d="scan'208";a="663165543" Received: from amomin-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.210.227]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2023 04:10:27 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id F205610DFD3; Mon, 3 Apr 2023 14:10:23 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: x86@kernel.org, Kostya Serebryany <kcc@google.com>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Andrey Konovalov <andreyknvl@gmail.com>, Alexander Potapenko <glider@google.com>, Taras Madan <tarasmadan@google.com>, Dmitry Vyukov <dvyukov@google.com>, "H . J . Lu" <hjl.tools@gmail.com>, Andi Kleen <ak@linux.intel.com>, Rick Edgecombe <rick.p.edgecombe@intel.com>, Bharata B Rao <bharata@amd.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Ashok Raj <ashok.raj@intel.com>, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCH 2/2] x86/mm/iommu/sva: Do not allow to set FORCE_TAGGED_SVA bit from outside Date: Mon, 3 Apr 2023 14:10:20 +0300 Message-Id: <20230403111020.3136-3-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230403111020.3136-1-kirill.shutemov@linux.intel.com> References: <20230403111020.3136-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762153904862117006?= X-GMAIL-MSGID: =?utf-8?q?1762153904862117006?= |
Series |
Couple of trivial fixes for LAM vs. SVA interaction
|
|
Commit Message
Kirill A. Shutemov
April 3, 2023, 11:10 a.m. UTC
arch_prctl(ARCH_FORCE_TAGGED_SVA) overrides the default and allows LAM
and SVA to co-exist in the process. It is expected by called by the
process when it knows what it is doing.
arch_prctl() operates on the current process, but the same code is
reachable from ptrace where it can be called on arbitrary task.
Make it strict and only allow to set MM_CONTEXT_FORCE_TAGGED_SVA for the
current process.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Fixes: 23e5d9ec2bab ("x86/mm/iommu/sva: Make LAM and SVA mutually exclusive")
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
---
arch/x86/kernel/process_64.c | 2 ++
1 file changed, 2 insertions(+)
Comments
On Mon, 3 Apr 2023 at 13:10, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > > arch_prctl(ARCH_FORCE_TAGGED_SVA) overrides the default and allows LAM > and SVA to co-exist in the process. It is expected by called by the > process when it knows what it is doing. > > arch_prctl() operates on the current process, but the same code is > reachable from ptrace where it can be called on arbitrary task. > > Make it strict and only allow to set MM_CONTEXT_FORCE_TAGGED_SVA for the > current process. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Fixes: 23e5d9ec2bab ("x86/mm/iommu/sva: Make LAM and SVA mutually exclusive") > Suggested-by: Dmitry Vyukov <dvyukov@google.com> > --- > arch/x86/kernel/process_64.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > index c7dfd727c9ec..cefac2d3a9f6 100644 > --- a/arch/x86/kernel/process_64.c > +++ b/arch/x86/kernel/process_64.c > @@ -885,6 +885,8 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > case ARCH_ENABLE_TAGGED_ADDR: > return prctl_enable_tagged_addr(task->mm, arg2); > case ARCH_FORCE_TAGGED_SVA: > + if (current != task) > + return -EINVAL; prctl_enable_tagged_addr() checks "task->mm != current->mm". Should we check the same here for consistency? Or also change the check in prctl_enable_tagged_addr(). arch_prctl() can only do task==current, so I guess "current != task" is a more reasonable check for prctl_enable_tagged_addr() as well. > set_bit(MM_CONTEXT_FORCE_TAGGED_SVA, &task->mm->context.flags); > return 0; > case ARCH_GET_MAX_TAG_BITS: > -- > 2.39.2 >
On Mon, Apr 03, 2023 at 03:55:09PM +0200, Dmitry Vyukov wrote: > On Mon, 3 Apr 2023 at 13:10, Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> wrote: > > > > arch_prctl(ARCH_FORCE_TAGGED_SVA) overrides the default and allows LAM > > and SVA to co-exist in the process. It is expected by called by the > > process when it knows what it is doing. > > > > arch_prctl() operates on the current process, but the same code is > > reachable from ptrace where it can be called on arbitrary task. > > > > Make it strict and only allow to set MM_CONTEXT_FORCE_TAGGED_SVA for the > > current process. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > Fixes: 23e5d9ec2bab ("x86/mm/iommu/sva: Make LAM and SVA mutually exclusive") > > Suggested-by: Dmitry Vyukov <dvyukov@google.com> > > --- > > arch/x86/kernel/process_64.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > > index c7dfd727c9ec..cefac2d3a9f6 100644 > > --- a/arch/x86/kernel/process_64.c > > +++ b/arch/x86/kernel/process_64.c > > @@ -885,6 +885,8 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > > case ARCH_ENABLE_TAGGED_ADDR: > > return prctl_enable_tagged_addr(task->mm, arg2); > > case ARCH_FORCE_TAGGED_SVA: > > + if (current != task) > > + return -EINVAL; > > prctl_enable_tagged_addr() checks "task->mm != current->mm". > Should we check the same here for consistency? Or also change the > check in prctl_enable_tagged_addr(). > > arch_prctl() can only do task==current, so I guess "current != task" > is a more reasonable check for prctl_enable_tagged_addr() as well. As of now, prctl_enable_tagged_addr() doesn't have the task on hands. It gets mm as input, so it cannot check the task directly. But functionally it is the same check. I would prefer to keep it this way. Unless anyone feels strongly about it.
On Mon, 3 Apr 2023 at 16:31, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > On Mon, Apr 03, 2023 at 03:55:09PM +0200, Dmitry Vyukov wrote: > > On Mon, 3 Apr 2023 at 13:10, Kirill A. Shutemov > > <kirill.shutemov@linux.intel.com> wrote: > > > > > > arch_prctl(ARCH_FORCE_TAGGED_SVA) overrides the default and allows LAM > > > and SVA to co-exist in the process. It is expected by called by the > > > process when it knows what it is doing. > > > > > > arch_prctl() operates on the current process, but the same code is > > > reachable from ptrace where it can be called on arbitrary task. > > > > > > Make it strict and only allow to set MM_CONTEXT_FORCE_TAGGED_SVA for the > > > current process. > > > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > > Fixes: 23e5d9ec2bab ("x86/mm/iommu/sva: Make LAM and SVA mutually exclusive") > > > Suggested-by: Dmitry Vyukov <dvyukov@google.com> > > > --- > > > arch/x86/kernel/process_64.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > > > index c7dfd727c9ec..cefac2d3a9f6 100644 > > > --- a/arch/x86/kernel/process_64.c > > > +++ b/arch/x86/kernel/process_64.c > > > @@ -885,6 +885,8 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > > > case ARCH_ENABLE_TAGGED_ADDR: > > > return prctl_enable_tagged_addr(task->mm, arg2); > > > case ARCH_FORCE_TAGGED_SVA: > > > + if (current != task) > > > + return -EINVAL; > > > > prctl_enable_tagged_addr() checks "task->mm != current->mm". > > Should we check the same here for consistency? Or also change the > > check in prctl_enable_tagged_addr(). > > > > arch_prctl() can only do task==current, so I guess "current != task" > > is a more reasonable check for prctl_enable_tagged_addr() as well. > > As of now, prctl_enable_tagged_addr() doesn't have the task on hands. It > gets mm as input, so it cannot check the task directly. But functionally > it is the same check. > > I would prefer to keep it this way. Unless anyone feels strongly about it. Fine with me. Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index c7dfd727c9ec..cefac2d3a9f6 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -885,6 +885,8 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) case ARCH_ENABLE_TAGGED_ADDR: return prctl_enable_tagged_addr(task->mm, arg2); case ARCH_FORCE_TAGGED_SVA: + if (current != task) + return -EINVAL; set_bit(MM_CONTEXT_FORCE_TAGGED_SVA, &task->mm->context.flags); return 0; case ARCH_GET_MAX_TAG_BITS: