diff options
author | Siddhesh Poyarekar <siddhesh@sourceware.org> | 2021-10-12 12:29:13 +0530 |
---|---|---|
committer | Siddhesh Poyarekar <siddhesh@sourceware.org> | 2021-10-20 08:33:31 +0530 |
commit | e938c02748402c50f60ba0eb983273e7b52937d1 (patch) | |
tree | 5784cd55dd66558fbdef877150dac886b1b09e5d /misc | |
parent | 46baeb61e16511f26db1b255e19dc9163f590367 (diff) | |
download | glibc-e938c02748402c50f60ba0eb983273e7b52937d1.tar glibc-e938c02748402c50f60ba0eb983273e7b52937d1.tar.gz glibc-e938c02748402c50f60ba0eb983273e7b52937d1.tar.bz2 glibc-e938c02748402c50f60ba0eb983273e7b52937d1.zip |
Don't add access size hints to fortifiable functions
In the context of a function definition, the size hints imply that the
size of an object pointed to by one parameter is another parameter.
This doesn't make sense for the fortified versions of the functions
since that's the bit it's trying to validate.
This is harmless with __builtin_object_size since it has fairly simple
semantics when it comes to objects passed as function parameters.
With __builtin_dynamic_object_size we could (as my patchset for gcc[1]
already does) use the access attribute to determine the object size in
the general case but it misleads the fortified functions.
Basically the problem occurs when access attributes are present on
regular functions that have inline fortified definitions to generate
_chk variants; the attributes get inherited by these definitions,
causing problems when analyzing them. For example with poll(fds, nfds,
timeout), nfds is hinted using the __attr_access as being the size of
fds.
Now, when analyzing the inline function definition in bits/poll2.h, the
compiler sees that nfds is the size of fds and tries to use that
information in the function body. In _FORTIFY_SOURCE=3 case, where the
object size could be a non-constant expression, this information results
in the conclusion that nfds is the size of fds, which defeats the
purpose of the implementation because we're trying to check here if nfds
does indeed represent the size of fds. Hence for this case, it is best
to not have the access attribute.
With the attributes gone, the expression evaluation should get delayed
until the function is actually inlined into its destinations.
Disable the access attribute for fortified function inline functions
when building at _FORTIFY_SOURCE=3 to make this work better. The
access attributes remain for the _chk variants since they can be used
by the compiler to warn when the caller is passing invalid arguments.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581125.html
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Diffstat (limited to 'misc')
-rw-r--r-- | misc/sys/cdefs.h | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index 4dac9d264d..f6ab95ab81 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -605,12 +605,22 @@ _Static_assert (0, "IEEE 128-bits long double requires redirection on this platf size-index is not provided: access (access-mode, <ref-index> [, <size-index>]) */ # define __attr_access(x) __attribute__ ((__access__ x)) +/* For _FORTIFY_SOURCE == 3 we use __builtin_dynamic_object_size, which may + use the access attribute to get object sizes from function definition + arguments, so we can't use them on functions we fortify. Drop the object + size hints for such functions. */ +# if __USE_FORTIFY_LEVEL == 3 +# define __fortified_attr_access(a, o, s) __attribute__ ((__access__ (a, o))) +# else +# define __fortified_attr_access(a, o, s) __attr_access ((a, o, s)) +# endif # if __GNUC_PREREQ (11, 0) # define __attr_access_none(argno) __attribute__ ((__access__ (__none__, argno))) # else # define __attr_access_none(argno) # endif #else +# define __fortified_attr_access(a, o, s) # define __attr_access(x) # define __attr_access_none(argno) #endif |