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 CFACFC28B30 for ; Thu, 20 Mar 2025 10:44:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8328D280004; Thu, 20 Mar 2025 06:44:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E37A280001; Thu, 20 Mar 2025 06:44:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 683C1280004; Thu, 20 Mar 2025 06:44:42 -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 48CA1280001 for ; Thu, 20 Mar 2025 06:44:42 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A3227140DED for ; Thu, 20 Mar 2025 10:44:43 +0000 (UTC) X-FDA: 83241596046.05.435BDED Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) by imf14.hostedemail.com (Postfix) with ESMTP id BA96C100005 for ; Thu, 20 Mar 2025 10:44:41 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rsFesVlG; spf=pass (imf14.hostedemail.com: domain of 3mPHbZwgKCDEWNPXZNaOTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--jackmanb.bounces.google.com designates 209.85.128.74 as permitted sender) smtp.mailfrom=3mPHbZwgKCDEWNPXZNaOTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742467481; 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=j11DFSETqOLtc+vMOz1k4rHgXFA118EedepjEdU8Zqw=; b=FNol1p7DbgH+M+/QxEGoEbUGexvuYc5hXHH2IVXCjoQNXXQKLhr/swOrSCrZzMCNdv9M0i W0W31friHRXEoLIwaHq9JUADzQyRszvG77qETyfQqq05wJBtvXP0UuKuMccrLK9RzKTJb8 3k4emYkBbmTX1tkLFt5tMs+Uv4T8G9A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742467481; a=rsa-sha256; cv=none; b=dyOPnWHGq/IalwyQK3nE6ZMid4JVfFT827z4sOWhgCAdC63ME5wO17RF+q11jMu2fwoi78 kHnKU6wSGsV5LUkn8Lr150hGp1LPDasR4UOepXC4aEuaU6czrmNu9VLJ8YDGsI9kxJ3s5l d6uIdnzTDgHguSaxQZjC1Ttze4XRSI8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rsFesVlG; spf=pass (imf14.hostedemail.com: domain of 3mPHbZwgKCDEWNPXZNaOTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--jackmanb.bounces.google.com designates 209.85.128.74 as permitted sender) smtp.mailfrom=3mPHbZwgKCDEWNPXZNaOTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-43d3b211d0eso9419255e9.1 for ; Thu, 20 Mar 2025 03:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742467480; x=1743072280; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=j11DFSETqOLtc+vMOz1k4rHgXFA118EedepjEdU8Zqw=; b=rsFesVlGM0LtnqSSQ0E8Db6HZkKR8JNMo2eRFf0ynkU4njtE7zSxNdnQX1oIAG/QZZ 0W4Hsjlx9C9PM5NrMU45qQdgqDh/uNvYAJjkgMF0pJrUhAM2TVRKtAT7NkSZ2WQPik5K KzDf3egdvNHV+ckTej6yV68aKz8/ea/EUhtg2JAvNGdErY8GnS4CuixMJPNhaXgSyxgY 7ztlahgS7JGwcF4KLA4YHAGqyeyC5o+oV55EfS4k5DIrkm+pcuNhmWuG5GP5cNdkPHfX xBLfRVagIF7EJD69uOImQ9gI76MBGW/F5WDmOLw/Lz3zDkHW7OHuSup4si7xM+n4ACJh EkBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742467480; x=1743072280; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=j11DFSETqOLtc+vMOz1k4rHgXFA118EedepjEdU8Zqw=; b=QRI16rWQK2+YkTjqRpSouGOJGTtLZ9uqWyrOzWW4TJTdT0qlpCOX4x6CcFNgWzb/Ph I0NqsVE/V+GWEtxFSF6CQSfQXogQESvtHUuYiJI/0TLed0hnFM/dFZrtmpFdvQm/345J cVA+fBeHh+BIkxz/aOrz0Hf39BV1dd4ECOjj0SG1ri2rU0L6kwyRqtcbbdvrV4ZWpMLn A5MT3v+R6qCyseDgMglyubImW4VcIuF1bZlqsqozZDGR+fQ/pCr/XSj6xIwLpATRZRZl NhFhwc+r/VCL4IvpSYP8kcT6oScAbdiCw74rMW347+ScbScAAUCmosi2/Tz03ArXTcBK SYzw== X-Forwarded-Encrypted: i=1; AJvYcCXmJpiz70rLngYCPP/nnB2lC747ZRr1MGAc2ewsmJBCGitWzufQQ7w2idF583gzWkNB+K6b+37V0g==@kvack.org X-Gm-Message-State: AOJu0Yzc2h6V6NfpKmUg918POL+xOiUSzs2/7aRrDIvO5+y5EAnqMUHC NSzadMLKzEp9QBBi3vbks+FrjWEuI2czyoPwREY0+kUkJc0rbZib0to+OB7Ogy1s/XEFUEgvN+y 5I5HHfU7eDA== X-Google-Smtp-Source: AGHT+IHmhdHTuCMOMffmpvyIMCzJObzjHJotMPvb7/CKZriBN1WJ2Qe2CHVhTxdEuiWThlixsbw8H9oOiShQMA== X-Received: from wmgg15.prod.google.com ([2002:a05:600d:f:b0:43b:c450:ea70]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:1da2:b0:439:5f04:4f8d with SMTP id 5b1f17b1804b1-43d49187ba9mr20806165e9.12.1742467480075; Thu, 20 Mar 2025 03:44:40 -0700 (PDT) Date: Thu, 20 Mar 2025 10:44:38 +0000 In-Reply-To: Mime-Version: 1.0 References: <20250110-asi-rfc-v2-v2-0-8419288bc805@google.com> <20250110-asi-rfc-v2-v2-4-8419288bc805@google.com> <20250319172935.GMZ9r-_zzXhyhHBLfj@fat_crate.local> X-Mailer: aerc 0.18.2 Message-ID: Subject: Re: [PATCH RFC v2 04/29] mm: asi: Add infrastructure for boot-time enablement From: Brendan Jackman To: Yosry Ahmed , Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Josh Poimboeuf , Pawan Gupta , , , , , , , , , , , , , , , , , , , , , , , , , Junaid Shahid Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BA96C100005 X-Stat-Signature: q5tdonkm7abyjkpdahua3tok9z7zddwh X-HE-Tag: 1742467481-889673 X-HE-Meta: U2FsdGVkX186pN0qHku5b1wfCe8vbHWK2ieTmVbLhXx8QQt62HOjtnbuPjvHPrX2n/xxnAcoMtlBg7E1c+fdIC3d2+e80xZGYrgEKHciSLB7KUjVd895zSS5G33RXRiMs3UrF32z5uRrfERiNNOB61yxkCY0shz/tiJaz/MkCrof9FSbukzo28RtLMzO+Cu4uTxZhOTw3YTg8SpUw4+OXxKn2WcRZKvBi5nJZT6JRx0nije4Wy8xY5fMEILOZdpxJeaXpQzHRYu7IVqYRQ0XIegSNNmjvkQFbu5RXIdEycoiNAqbU83KkdAuJhtminePOv9vip8cS9Wkk8SSBtcma8TJ9vR3ivUiEm79YO7pD4Mbmfjm4FUm7V2AT6L2SKjkhIse6mZnFClW2eSUJndOSoUVbTC1A3LCY5CWC/7LBkyy2Bd8OrGAC1EdjscN7Dn9fEO8xgNQZY5eFpauS88kl5N5HpjjTOTlDZOOQAXpj6Bz8SbAXNavIl0CwUUQZL1+d2UWzVnUySbQAS5cJuxruLRHxGCYAJZ7kpn9Z4lbE/50rGWeYR6Mpf3K+d+dPt98fDXcqtRUIym4i8n12pLc4DIhn4z4c1cZ1NpxvZlv/CNmE6xMQZfrlL/9ZoBOjp3/Mrg+YCSYofum/kiTnnu5QU5F0lYTyERxwB3oMN4wwUWJmFr/av0acic22ZJ7IM1NSg4EFZ/btNWKr1tjxQfOTCH4hyYpraaNtHa/JcJtwkEjkf+vAEAS5bdhFQYl04zYLRkQjtmH8I7FUbu+9Pd9AF+3V+VW5ZHxfmZCRtHZslmVMxYRXYMhaQRBNb7+ZUFbtfmMWlSdoYryPS5o1xRfmKJshk/MAPW7OR7DHSIsA1tvQG+3hxXNKfXC0bha+UHRFqcNkTgFpLWYe1A1jX6UjjVHX2WiZZkEC6QCLepV5Xslr6uLNdsR1u0wEgqg+UzT9fkR0sgnTtd2XqTZFFR fo6v7smn FK6MbMCzMuH7Oq+Eg1VmyRzKTxBQvncVgb7XgpdJAVsb6r+YCTAtczATXSUVyo01L3T25Ij6Vg9s4q+nsnkIfSrlStXRO6vg7uHntAL9j4mTqnWWBdwFuj5E6r6WC3cFSRUZW5s7FvF1htjthf47vK/NxaAGnEO4bx1uJkiAwcpdyrGcurhM9YGf5gQnaY3FvgnyDQ/LmblZLCIvhNuGFbrl9trGbiBeWEPm0XW9hpESuYOqr7OjzGzivJZOV3w93aI0ufTmlQp6CQvvHow6nm3/+d5QG/p1gjPKPuD2IGya6T2DYBZsCAcT999KljD7/Rq8jw1kdFU7rNB35tP01BM+veemoLisn4gDcnY1nYiCu9MMeS2VSdJlxoLgx+ufAGX609tj6uzpywRwEfRZtaltjCEHKWyCHrBrGEGhtTldZURJb4QRgGlxBdEebCNu1XPhFsmrVcsl/5/79xr8omZMLv1QCNwreqB7WAno3WiT57UZA7T8Mf1nzfiiiauQCs3EbuY0kSovgueFGuvsGjwdzQKgwtUaVIV4GYsYcrRre9HHUFtNdIZcV6RwzSBoM16zX 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: List-Subscribe: List-Unsubscribe: On Wed Mar 19, 2025 at 6:47 PM UTC, Yosry Ahmed wrote: > On Wed, Mar 19, 2025 at 06:29:35PM +0100, Borislav Petkov wrote: > > On Fri, Jan 10, 2025 at 06:40:30PM +0000, Brendan Jackman wrote: > > > Add a boot time parameter to control the newly added X86_FEATURE_ASI. > > > "asi=on" or "asi=off" can be used in the kernel command line to enable > > > or disable ASI at boot time. If not specified, ASI enablement depends > > > on CONFIG_ADDRESS_SPACE_ISOLATION_DEFAULT_ON, which is off by default. > > > > I don't know yet why we need this default-on thing... > > It's a convenience to avoid needing to set asi=on if you want ASI to be > on by default. It's similar to HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON > or ZSWAP_DEFAULT_ON. > > [..] > > > @@ -175,7 +184,11 @@ static __always_inline bool asi_is_restricted(void) > > > return (bool)asi_get_current(); > > > } > > > > > > -/* If we exit/have exited, can we stay that way until the next asi_enter? */ > > > +/* > > > + * If we exit/have exited, can we stay that way until the next asi_enter? > > > > What is that supposed to mean here? > > asi_is_relaxed() checks if the thread is outside an ASI critical > section. > > I say "the thread" because it will also return true if we are executing > an interrupt that arrived during the critical section, even though the > interrupt handler is not technically part of the critical section. > > Now the reason it says "if we exit we stay that way" is probably > referring to the fact that an asi_exit() when interrupting a critical > section will be undone in the interrupt epilogue by re-entering ASI. > > I agree the wording here is confusing. We should probably describe this > more explicitly and probably rename the function after the API > discussions you had in the previous patch. Yeah, this is confusing. It's trying to very concisely define the concept of "relaxed" but now I see it through Boris' eyes I realise it's really unhelpful to try and do that. And yeah we should probably just rework the terminology/API. To re-iterate what Yosry said, aside from my too-clever comment style the more fundamental thing that's confusing here is that, using the terminology currently in the code there are two concepts at play: - The critical section: this is the path from asi_enter() to asi_relax(). The critical section can be interrupted, and code running in those interupts is not said to be "in the critical section". - Being "tense" vs "relaxed". Being "tense" means the _task_ is in a critical section, but the current code might not be. This distinction is theoretically relevant because e.g. it's a bug to access sensitive data in a critical section, but it's OK to access it while in the tense state (we will switch to the restricted address space, but this is OK because we will have a chance to asi_enter() again before we get back to the untrusted code). BTW, just to be clear: 1. Both of these are only relevant to code that's pretty deeply aware of ASI. (TLB flushing code, entry code, stuff like that). 2. To be honest whenever you write: if (asi_in_critical_section()) You probably mean: if (WARN_ON(asi_in_critical_section())) For example if we try to flush the TLB in the critical section, there's a thing we can do to handle it. But that really shouldn't be necessary. We want the critical section code to be very small and straight-line code. And indeed in the present code we don't use asi_in_critical_section() for anything bur WARNing. > asi_is_relaxed() checks if the thread is outside an ASI critical > section. Now I see it written this way, this is probably the best way to conceptualise it. Instead of having two concepts "tense/relaxed" vs "ASI critical section" we could just say "the task is in a critical section" vs "the CPU is in a critical section". So we could have something like: bool asi_task_critical(void); bool asi_cpu_critical(void); (They could also accept an argument for the task/CPU, but I can't see any reason why you'd peek at another context like that). -- For everything else, Ack to Boris or +1 to Yosry respectively.