RFC: GCC plugin to find encrypted function pointer calls in glibc

[Aldy Hernandez]

On 05/04/2016 09:59 AM, Carlos O'Donell wrote:
> On 04/30/2016 11:57 AM, Aldy Hernandez wrote:
>> I take it option 3 is too disgusting, provided #1 is a no go?  That
>> is, adding a carefully crafted comment at the end of an inline asm
>> string?
>
> Option 3 is a non-starter.
>
> I think a static inline wrapper is going to be just fine if the compiler
> does a good job of the generated code.

It does, and if it doesn't, it's a compiler bug that must be fixed.

>
>> Errr, and by the way, is it a requirement that this plugin work with
>> 4.7?  Because, we only need this for static analysis.  Is building
>> glibc twice a no go (once with the plugin for static analysis, and
>> once for building the actual production code)?  I thought the purpose
>> of the plugin was just to analyze what's already there, but I do see
>> the benefit of using the same compiler for static analysis _and_ for
>> building the library.
>
> You misunderstood. Let me clarify. If you add new attributes to the source
> then the compiler that compiles glibc must know about those new attributes
> or we must conditionally enable/disable them. If we conditionally enable
> and disable them, then this will seriously impact the output of the plugin
> in ways which aren't immediately obvious. Consider building with an older
> gcc, and now the plugin (using a newer gcc) starts raising lots of errors.
> The gcc used to build glibc should not have a material impact on the results
> of the plugin.

You can leave the attributes enabled unconditionally.  GCC ignores 
unknown attributes, so the old compiler compiling the attributed source 
will behave as usual.

However, you will get an "unknown attribute ignored" warning with -Wall, 
but you can easily silence that particular warning just for the wrapper:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wattributes"
static inline void
__attribute__((SOME_POSSIBLY_UNKNOWN_ATTRIBUTE))
wrapper_function (void)
{
}
#pragma GCC diagnostic pop

>
>> If the same compiler is a requirement, the plugin requires some
>> rewriting, because unfortunately, the plugin infrastructure is a
>> moving API target.  I doubt a plugin for GCC 6 will even compile the
>> boiler plate nonsense we need for another GCC version (and vice
>> versa).
>
> That's fine.
>
> What I would like to see is:
>
> (a) In-tree plugins.
> (b) A configure option to enable the plugins (default disabled for now).
>      * Enables source markers to use the appropriate attributes.
>      * Builds the plugins.
> (c) Make it a hard error if a compiler recent enough to build them is
>      not present.
>
> This way the individual developers can use CI to do a glibc build with
> this option enabled and look for errors.

Sounds good.  I'll leave Florian and the rest of you glibc gurus to 
those details :).

Aldy