PATCH: compile redis with stack-protector, _FORTIFY_SOURCE=2 and PIE for extra security.

[GoogleCodeExporter]

Hello,

this patch modifies the Makefiles to compile redis (and dependencies) with gcc 
flags for extra security.

This was tested on linux/amd64, linux-2.6.33, gcc-4.4.3 with no significant 
impact in performance on redis-benchmark.

benchmark results with default redis.conf,
on my linux/x86_64 (kernel:2.6.33, gcc:4.4.3):

vanilla (git ci c086b85afb1f0f2d9aa76faa5a4c8536380670a2):
% src/redis-benchmark -q -n 100000
    PING: 58377.11 requests per second
    PING (multi bulk): 59701.50 requests per second
    MSET (10 keys, multi bulk): 60132.29 requests per second
    SET: 59559.26 requests per second
    GET: 59772.86 requests per second
    INCR: 62460.96 requests per second
    LPUSH: 60938.45 requests per second
    LPOP: 60864.27 requests per second
    SADD: 62305.30 requests per second
    SPOP: 59523.81 requests per second
    LPUSH (again, in order to bench LRANGE): 62383.03 requests per second
    LRANGE (first 100 elements): 36683.79 requests per second
    LRANGE (first 300 elements): 18395.88 requests per second
    LRANGE (first 450 elements): 13092.43 requests per second
    LRANGE (first 600 elements): 11316.06 requests per second

with patch applied:
% src/redis-benchmark -q -n 100000
    PING: 59630.29 requests per second
    PING (multi bulk): 59347.18 requests per second
    MSET (10 keys, multi bulk): 56306.30 requests per second
    SET: 61728.39 requests per second
    GET: 62189.05 requests per second
    INCR: 60204.70 requests per second
    LPUSH: 61996.28 requests per second
    LPOP: 58275.06 requests per second
    SADD: 61199.51 requests per second
    SPOP: 59559.26 requests per second
    LPUSH (again, in order to bench LRANGE): 62189.05 requests per second
    LRANGE (first 100 elements): 34662.05 requests per second
    LRANGE (first 300 elements): 16064.26 requests per second
    LRANGE (first 450 elements): 12490.63 requests per second
    LRANGE (first 600 elements): 9877.52 requests per second

please pull:
https://github.com/msf/redis/commit/e5fabd9cff1fe63e72d283482852472e68e53648

thank you.

Original issue reported on code.google.com by miguel.filipe on 19 Nov 2010 at 11:49

[GoogleCodeExporter]

Can you elaborate on the benefits of using these flags? Also, the CPU bound 
tests (LRANGE) are about 10% slower in the benchmarks you show. That's not 
really insignificant.

Original comment by pcnoordh...@gmail.com on 20 Nov 2010 at 9:49

[GoogleCodeExporter]

-fstack-protector, like the name suggests, protects the stack against stack 
smashing and stack buffer overflows.
for more detailed information, please see:
http://www.trl.ibm.com/projects/security/ssp/
http://linuxfromscratch.xtra-net.org/hlfs/view/unstable/glibc-2.4/chapter02/ssp.
html

FORTIFY_SOURCE is described in:
https://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28F
ORTIFY_SOURCE.29
this shouldn't have any impact in performance, since all the checks are compile 
time.

I will address PIE in another comment.

Original comment by miguel.filipe on 21 Nov 2010 at 1:48

[GoogleCodeExporter]

About -pie:

PIE: position independent code is used to obtain better address space layout 
randomization (ASLR, 
http://en.wikipedia.org/wiki/Address_space_layout_randomization)
This enables ASLR for data and bss segments of the executable.
Example of the difference in address space with and without PIE on a normal 
linux binary:
#include <stdio.h>
#include <stdlib.h>
char bss;
char data = 'a';
 int test(void)
 {
     char a;
     char *s;
     s = (char *) malloc(sizeof(char));
     printf("heap: %p\tstack: %p\tdata: %p\tbss: %p\n", s,&a, &data, &bss);
     free(s);
     return 0;
 }
int main(void)
{
    test();
    return 0;
}

compiled without PIE:
miguel@thinkpad ~/code/c (master) $ gcc -o mem mem.c 
miguel@thinkpad ~/code/c (master) $ for i in `seq 1 5`; do ./mem; done
heap: 0x1b56010 stack: 0x7fff5439a80f   data: 0x402030  bss: 0x402048
heap: 0x22f1010 stack: 0x7fff270c78df   data: 0x402030  bss: 0x402048
heap: 0xd0b010  stack: 0x7fff4826877f   data: 0x402030  bss: 0x402048
heap: 0x196e010 stack: 0x7fff808e398f   data: 0x402030  bss: 0x402048
heap: 0xd70010  stack: 0x7fffd59c835f   data: 0x402030  bss: 0x402048

compiled with PIE:
miguel@thinkpad ~/code/c (master) $ gcc -o mem mem.c -fPIC -pie
miguel@thinkpad ~/code/c (master) $ for i in `seq 1 5`; do ./mem; done
heap: 0x7f73c2a7e010    stack: 0x7fff3b62d01f   data: 0x7f73c1556038    bss: 
0x7f73c1556050
heap: 0x7f79bb64a010    stack: 0x7fffd766e06f   data: 0x7f79bb537038    bss: 
0x7f79bb537050
heap: 0x7f3a8b0ab010    stack: 0x7fff04655fef   data: 0x7f3a8a795038    bss: 
0x7f3a8a795050
heap: 0x7facc8689010    stack: 0x7fff16340ddf   data: 0x7facc845a038    bss: 
0x7facc845a050
heap: 0x7f4f119e5010    stack: 0x7fff1328591f   data: 0x7f4f11705038    bss: 
0x7f4f11705050

Original comment by miguel.filipe on 21 Nov 2010 at 1:54

[GoogleCodeExporter]

I can triage the performance issue. Its probably due to -fstack-protector.

If PIE & FORTIFY_SOURCE don't have significant performance impact, i'm 
proposing putting those in the CFLAGS.

Regarding -fstack-protector, it could eventually be made optional, just like 
tcmalloc..

I just proposed this things as a proactive security measure, since this is C 
code listening on the network.. 

Original comment by miguel.filipe on 22 Nov 2010 at 5:35