linux-hardening - Re: [PATCH v2] x86/traps: Enable UBSAN traps on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202406171557.E6CA604FB@keescook>
Date: Mon, 17 Jun 2024 16:06:47 -0700
From: Kees Cook <kees@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Gatlin Newhouse <gatlin.newhouse@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, Marco Elver <elver@...gle.com>,
	Andrey Konovalov <andreyknvl@...il.com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Baoquan He <bhe@...hat.com>, Changbin Du <changbin.du@...wei.com>,
	Pengfei Xu <pengfei.xu@...el.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>, Xin Li <xin3.li@...el.com>,
	Jason Gunthorpe <jgg@...pe.ca>, Tina Zhang <tina.zhang@...el.com>,
	Uros Bizjak <ubizjak@...il.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
	linux-hardening@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v2] x86/traps: Enable UBSAN traps on x86

On Tue, Jun 18, 2024 at 12:13:27AM +0200, Thomas Gleixner wrote:
> On Wed, Jun 12 2024 at 11:42, Kees Cook wrote:
> > On Tue, Jun 11, 2024 at 01:26:09PM -0700, Gatlin Newhouse wrote:
> >> It seems that is_valid_bugaddr() needs to be implemented on all architectures
> >> and the function get_ud_type() replaces it here. So how should the patch handle
> >> is_valid_bugaddr()? Should the function remain as-is in traps.c despite no
> >> longer being used?
> >
> > Yeah, this is why I'd suggested to Gatlin in early designs to reuse
> > is_valid_bugaddr()'s int value. It's a required function, so it seemed
> > sensible to just repurpose it from yes/no to no/type1/type2/type3/etc.
> 
> It's not sensible, it's just tasteless.
> 
> If is_valid_bugaddr() is globaly required in it's boolean form then it
> should just stay that way and not be abused just because it can be
> abused.
> 
> What's wrong with doing:
> 
> __always_inline u16 get_ud_type(unsigned long addr)
> {
>         ....
> }
> 
> int is_valid_bugaddr(unsigned long addr)
> {
> 	return get_ud_type() != BUG_UD_NONE;
> }
> 
> Hmm?
> 
> In fact is_valid_bugaddr() should be globally fixed up to return bool to
> match what the function name suggests.
> 
> The UD type information is x86 specific and has zero business in a
> generic architecture agnostic function return value.
> 
> It's a sad state of affairs that I have to explain this to people who
> care about code correctness. Readability and consistency are substantial
> parts of correctness, really.

Well, it's trade-offs. If get_ud_type() is in is_valid_bugaddr(), we
have to call it _again_ outside of is_valid_bugaddr(). That's suboptimal
as well. I was trying to find a reasonable way to avoid refactoring all
architectures and to avoid code code.

Looking at it all again, I actually think arch/x86/kernel/traps.c
shouldn't call is_valid_bugaddr() at all. That usage can continue to
stay in lib/bug.c, which is only ever used by x86 during very early
boot, according to the comments in early_fixup_exception(). So just a
direct replacement of is_valid_bugaddr() with the proposed get_ud_type()
should be fine in arch/x86/kernel/traps.c.

What do you think?

-- 
Kees Cook