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]
Date:   Fri, 15 Oct 2021 09:22:27 -0700
From:   "Andy Lutomirski" <>
To:     "Thomas Gleixner" <>,
        "Sami Tolvanen" <>,
        "the arch/x86 maintainers" <>
Cc:     "Kees Cook" <>,
        "Josh Poimboeuf" <>,
        "Peter Zijlstra (Intel)" <>,
        "Nathan Chancellor" <>,
        "Nick Desaulniers" <>,
        "Sedat Dilek" <>,
        "Steven Rostedt" <>,,
        "Linux Kernel Mailing List" <>,
Subject: Re: [PATCH v5 03/15] linkage: Add DECLARE_NOT_CALLED_FROM_C

On Fri, Oct 15, 2021, at 8:55 AM, Thomas Gleixner wrote:
> On Thu, Oct 14 2021 at 19:51, Andy Lutomirski wrote:
>> On Wed, Oct 13, 2021, at 11:16 AM, Sami Tolvanen wrote:
>>> +/*
>>> + * Declares a function not callable from C using an opaque type. Defined as
>>> + * an array to allow the address of the symbol to be taken without '&'.
>>> + */
>> I’m not convinced that taking the address without using & is a
>> laudable goal.  The magical arrays-are-pointers-too behavior of C is a
>> mistake, not a delightful simplification.
>>> +#define DECLARE_NOT_CALLED_FROM_C(sym) \
>>> +	extern const u8 sym[]
>>> +#endif
>> The relevant property of these symbols isn’t that they’re not called
>> from C.  The relevant thing is that they are just and not objects of a
>> type that the programmer cares to tell the compiler about. (Or that
>> the compiler understands, for that matter. On a system with XO memory
>> or if they’re in a funny section, dereferencing them may fail.)
> I agree.
>> So I think we should use incomplete structs, which can’t be
>> dereferenced and will therefore be less error prone.
> While being late to that bike shed painting party, I really have to ask
> the question _why_ can't the compiler provide an annotation for these
> kind of things which:
>     1) Make the build fail when invoked directly
>     2) Tell CFI that this is _NOT_ something it can understand
> -void clear_page_erms(void *page);
> +void __bikeshedme clear_page_erms(void *page);
> That still tells me:
>     1) This is a function
>     2) It has a regular argument which is expected to be in RDI
> which even allows to do analyis of e.g. the alternative call which
> invokes that function.
> DECLARE_NOT_CALLED_FROM_C(clear_page_erms);
> loses these properties and IMO it's a tasteless hack.

Ah, but clear_page_erms is a different beast entirely as compared to, say, the syscall entry. It *is* a C function.  So I see two ways to handle it:

1. Make it completely opaque.  Tglx doesn’t like it, and I agree, but it would *work*.

2. Make it a correctly typed function. In clang CFI land, this may or may not be “canonical” (or non canonical?).

I think #2 is far better. I complained about this quite a few versions ago, and, sorry, the word “canonical” is pretty much a non-starter. There needs to be a way to annotate a function pointer type and an extern function declaration that says “the callee follows the ABI *without CFI*” and the compiler needs to do the right thing. And whatever attribute or keyword gets used needs to give the reader at least some chance of understanding.

(If there is a technical reason why function *pointers* of this type can’t be called, perhaps involving IBT, so be it.  But the type system should really be aware of C-ABI functions that come from outside the CFI world.)

It looks like clear_page might be improved by using static_call some day, and then proper typing will be a requirement.

Would it help if I file a clang bug about this?

Powered by blists - more mailing lists