[cfe-dev] How clang compares with gcc on security hardening ?

[Amara Emerson via cfe-dev]

FYI, I will be upstreaming a new implementation of stack checking support for Darwin enabled by -fstack-check in the near future, for arm64 and x86_64.

However, these will be Darwin specific as we will have a custom ABI and multiple stack checking techniques to achieve this. Other platforms are welcome to adapt the patches and standardize on an ABI (for arm64, for x86 we use the existing ABI from the windows stack probing implementation).

Amara

> On Feb 19, 2019, at 2:23 PM, Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 02/19/2019 01:47 PM, via cfe-dev wrote:
>> TL;DR: I think "lags significantly" is overstating the case.  The only feature I can identify that Clang doesn't have (wrt the things brought up in that Fedora post) is a real `-fstack-clash-protection` implementation.
>> 
>> 
>> 
>> I read through that post a couple of times looking for a list, and eventually noticed a reference to
>> 
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
>> 
>> which is probably as close to an actual list of security options as we're going to get (it talks about many different options and doesn't explicitly call out those that are security-related).  Between that reference and other comments in the Fedora issue, the list is probably something like this:
>> 
>> 
>> 
>> -fstack-protector-strong
>> 
>> Clang has this.
>> 
> 
> This comment mentions possible bugs in clang's implementation:
> https://pagure.io/fesco/issue/2020#comment-546820 <https://pagure.io/fesco/issue/2020#comment-546820>
> 
> 
>> 
>> 
>> -fcf-protection
>> 
>> Clang has this.
>> 
>> 
>> 
>> -D_FORTIFY_SOURCE=2
>> 
>> AFAICT, Clang supports what is needed by this.
>> 
>> Being a preprocessor symbol, this is mostly about glibc changes to support protections on various unsafe library calls; those in turn depend on a pile of builtins, which are likely the ones implemented in this GCC patch:
>> 
>> https://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
>> 
>> I see a bunch of builtins with these sorts of names in Clang, so if nobody has filed bugs, I suspect this should all work (when using glibc).
>> 
>> 
>> 
>> -fstack-clash-protection
>> 
>> Clang does not recognize this option. Curiously I see two patches to add it, neither of them has been committed. I think there's a reasonable argument that a key security option should not be recognized and ignored.
>> 
> 
> I agree. When I wrote https://reviews.llvm.org/D42593 <https://reviews.llvm.org/D42593>, I
> thought it would be OK to ignore, because -fstack-check
> was also ignored, but I changed my mind after Joerg's comment.
> 
> -Tom
> 
>> FTR, the `buildflags.md` documentation says this keeps large stack allocations from skipping over a check of the guard page.
>> 
>> 
>> 
>> @Sylvestre do you want to file a bug requesting this option?
>> 
>> 
>> 
>> --paulr
>> 
>> 
>> 
>> *From:*cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of *Sylvestre Ledru via cfe-dev
>> *Sent:* Tuesday, February 19, 2019 2:43 PM
>> *To:* clang Development List
>> *Subject:* [cfe-dev] How clang compares with gcc on security hardening ?
>> 
>> 
>> 
>> Hello,
>> 
>> Looking at a Fedora thread ( https://pagure.io/fesco/issue/2020 ) about changing the compiler from gcc to clang to build Firefox,
>> I noticed the following statement:
>> 
>> "Clang lags significantly behind GCC on security hardening"
>> 
>> Some of the arguments or missing features are discussed here:
>> 
>> https://pagure.io/fesco/issue/2020#comment-546825 and other answers
>> https://pagure.io/fesco/issue/2020#comment-545776
>> 
>> I am wondering if these statements are accurate and if they are enough of a worry?
>> 
>> Thanks,
>> Sylvestre
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190219/51d92a3b/attachment.html>