N.B. clang-style FORTIFY can cause existing code to not compile. These issues are primarily things like redeclarations of standard library functions, and code like:

unsigned char foo[20];
strcpy(foo, "hi"); // unsigned char -> char conversion makes clang sad.

I'll be tagging all of the fixes like ^ with this bug.

If you're interested in why this is the case, it's because clang-style FORTIFY relies *heavily* on overloads. Yes, even in C; we use the overloadable attribute for that. This approach has a few quirks:

- Because overloads in C are surprising, `overloadable` needs to be present on every function decl. If it's not, clang emits an error. So, redeclarations of standard library functions inside of not-glibc turns into an error.

- Clang uses C++'s overload resolution rules when resolving overloads in C. This is mostly fine, except when a C-only conversion needs to take place when calling a function. Implicitly casting from an (unsigned char*) to a (char*) is a "C-only conversion," and ends up emitting a warning without FORTIFY. With FORTIFY, this warning becomes an error, since there's no suitable candidate that takes an (unsigned char*), and converting that to a (char*) is illegal. (N.B. Clang will allow this conversion to take place if there is otherwise only one viable candidate, but if there are multiple, we need to make the conversion from (unsigned char*) to (char*) explicit.)

FWIW, the changes that "fix" said issues are:

https://chromium-review.googlesource.com/372264
https://chromium-review.googlesource.com/372340
https://chromium-review.googlesource.com/372478
https://chromium-review.googlesource.com/#/c/372322/
https://chromium-review.googlesource.com/#/c/372400/
https://chromium-review.googlesource.com/#/c/372401/
https://chromium-review.googlesource.com/#/c/372460/
https://chromium-review.googlesource.com/372479
https://chromium-review.googlesource.com/372265

We have 3 other known breakages with no fix. I'll work on those now. :)

(Those are split out, because the fixes for those may not be as trivial as the above.)

In general, we should not change contents in portage-stable. They are supposed to be the same as the upstream Gentoo. If you really need to change something, you should copy it to chromiumos-overlay repository instead.

I add vapier@ for further clarification.

ideally these patches should be sent upstream, and then we can add them to Gentoo, and then we can pull them into CrOS.  it's never too early to `git send-email` a patch to an upstream project.

that process is going to be time consuming. If needed can we put temporary local patches in portage-stable?

> ideally these patches should be sent upstream, and then we can add them to Gentoo, and then we can pull them into CrOS

Sounds good -- I'll see what I can do about about cleaning these up + upstreaming them tomorrow. Thanks for the tip. :)

Like llozano said, though, we are trying to get this stuff in soon; do you have recommendations for how we can temporarily apply these patches until we pull them from upstream? (...If that's not possible, we *can* work around it by applying special compiler flags specifically to these projects, but I think having these patches applied would be better, if possible.)

https://bugs.chromium.org/p/chromium/issues/detail?id=640358 now tracks the bugfix efforts.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/0041b82475abca323297cf866589af40a2bd227f

commit 0041b82475abca323297cf866589af40a2bd227f
Author: Yunlian Jiang <yunlian@chromium.org>
Date: Mon Aug 22 22:58:58 2016

sed: upgrade to 4.2.2

This pulls upstream sed 4.2.2. It fixes a but when
building with clang fortify.

BUG= chromium:638456 
TEST=cbuildbot chromiumos-sdk falco-release

Change-Id: I48cb04ea63ac1ee2bb9759d63e034bc0a4a07fca
Reviewed-on: https://chromium-review.googlesource.com/374042
Commit-Ready: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[rename] https://crrev.com/0041b82475abca323297cf866589af40a2bd227f/sys-apps/sed/sed-4.2.2.ebuild
[delete] https://crrev.com/d83372d347dc855051ae4ba3ca1768eafc27c754/sys-apps/sed/files/dos2unix
[modify] https://crrev.com/0041b82475abca323297cf866589af40a2bd227f/sys-apps/sed/Manifest
[delete] https://crrev.com/d83372d347dc855051ae4ba3ca1768eafc27c754/sys-apps/sed/files/sed-4.2.1-handle-incomplete-sequences-as-if-they-were-invalid.patch
[delete] https://crrev.com/d83372d347dc855051ae4ba3ca1768eafc27c754/sys-apps/sed/files/unix2dos

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/ltp/+/946757d51bb96a280fc4ebe156fa1ad63d9dba13

commit 946757d51bb96a280fc4ebe156fa1ad63d9dba13
Author: George Burgess IV <gbiv@google.com>
Date: Wed Aug 24 03:21:11 2016

ltp: don't memcpy into function pointers.

This cherry-picks the following two commits:

commit beea06f31d0fd8c9000768c237a23d4ab3d01456
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Wed Sep 2 16:43:42 2015 +0200

    syscalls/mprotect04: Fix for ia64

    IA64 ABI calls functions by function descriptors and because of that we
    cannot simply copy function address since the address we get in C is
    addres of the function descriptor and not the function itself.

    Instead of that we copy a code for a minimal function to the mmaped page
    and create a function descriptor for it.

    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

commit e2b6ca1179cd96b77e32fd0fa281bb0491f7d80d
Author: Jan Stancek <jstancek@redhat.com>
Date:   Wed Sep 9 13:00:01 2015 +0200

    mprotect04: fix powerpc crash when copying exec_func

    Testcase tried to copy page size area starting at &exec_func.
    This results in crash on powerpc, because &exec_func is too close
    to end of page and subsequent page is not mapped:

     10000000-10010000 r-xp 00000000 fd:00 402855 mprotect04
     10010000-10020000 rw-p 00000000 fd:00 402855 mprotect04
     806a410000-806a440000 r-xp 00000000 fd:00 2097827 /lib64/ld-2.12.so
    where &exec_func == 0x100199c0, and page_size == 65536.

    It's also worth noting, that function ptr does not reside in .text,
    but in .opd section. That shouldn't matter for this testcase as long
    as it doesn't try to copy non-existent pages.

    This patch is changing copy function to try copy 2 whole aligned pages.
    Both pages are checked to be present in memory before memcpy is
    attempted. First is the page which contains &exec_func, and 2nd is the
    subsequent page - for the case &exec_func is too close to page boundary.

    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Acked-by: Cyril Hrubis <chrubis@suse.cz>

BUG= chromium:638456 
TEST=emerge-x86-generic with clang-FORTIFY enabled is now happy about memcpy.

Change-Id: I0f77b9c4b5baa8edfbc7062c4fc9fb324aacb20e
Reviewed-on: https://chromium-review.googlesource.com/374860
Commit-Ready: George Burgess <gbiv@google.com>
Tested-by: George Burgess <gbiv@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/946757d51bb96a280fc4ebe156fa1ad63d9dba13/testcases/kernel/syscalls/mprotect/mprotect04.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/4d7337a41b8c2b3da83a29f1dc8766eedb6e4ecf

commit 4d7337a41b8c2b3da83a29f1dc8766eedb6e4ecf
Author: George Burgess IV <gbiv@google.com>
Date: Thu Aug 11 00:34:09 2016

glibc: add clang-style FORTIFY.

This patch adds support for a clang-style FORTIFY to ChromeOS's glibc.

Without this, when we swap to clang as the default compiler for
ChromeOS, our FORTIFY story will get *way* worse. When given a gcc-style
FORTIFY, clang is unable to emit just about any compile-time
diagnostics, and the dynamic checks that clang emits is a (small) subset
of gcc's.

This patch makes clang's diagnostic story nearly on-par with gcc's, and
should allow clang to dynamically catch just about any bug that gcc can
(either statically or dynamically). Due to differences in how the
compilers work (e.g. how they optimize code, etc.), there may be cases
where clang detects errors at run-time where gcc can't and vice-versa.

BUG= chromium:638456 
TEST=Lots of buildbot runs. (Primarily peppy, oak, and daisy, but ~14
different configurations were tested in all.)

Change-Id: I66489b82bafc59f93a3cc7d78278451ccf654ddc
Reviewed-on: https://chromium-review.googlesource.com/368220
Commit-Ready: George Burgess <gbiv@chromium.org>
Tested-by: Luis Lozano <llozano@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
Reviewed-by: Luis Lozano <llozano@chromium.org>

[add] https://crrev.com/4d7337a41b8c2b3da83a29f1dc8766eedb6e4ecf/sys-libs/glibc/files/local/glibc-2.19-clang-fortify.patch
[rename] https://crrev.com/4d7337a41b8c2b3da83a29f1dc8766eedb6e4ecf/sys-libs/glibc/glibc-2.19-r13.ebuild

Woo!

Hi guys, I see that strongswan-clang-fortify-fix.patch is not upstream yet.  If it is still needed, could you please with with the maintainers to pull it into their project so it doesn't need to be maintained out of tree forever?

FWIW: I built strongSwan ToT on my workstation with no changes, although I am not sure if this procedure mirrors what you're testing:

CC="clang-3.5 -D_FORTIFY_SOURCE=2" ./configure && make

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/8b43c24a66f03d96575ea3294b4a5c1c7d13b2ba

commit 8b43c24a66f03d96575ea3294b4a5c1c7d13b2ba
Author: George Burgess IV <gbiv@google.com>
Date: Tue Nov 08 22:45:45 2016

strongswan: remove clang FORTIFY hacks

This patch was necessary before we made clang more lenient about
incompatible pointer type conversions. Now that clang doesn't get as
upset about e.g. passing an `unsigned char*` as a `char*` when calling
an overloaded function, we can remove it.

BUG= chromium:638456 
TEST=Still builds with clang FORTIFY enabled.

Change-Id: I77b93e479feefebafc7a67e1c564ee1ff8e1615f
Reviewed-on: https://chromium-review.googlesource.com/408719
Commit-Ready: George Burgess <gbiv@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[delete] https://crrev.com/33a80a35c80e0d595f43544d8867224877a2fc98/net-misc/strongswan/files/strongswan-clang-fortify-fix.patch
[rename] https://crrev.com/8b43c24a66f03d96575ea3294b4a5c1c7d13b2ba/net-misc/strongswan/strongswan-5.0.2-r20.ebuild
[modify] https://crrev.com/8b43c24a66f03d96575ea3294b4a5c1c7d13b2ba/net-misc/strongswan/strongswan-5.0.2.ebuild

Closing. Please reopen it if its not fixed. Thanks!