[prev in list] [next in list] [prev in thread] [next in thread]
List: netbsd-tech-userlevel
Subject: fortification
From: Iain Hibbert <plunky () ogmig ! net>
Date: 2015-09-03 20:59:00
Message-ID: alpine.NEB.2.11.1509022241320.5040 () galant ! ogmig ! net
[Download RAW message or body]
Hello
while I was looking at the ssp/fortification code, I noticed something..
the following code example
#include <string.h>
int a, b;
void foo(void)
{
memcpy(&a, &b, sizeof(a));
}
when preprocessed with fortification enabled
% gcc -fstack-protector -O2 -D_FORTIFY_SOURCE=2 -E -o test.i test.c
outputs basically the following code (I've added spaces and cut out the
unrelated parts)
static __inline void * __memcpy_ichk(void * __restrict__, const void * __restrict__, \
size_t);
static __inline __attribute__((__always_inline__)) void * __memcpy_ichk(void * \
__restrict__ dst, const void * __restrict__ src, size_t len) {
return __builtin___memcpy_chk(dst, src, len, __builtin_object_size(dst, 0));
}
int a, b;
void foo(void)
{
(
(__builtin_object_size(&a, 0) != (size_t)-1)
?
__builtin___memcpy_chk(&a, &b, sizeof(a), __builtin_object_size(&a, 0))
:
__memcpy_ichk(&a, &b, sizeof(a))
);
}
which seems like it is wrong, since both branches end up with the same
code.. should the inline __memcpy_ichk() function actually call
__memcpy_chk() from libc? I'm not sure of the rationale here..
regards,
iain
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic