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 17:55:22 +0200
From:   Thomas Gleixner <>
To:     Andy Lutomirski <>,
        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 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.


loses these properties and IMO it's a tasteless hack.



Powered by blists - more mailing lists