Source: urweb
Version: 20170720+dfsg-2

Ur/Web’s C runtime currently builds with -D_FORTIFY_SOURCE=2 (really,
with DEB_BUILD_MAINT_OPTIONS=hardening=+all), since it’s a library in
the serving path. However, the runtime makes heavy use of %n format
specifiers, and _FORTIFY_SOURCE=2 causes that format specifier to be
incredibly slow:

    /tmp$ cat stuff.c
    #include <stdio.h>
    int main(int argc, char* argv[]) {
      int n;
      for (int i = 0; i < 1000000; ++i) {
        printf("%s%n\n", argv[1], &n);
        printf("%d\n", n);
    /tmp$ gcc -O3 -o stuff stuff.c
    /tmp$ time ./stuff 'Hello, world!' >/dev/null
    real    0m0.167s
    user    0m0.167s
    sys     0m0.000s
    /tmp$ gcc -O3 -D_FORTIFY_SOURCE=1 -o stuff stuff.c
    /tmp$ time ./stuff 'Hello, world!' >/dev/null
    real    0m0.170s
    user    0m0.170s
    sys     0m0.000s
    /tmp$ gcc -O3 -D_FORTIFY_SOURCE=2 -o stuff stuff.c
    /tmp$ time ./stuff 'Hello, world!' >/dev/null
    real    0m8.605s
    user    0m2.058s
    sys     0m6.482s

This has been confirmed to affect Ur/Web benchmark results [1, 2].
(Short version: TechEmpower switched from a custom build of Ur/Web to
using the package out of the archive and observed a 100× slowdown.)

One of Ur/Web’s major selling points is its speed, and while hardening
is valuable, users are likely to be surprised by Debian shipping an
Ur/Web that runs orders of magnitude slower than published benchmark
results. We should probably force _FORTIFY_SOURCE=1 in Ur/Web builds.


Reply via email to