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
