Description
X86-focused material has historically been spread out at Plumbers. This will be an x86-focused microconference. Broadly speaking, anything that might affect arch/x86 is on topic, except where there may be a more focused discussion occurring, like around Confidential Computing or KVM.
This microconference would look at how to address new x86 processor features and also look back at how older issues might be made less painful. For new processor features like APX, what is coming? Are the vendors coordinating and are they compatible? For older issues like hardware security vulnerabilities, is the current approach working? If not, how should they be dealt with differently? Can new hardware features or vendor policies help?
As always, the microconference will be a great place for coordination among distributions, toolchains and users up and down the software stack. All the way from guest userspace to VMMs.
Potential Problem Areas to Address:
- CPU Vulnerabilities
- Default options for mitigations
- Are they being mitigated right?
- Are hardware interfaces for Data Independent Execution being plumbed into applications?
- FRED - new kernel entry/exist hardware
- What doors does FRED open?
- What things will be FRED-only?
- CET - Control flow Enforcement
- Security Hardware feature, includes Shadow Stacks and Indirect Branch Tracking
- Kernel Shadow Stacks
- User IBT/FineIBT?
- APX - new Intel ISA, more general purpose registers (GPRs) … (and more)
- What would a kernel with more GPRs look like?
- What plumbing implications does the MPX XSAVE offset reuse have?
- x86-S - Some future x86 CPUs may have a Smaller feature set and not be backward compatible
- SIPI64 is nice-ish, but other aspects are going to be especially nasty for virt
- Memory Protection Keys
- Userspace: Should we expand the ABI to cover more use cases?
- Can it be used to improve userspace security?
- Kernel: Page Table protections, mitigate malicious writes
- Memory Tagging / LAM / UBI
- CoCo Pain Points - what should the vendors be doing to ease them?
- XSAVE - Stay the course, or give up?
- How to ease the pain on gdb of AMD and Intel format divergence?
- x86 feature detection
- X86_FEATURE* - Is the code patching variants worth it? Should we pare down the choices? Do they really need to be per-cpu or should they be global?
- Should we impose more order in early boot about when it is OK to start checking feature flags or other parts of ‘boot_cpu_data’? Is this a good idea? Should ‘cpuinfo_x86’ be slimmed down further? - DaveH
Boot - Can the decompressor be entirely separated from the rest of the kernel proper?
- What old code imposes a maintenance burden and might be removed?
-
Pawan Gupta (Intel)20/09/2024, 15:00
This presentation will describe the growing complexity of mitigations for CPU side-channel vulnerabilities, the challenges they pose to the Linux kernel and what we can do to minimize the performance impact. It will also present the difficulty of maintaining various mitigation options, and the intrusive nature of mitigations that affect the core areas like context switch and kernel entry/exit...
Go to contribution page -
David Kaplan (AMD)20/09/2024, 15:20
There are currently more than a dozen command line options related to x86 CPU speculation bugs, and it takes a security expert to understand them all and when they can be safely disabled. This talk will discuss a recent RFC that proposes simpler “attack vector” based controls which would allow admins to select a set of mitigation options based on how the system is being used. For instance,...
Go to contribution page -
Lai Jiangshan (AntGroup)20/09/2024, 15:50
The x86_64 exception handling relies on complex indirect system structures such as the IDT and TSS. This process can sometimes involve complicated stack switching, which further complicates the situation when it comes to ring changes, syscall gaps, unblockable reentrant IST exceptions, the increasing number of Coco-introduced IST exception types, the nesting of the IST exceptions, and so...
Go to contribution page -
Brendan Jackman (Google)20/09/2024, 16:10
Address Space Isolation (ASI) is a technique to mitigate broad classes of CPU vulnerabilities.
ASI logically separates memory into “sensitive” and “nonsensitive”, the former is memory that may contain secrets and the latter is memory that, though it might be owned by a privileged component, we don’t actually care about leaking. The core aim is to execute comprehensive mitigations for...
Go to contribution page -
Peter Anvin, Xin Li20/09/2024, 17:00
First a quick update on what is done for FRED in Linux upstream, and then some improvements/fixes/refactors that we are doing or going to do. Lastly and most importantly an overview of future FRED features will be presented.
Go to contribution page -
Ahmed S. Darwish (Linutronix GmbH)20/09/2024, 17:20
At last year's Refereed Track, we introduced the "x86-cpuid-db" project and discussed its rationale for the Linux Kernel, the Xen hypervisor, and other plumbing layer open-source projects.
This year, the author will present a demo and initiate a discussion on the refactorings of the Linux Kernel's x86 subsystem and a new X86_FEATURE flags' dependency data model that are to be submitted...
Go to contribution page -
Chang Bae (Intel Corporation)20/09/2024, 17:50
Prior to the XSAVE introduction, managing the processor's context state
was handled on a per-feature basis. XSAVE normalized this by making state
management independent of the CPU feature set. The XSAVE architecture has
since evolved with optimizations, such as compacting the state format and
tweaks for efficient reloads, resulting in a few XSAVE variants.This monolithic approach to...
Go to contribution page -
Dave Hansen20/09/2024, 18:10
Memory Protection Keys (pkeys) was originally an Intel-only CPU feature to protect userspace memory. Since its introduction, support has materialized for powerpc, AMD and ARM, and Intel has expanded the original implementation to cover kernel memory.
There have been a number of attempts to expand the original implementation.
Let's take stock of where the original implementation stands...
Go to contribution page
