Re: [PATCH v2 2/4] x86/process: Add a debug interface to change LAM tag width

[Borislav Petkov]

On February 25, 2026 9:29:29 AM UTC, Maciej Wieczor-Retman <m.wieczorretman@xxxxx> wrote:
>On 2026-02-24 at 21:25:45 +0000, Borislav Petkov wrote:
>>On February 24, 2026 1:22:07 PM UTC, Maciej Wieczor-Retman <m.wieczorretman@xxxxx> wrote:
>>>From: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>
>>>+
>...
>>>+/*
>>>+ * Writing a number to this file changes the used lam tag width. Valid values
>>>+ * are 4 bit tag width and 6 bit tag width - the second, non-default one is
>>>+ * meant mostly for debug and shall be deprecated in the future.
>>>+ */
>>>+static ssize_t lam_bits_write_file(struct file *file,
>>>+				   const char __user *user_buf, size_t count,
>>>+				   loff_t *ppos)
>...
>>
>>The moment someone starts using this, it becomes an ABI no matter whether it is in debugfs or not.
>>
>>So why do we *really* want it?
>>--
>>Small device. Typos and formatting crap
>
>The general intention as stated in the comment above is to move over to the
>4-bits of LAM as the default value so that once things like ChkTag start using
>it they don't expect the wider value and any future ABIs don't break in case the
>6-bit width is removed in favor of the 4-bit one.
>
>Now the debugfs part of that was meant to allow access to the full functionality
>in case someone could find some temporary use for that. AFAIK so far only clang
>implemented a KASAN mode for x86 with the assumption of 6-bit LAM but from my
>tests with the KASAN series I'm working on it doesn't work properly and needs
>fixes anyway.
>
>So if you think this is a problematic addition I'm not opposed to just dropping
>the debugfs part or documenting it that it shouldn't be relied on to stay here
>forever. Altough I thought that debugfs is documented as 'to not serve as a
>stable ABI to user space'?

I'm on a plane right now but you can search "debugfs ABI" on lwn.net and read the article. "[I]n case someone could find some temporary use" is exactly the "interceptive" enablement we do NOT do. When someone does find a concrete use, we'll talk about proper design then.

-- 
Small device. Typos and formatting crap