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: <875xu7rzeg.ffs@tglx>
Date: Tue, 18 Jun 2024 00:13:27 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Kees Cook <kees@...nel.org>
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 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.

Thanks,

        tglx