Re: [PATCH v2 2/4] x86/process: Add a debug interface to change LAM tag width
From: Maciej Wieczor-Retman
Date: Wed Feb 25 2026 - 13:00:46 EST
On 2026-02-25 at 10:17:20 +0000, Borislav Petkov wrote:
>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.
Okay, then I'll drop the debugfs part until that happens. Thanks!
--
Kind regards
Maciej Wieczór-Retman