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

[Maciej Wieczor-Retman]

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'?

-- 
Kind regards
Maciej Wieczór-Retman