From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31BCA223336 for ; Mon, 12 Jan 2026 23:03:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768258991; cv=none; b=YxbDNGSB/7YEQJg7buGlfJxoNxNGIO0SjYr0cdTmFnvuCaF38UvpRkMkOVdDtLKQJml4icogk8AT1L0TrovqK8MchnnLCt/gXmJ3rmrRlIa6ER7gv9xanq2EUnbkF3kkbVlXuaTVb0dsDykndr0JFRUYtpTHZGPYHN5JHUFRfbI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768258991; c=relaxed/simple; bh=xZkOPXCIRdSZAx9SJK5eN9HdiBC+/orEbq8QkucfCtM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QDbjT8h52ZOZxp7XkREdVPgaDaoLZ30EiUkQl2kl2JB7K8qNK5jrPT9X2rUag6OBX1ijosgBgBt0/pCOS/E9CDqLf0HZqUMZ0UlO24VQ/tESXTCR4aT5qPrTVE82fHYUBhvHF7PNUP548GmsJAGTQnlYn1jAr8GReOu37oYG2gg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=A4ziwlIM; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A4ziwlIM" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so47538395e9.2 for ; Mon, 12 Jan 2026 15:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768258988; x=1768863788; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=VRWaHHKt6PhH1VQF5Sj58s1toZVOW1aFddwms70jGV0=; b=A4ziwlIMU09Uxip/+BglP9T+rihoA8FGdxDrRlEFGX0wxH3J9KIoaMJlWcZEDM5ei1 /RjrSG/YxtrP0JXjn0NSyCkcNDQq9DHB72vxe9pJu99U9Vp9ogLTbBWmCgZyNxAbWgtf ZuPQMwVzL/PZXu+YDa/CvIhQGbqoN9mMJ2Aw2dniDTjueSno7dyucBvjDQ6jB1NkW0ds b8KK/UDQW977jyQyrvudAUTAhaxSoR1iCkGOlJoJMnYykx87sRmCENJIJ55OZuSrQkAJ Slz3i8bxIs3Lk3etVByEQYUQxlRthG+Zfzs09WthxOSUT05K1RmUuMRTc1V/n41G6MnE LxJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768258988; x=1768863788; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=VRWaHHKt6PhH1VQF5Sj58s1toZVOW1aFddwms70jGV0=; b=jbmuYYDPYHtCOFsXNjxwGn4HTQD4bx+b3icegcJQayyU5YMrjrTB+bPcbw77n97PVl IrUUleeZeFxeeab3x5zotqqn0yc0xpArtTRqnIjqalBc55l+NlU2rEE4CoNkY9kTK0TH zCdZ/HeC+Csu/QIZnApvtB+Xmo7W13qzlfa7f/+oq1kNPBajxb6vWidXhAOTl1YlOw+d 9/+pqfMjrIlXTPGmVXHyIYRf/XM7sL35feS5c9Yaf/mdPhHltF/5J5kF/uowCV2VJ9UI cn2EMHlIM81ll2TD6TO9PHII22UXgQL4XUdCDGxvW0jcUZa4A+K0AF1yZBbN0V52MNvh uA0g== X-Forwarded-Encrypted: i=1; AJvYcCUHn/aebZq4ByYda59nOlrTuoA+9C5lqVSZERcyhQ/bSjglVJ/G/oVUX/Ggy5ltHoTwZdDi/JSJQwLt/go=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2gC46X1NBQ+OLMdJZnWDjqfzhx6ZLBRdfMtOZWLB3YR81Jpua Wv9WM3dpS0Ey1fKj2I/wEYP8kJEL1Nh5nza2V/rh98jL545hcI2CjQX2 X-Gm-Gg: AY/fxX4hnG+XyNErZKZB2G9dEGqk53t9tRcfqCQ+jv6hEbWS/Ef23Nt6p7Dz0GX+kiR da+Do/ApOq2UIzZWyFTuAZD+F4AWp7z4GDsFw8/8NwBZEo7OQNoThhTteXiZDMuRqJeSDLsN7MZ ZV8jDrel3cNY714ST3ZTTxdKkNlWovJCM0kyJtrpcOw/WVQ6RHHZtkoBo0Y4DaZvbqS/se2qqNp teA9mVhwdE70Dksx+CS4Wxfudu0dLeYQGtqUbcujqUtmgGyUxC0JEjOYUIFCW8hxntD283J09Hp AaAiExfJZPRyUyRxIFTGWGWmN78HSRqxn1Xck2BQWttJ5d7rm6GnHljiwIR0kUkbawy3rruaBFh QchwrRCPqchsBi0dMtjU+j3CHE0LZX9WislCaiX/Ob8pg2doS9yPwUZ88aDu/K1D+kIy9Cieb3X Tl1jeX5d8fypbA/4vuYpr7lG5UHk6pL9P5/wo9lTRkd5L2itpEROrqzjV3hpFt/vQ= X-Google-Smtp-Source: AGHT+IGSivVyFTxneB87aCQkJONNB7LVvg4lx7QX43oTnxdJrYtfU1jnpmMQVmNUwyepeNv0k7k+rg== X-Received: by 2002:a05:600c:a03:b0:47a:7fd0:9eea with SMTP id 5b1f17b1804b1-47d8e56625cmr174793975e9.3.1768258988453; Mon, 12 Jan 2026 15:03:08 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f6ef868sm370626565e9.11.2026.01.12.15.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 15:03:08 -0800 (PST) Date: Mon, 12 Jan 2026 23:03:06 +0000 From: David Laight To: Kees Cook Cc: Alexander Lobakin , linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] Fortify: Use C arithmetic not FIELD_xxx() in FORTIFY_REASON defines Message-ID: <20260112230306.7cf878b1@pumpkin> In-Reply-To: <202601121415.CEB3C024@keescook> References: <20251214125857.3308-1-david.laight.linux@gmail.com> <202601121415.CEB3C024@keescook> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 12 Jan 2026 14:18:56 -0800 Kees Cook wrote: > On Sun, Dec 14, 2025 at 12:58:57PM +0000, david.laight.linux@gmail.com wrote: > > From: David Laight > > > > FIELD_GET() and FIELD_PREP() are mainly useful for hardware register > > accesses, but here they are being used for some very simple oprations. > > > > This wouldn't matter much, but they contain a lot of compile-time > > checks (that really aren't needed here) that bloat the expansion > > of FIELD_GET(GENMASK(7, 1), func) to over 18KB. > > Even with the 'bloat reduced' FIELD_GET/PREP they are still hundreds of > > characters. > > > > Replace FIELD_GET(BIT(0), r) with ((r) & 1), FIELD_GET(GENMASK(7, 1), r) with > > (r) >> 1), and (FIELD_PREP(BIT(0), write) | FIELD_PREP(GENMASK(7, 1), func)) > > with ((func) << 1 | (write)). > > > > The generated code is the same, but it makes the .c file less obfuctaced, > > the .i file much easier to read, and should marginally decrease compilation > > time. > > > > Signed-off-by: David Laight > > --- > > > > Note that changing 'const u8 reason' to 'const unsigned int reason' generates > > better code - in this case removing 2 instructions (one in each of the called > > functions). > > > > include/linux/fortify-string.h | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h > > index b3b53f8c1b28..171982e53c9a 100644 > > --- a/include/linux/fortify-string.h > > +++ b/include/linux/fortify-string.h > > @@ -2,7 +2,6 @@ > > #ifndef _LINUX_FORTIFY_STRING_H_ > > #define _LINUX_FORTIFY_STRING_H_ > > > > -#include > > #include > > #include > > #include > > @@ -10,10 +9,9 @@ > > #define __FORTIFY_INLINE extern __always_inline __gnu_inline __overloadable > > #define __RENAME(x) __asm__(#x) > > > > -#define FORTIFY_REASON_DIR(r) FIELD_GET(BIT(0), r) > > -#define FORTIFY_REASON_FUNC(r) FIELD_GET(GENMASK(7, 1), r) > > -#define FORTIFY_REASON(func, write) (FIELD_PREP(BIT(0), write) | \ > > - FIELD_PREP(GENMASK(7, 1), func)) > > +#define FORTIFY_REASON_DIR(r) ((r) & 1) > > +#define FORTIFY_REASON_FUNC(r) ((r) >> 1) > > Sure, we can do this. I agree, the preprocessor gunk is huge currently. > For the above, how about keeping with the original logic and use: > > #define FORTIFY_REASON_FUNC(r) (((r) & 0xF) >> 1) I think you mean 0xFF (and below) to match the old code. But since your 'r' is 'u8' (but see below) the mask should be discarded by the compiler anyway. > > +#define FORTIFY_REASON(func, write) ((func) << 1 | (write)) > > and: > > > +#define FORTIFY_REASON(func, write) ((func) << 1 | (write)) > > #define FORTIFY_REASON(func, write) (((func) << 1 | ((write) & 1)) & 0xF) 'write' is always a constant 0 or 1, and you are writing it to a u8 (which will mask with 0xff anyway). So you are adding code that just makes it more difficult to read. > > so we're always getting processing a u8? IIRC that is just passed as a function parameter, not stored in a structure? If so there isn't any such beast as a 'u8'. It will always be passed exactly the same way an int is passed. So the parameter might as well be a u32 (the code might shrink). By saying it is a u8 you just force the compiler to mask any (non-constant) calculated value to 8 bits after writing it to the register that holds the value (and on the function parameter). All the arithmetic is done after promoting the u8 to 'signed int'. You won't see the 'gory details' on x86, it and m68k are the only cpu that have 8/16 bit registers (as part of the 32bit ones). ISTR there is a check that FUNC isn't too big (because there are no where near 127 of them), that will pick up any 'accidental garbage' before it breaks badly - no need to mask the values to 8 bits at all. David > > -Kees >