Bug 100431 - Fixes to enable compiling with -Werror=format-security
Summary: Fixes to enable compiling with -Werror=format-security
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 11.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build, diagnostic, documentation
Depends on:
Blocks:
 
Reported: 2021-05-05 11:24 UTC by Joey Dumont
Modified: 2021-08-20 00:10 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Patch to fix -Werror=format-security errors (1.31 KB, application/mbox)
2021-05-05 11:24 UTC, Joey Dumont
Details
Workaround for -Wno-format flag injected during build process. (655 bytes, patch)
2021-05-05 11:25 UTC, Joey Dumont
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joey Dumont 2021-05-05 11:24:40 UTC
Created attachment 50757 [details]
Patch to fix -Werror=format-security errors

As mentioned in bug 100207, Arch Linux recently starting compiling its packages with the -Werror=format-security option. In this bug report, I attach two patches that enable compiling gcc with that flag. 

The first patch expliclity adds "%s" format strings to functions that pass its arguments to printf. 

However, during my testing, I found that libgcc uses -Wno-format in its CFLAGS, making the flags inconsistent. It seemed that adding the --enable-build-format-warnings should remove the -Wno-format option from the compile flags, but it didn't seem to work as expected, leading to errors like this: 

/build/gcc/src/gcc-build/./gcc/xgcc -B/build/gcc/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include   -fno-checking -g -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -m32 -O2  -g -march=x86-64 -mtune=generic -O2  -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS         -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../../.././gcc -I/build/gcc/src/gcc/libgcc -I/build/gcc/src/gcc/libgcc/. -I/build/gcc/src/gcc/libgcc/../gcc -I/build/gcc/src/gcc/libgcc/../include -I/build/gcc/src/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /build/gcc/src/gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security]

I am not sure how these flags are set. In any case, the second patch works around the issue by changing the --enable-build-format-warnings to add -Wno-format-security to the flags, making the flags consistent again.

I think the first patch is a genuine fix, but I'm not sure about the second. I would have expected --enable-build-format-warnings to entirely remove the -Wno-format option, but it seems to stick somewhere in the build process, and I can't see where.
Comment 1 Joey Dumont 2021-05-05 11:25:22 UTC
Created attachment 50758 [details]
Workaround for -Wno-format flag injected during build process.
Comment 2 Jakub Jelinek 2021-05-05 11:47:37 UTC
Comment on attachment 50757 [details]
Patch to fix -Werror=format-security errors

I doubt you have properly tested it, because it is clearly buggy.

          const char *message = (result & CPP_N_UNSIGNED) == CPP_N_UNSIGNED
                                ? N_("use of C++23 %<size_t%> integer constant")
                                : N_("use of C++23 %<make_signed_t<size_t>%> integer constant");
          cpp_warning_with_line (pfile, CPP_W_SIZE_T_LITERALS,
                                 virtual_location, 0, message);
Changing this to "%s", message obviously breaks it, it will not print
use of C++23 'size_t' integer constant (or with UTF-8 quotes etc. and with colors etc.), but
use of C++23 %<size_t%> integer constant
Comment 3 Joey Dumont 2021-05-11 13:45:18 UTC
I had tested with a simple printf: 

#include <stdio.h>

#ifndef N_
# define N_(msgid) msgid
#endif

int
main(int argc, char* argv[]) {
  printf(N_("use of C++23 %<size_t%> integer constant"));
  printf(N_("use of C++23 %<make_signed_t<size_t>%> integer constant"));

  return 0;
}

which prints the same thing with or without the "%s" format string. 

I've been trying to trace where pfile->cb.diagnostic is set to see how the output is actually processed, but I haven't found it yet. 

Thanks for the feedback!
Comment 4 Jakub Jelinek 2021-05-11 13:57:57 UTC
%< and %> are GCC diagnostics format specifiers, not printf.
They are more similar to e.g. GNU printf %m , something that doesn't take any va_arg, but is interpreted.
Try
printf ("%m\n");
vs.
printf ("%s", "%m\n");
to see the difference.
Anyway, for this case either using the conditional directly in the cpp_warning_with_line argument instead of in initializer of a temporary, or two cpp_warning_with_line calls each with a separate string would do.
Anyway, I strongly doubt your patch covers everything, I can see e.g.
gcc/c/c-convert.c:81:31: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c/c-typeck.c:3681:28: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c/c-typeck.c:4433:42: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c/c-typeck.c:6587:43: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c/c-typeck.c:11679:42: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c-family/c-common.c:6358:30: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/c-family/c-common.c:6362:33: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/fold-const.c:303:42: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/ipa-devirt.c:951:47: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/analyzer/program-state.cc:1153:20: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/diagnostic.c:1887:52: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/cp/cvt.c:725:26: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/cp/error.c:799:20: warning: spurious leading punctuation sequence ‘<’ in format [-Wformat-diag]
gcc/cp/error.c:799:20: warning: spurious trailing punctuation sequence ‘>’ in format [-Wformat-diag]
gcc/cp/error.c:799:20: warning: spurious leading punctuation sequence ‘<’ in format [-Wformat-diag]
gcc/cp/error.c:799:20: warning: spurious trailing punctuation sequence ‘>’ in format [-Wformat-diag]
gcc/cp/decl.c:3485:22: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/cp/typeck.c:4721:24: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/cp/typeck.c:6630:24: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/cp/pt.c:19640:20: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/collect2.c:2422:37: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/collect-utils.c:200:37: warning: format not a string literal and no format arguments [-Wformat-security]
gcc/lto-wrapper.c:1606:31: warning: format not a string literal and no format arguments [-Wformat-security]
and you've only touched the gcc/diagnostic.c case from that.
Comment 5 Joey Dumont 2021-06-20 02:33:07 UTC
I just started looking at these other cases (for some reason I didn't see them in my initial compilation), but I am not sure what format specifiers should be used. Are the format specifiers used by __gcc_tdiag__ documented somewhere? I tried grepping through the source, but couldn't find anything.