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.
