bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue building gnulib with clang (as used in GRUB)


From: Darren Kenny
Subject: Issue building gnulib with clang (as used in GRUB)
Date: Thu, 24 Mar 2022 17:16:35 +0000

Hi, 

I'm working on some issues in GRUB, which some of you may know requires
a subset of gnulib to be built in to it.

I'm seeing a failure due to the use of variable length arrays when
building with clang, versions 11 and 13, which I'm not seeing when
building with GCC. 

The error that I amd seeing looks like:

    clang -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EMU=1
    -DGRUB_MACHINE=X86_64_EMU -I../include -I../include -DGR
    In file included from commands/regexp.c:28:
    ../grub-core/lib/gnulib/regex.h:682:20: error: variable length array used 
[-Werror,-Wvla]
                                            _REGEX_NELTS (__nmatch)],
                                                        ^~~~~~~~
    ../grub-core/lib/gnulib/regex.h:528:27: note: expanded from macro 
'_REGEX_NELTS'
    #  define _REGEX_NELTS(n) n
                            ^
    1 error generated.
    make[2]: *** [Makefile:41321: commands/regexp_module-regexp.o] Error 1

After reading up a bit on it, it looks like 'variable length arrays' (VLA)
are where there is an array size in an argument, or stack variable, that is 
based
on the value of another variable - not a constant. The possible
security issue is that this size variable can be manipulated
to enable mis-use via a stack overflow, enabling the possible
manipulation of other data on the stack.

>From what I've read the Linux Kernel has disabled the use of variable
length arrays with the -Wvla option flagging it in any build, and it
looks like GRUB has that too - or at least it is being included in
certain builds, possibly with -Wall in later compilers.

GRUB recently updated the version of gnulib being pulled in to the SHA:

- 9f48fb992a3d7e96610c4ce8be969cff2d61a01b

which I know is not the latest, but still fairly recent (Feb 2022).

In the regex.h file there is a specific piece of code to do what appears
to be is to disable -Wvla option for specific GCC versions.

    #if defined __GNUC__ && 4 < __GNUC__ + (6 <= __GNUC_MINOR__)
    # pragma GCC diagnostic push
    # pragma GCC diagnostic ignored "-Wvla"
    #endif

But this doesn't work for clang.

I also see in a commit that the intent is to ignore the use of VLAs for
the whole regex.c file:

    commit 56b322516f8471584c8c67d2f749ae635560eeca
    Author: Paul Eggert <eggert@cs.ucla.edu>
    Date:   Thu Aug 26 10:08:00 2021 -0700

        regex: use C99-style array arg syntax

        This should help with some static checking.
        Derived from a suggestion by Martin Sebor in:
        https://sourceware.org/pipermail/libc-alpha/2021-August/130336.html
        This also ports recent and relevant Glibc changes to Gnulib
        and prepares to copy back.
        * lib/cdefs.h (__ARG_NELTS): New macro.
        * lib/regex.c: Ignore -Wvla for the whole file.
        * lib/regex.h (_ARG_NELTS_, _Attr_access_): New macros.
        Ignore -Wvla when declaring regexec.
        * lib/regex.h (re_compile_pattern, re_search, re_search_2)
        (re_match, re_match_2, regcomp, regerror):
        Use _Attr_access_ where that could help static checking.
        * lib/regexec.c (regexec, __compat_regexec, re_copy_regs)
        (re_search_internal, proceed_next_node, push_fail_stack)
        (pop_fail_stack, set_regs, update_regs):
        Use __ARG_NELTS for each array parameter whose size is another arg,
        but which might be null.

I've tried building with the C flag -D__STDC_NO_VLA__, and this will get
it to build, but that seems like something that should only be defined
by a compiler and not a consumer of the gnulib code.

Is this a known issue when building with clang? Would you have any
suggestions on how to correctly resolve it?

Thanks,

Darren.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]