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 F3593C43334 for ; Wed, 20 Jul 2022 12:47:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DFC76B0072; Wed, 20 Jul 2022 08:47:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4908D6B0073; Wed, 20 Jul 2022 08:47:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37E966B0074; Wed, 20 Jul 2022 08:47:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 296716B0072 for ; Wed, 20 Jul 2022 08:47:42 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E9ADAA1D2B for ; Wed, 20 Jul 2022 12:47:41 +0000 (UTC) X-FDA: 79707454722.31.A95966C Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf04.hostedemail.com (Postfix) with ESMTP id 0C3FE40071 for ; Wed, 20 Jul 2022 12:47:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658321261; x=1689857261; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YfJNf2xYuj2xjx3ZO/qD+opLPrqxhG9thyqGVqUoNA0=; b=RQtVb0KJY9W4ImlQ+nya9tkUDCswuxDRgMPMUN1H+XeRmedXm8mn71Im ADJCT+dAHn49VIVh3GeEZyoitYy+WBAnb/T2njo+s2NWIu/GFCEKgQGAB nHmaaSOwNme1m+5sbqDVAroXm0C+7DWKtUzhnppXYszJln+WdkydGbJb5 iUdPaE1l+69U8eH2VzJYZw4ONPd0koEpfUgg31MP+UJxmGxsxBJ18853Q Odmdb0HxOFRek21O7/EBdbQ3YGawBr429Z+2HtJx8OOjM2RRyxeIznU6N qfIckt5ar1yXmVjp9qw61opXWZJUpNZUoREs1/nIiPAlfcC715O2r6ryh g==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="267167181" X-IronPort-AV: E=Sophos;i="5.92,286,1650956400"; d="scan'208";a="267167181" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2022 05:47:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,286,1650956400"; d="scan'208";a="700862742" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 20 Jul 2022 05:47:35 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id EA207199; Wed, 20 Jul 2022 15:47:44 +0300 (EEST) Date: Wed, 20 Jul 2022 15:47:44 +0300 From: "Kirill A. Shutemov" To: Alexander Potapenko Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , the arch/x86 maintainers , Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Subject: Re: [PATCHv5 06/13] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR Message-ID: <20220720124744.rpvns3nda7jfljgn@black.fi.intel.com> References: <20220712231328.5294-1-kirill.shutemov@linux.intel.com> <20220712231328.5294-7-kirill.shutemov@linux.intel.com> <20220720005724.mwodxwm5r5gayqrm@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RQtVb0KJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658321261; 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=yh9i1wGcsNPUyVAT82yKWtiPKKAjyG/xCurzNQcLLHY=; b=01C0kK+tzImlhJEisExtU047behh0s2XziDfO6a2T/7BsRUY67JW2CTBh88IwfiqN1HCro 96lCgkQKacfK50Bme4LhXIvl/5mQMnf/iz/b3PPiSccE98GhUEpQ37pNpzgvFhuffmsxq3 gVXh9Yi/BsQ0dQhFrzKbOf0WgY/Lyjw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658321261; a=rsa-sha256; cv=none; b=tbM4DgMqBr/l5MORemAxppG3ETfG3B5CNb0Slknn6Lk4tVYIfsYku5OmwZieN/rem8fDvH oQ8K65sZWExylWD3m0e68Jyq5yxKcXqSyhbbCznvhEPkOIdzKb56Xgyqu+We8Elk24Plfr fdw9aQYbcFHFLrC5GT3b1DYR28J0RXo= X-Stat-Signature: pnjhtkbdh6jqwjei69ay9xnaoptnu6m5 X-Rspamd-Queue-Id: 0C3FE40071 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RQtVb0KJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Rspamd-Server: rspam11 X-HE-Tag: 1658321260-786726 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 Wed, Jul 20, 2022 at 10:19:36AM +0200, Alexander Potapenko wrote: > > > > long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > > > > { > > > > int ret = 0; > > > > @@ -829,7 +883,11 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) > > > > case ARCH_MAP_VDSO_64: > > > > return prctl_map_vdso(&vdso_image_64, arg2); > > > > #endif > > > > - > > > > + case ARCH_GET_UNTAG_MASK: > > > > + return put_user(task->mm->context.untag_mask, > > > > + (unsigned long __user *)arg2); > > > > > > Can we have ARCH_GET_UNTAG_MASK return the same error value (ENODEV or > > > EINVAL) as ARCH_ENABLE_TAGGED_ADDR in the case the host doesn't > > > support LAM? > > > After all, the mask does not make much sense in this case. > > > > I'm not sure about this. > > > > As it is ARCH_GET_UNTAG_MASK returns -1UL mask if LAM is not present or > > not enabled. Applying this mask will give correct result for both. > > Is anyone going to use this mask if tagging is unsupported? > Tools like HWASan won't even try to proceed in that case. I can imagine the code that tries to be indifferent to whether a pointer has tags. It gets mask from ARCH_GET_UNTAG_MASK and applies it to the pointer without any conditions. > > Why is -ENODEV better here? Looks like just more work for userspace. > > This boils down to the question of detecting LAM support I raised previously. > It's nice to have a syscall without side effects to check whether LAM > can be enabled at all (e.g. one can do the check in the parent process > and conditionally enable LAM in certain, but not all, child processes) > CPUID won't help here, because the presence of the LAM bit in CPUID > doesn't guarantee its support in the kernel, and every other solution > is more complicated than just issuing a system call. > > Note that TBI has PR_GET_TAGGED_ADDR_CTRL, which can be used to detect > the presence of memory tagging support. I would rather make enumeration explicit: diff --git a/arch/x86/include/uapi/asm/prctl.h b/arch/x86/include/uapi/asm/prctl.h index 38164a05c23c..a31e27b95b19 100644 --- a/arch/x86/include/uapi/asm/prctl.h +++ b/arch/x86/include/uapi/asm/prctl.h @@ -22,5 +22,6 @@ #define ARCH_GET_UNTAG_MASK 0x4001 #define ARCH_ENABLE_TAGGED_ADDR 0x4002 +#define ARCH_GET_MAX_TAG_BITS 0x4003 #endif /* _ASM_X86_PRCTL_H */ diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index cfa2e42a135a..2e4df63b775f 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -911,6 +911,13 @@ long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2) (unsigned long __user *)arg2); case ARCH_ENABLE_TAGGED_ADDR: return prctl_enable_tagged_addr(task->mm, arg2); + case ARCH_GET_MAX_TAG_BITS: + if (!cpu_feature_enabled(X86_FEATURE_LAM)) + return put_user(0, (unsigned long __user *)arg2); + else if (lam_u48_allowed()) + return put_user(15, (unsigned long __user *)arg2); + else + return put_user(6, (unsigned long __user *)arg2); default: ret = -EINVAL; break; -- Kirill A. Shutemov