unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex Vong <alexvong1995@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH 1/2] Add (guix build build-flags).
Date: Fri, 25 Dec 2015 23:38:28 +0800	[thread overview]
Message-ID: <87k2o2a68b.fsf@gmail.com> (raw)
In-Reply-To: <878u6caz6z.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 05 Nov 2015 22:55:32 +0100")

ludo@gnu.org (Ludovic Courtès) writes:

Hi,

This is an old thread, but I am still unclear of something, so I will
reply.

> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
>> From: Alex Vong <alexvong1995@gmail.com>
>> Date: Sat, 31 Oct 2015 19:44:13 +0800
>> Subject: [PATCH 1/2] Add (guix build build-flags).
>>
>> A module to manipulate build flags, similar to dpkg-buildflags.
>>
>> * guix/build/build-flags.scm: New file.
>> * Makefile.am (MODULES): Register it.
>
> [...]
>
>> +;;; Module to manipulate build flags, similar to dpkg-buildflags.
>
> It doesn’t really help to refer to dpkg-buildflags, at least for me.  ;-)
>
Sure, I should have elaborated more on it. What I am looking for are
ways to avoid repeating a lot of flags in different packages, something
like `use this set of flags, please'. For example, in Debian, if you
type

$ dpkg-buildflags --get CFLAGS

you get

-g -O2 -fstack-protector-strong -Wformat -Werror=format-security

which are thr default flags to be exported during package
build. Moroever, maintainer can alter the default behaviour by setting
DEB_BUILD_MAINT_OPTIONS. For example,

$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS

will return

-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security

>> +;;; Data structure <flag-list> is constructed by flag-list.
>> +;;; The constructor flag-list does something to its arguments,
>> +;;; such as trimming white-spaces, to ensure no two arguments mean the same.
>> +;;;
>> +;;; Here is an example:
>> +;;; (define default-flag-list
>> +;;;   (flag-list
>> +;;;    #:CFLAGS '("-O2" "-g")
>> +;;;    #:LDFLAGS '("-lm" "-lpthread")))
>> +;;;
>> +;;; flag-list+ and flag-list- are analogous to
>> +;;; numeric + and - but operate on <flag-list>.
>> +;;;
>> +;;; flag-list->string-list converts <flag-list> into
>> +;;; configure-flags-compatible string-list.
>
> How would we use flag lists?
>
> The problem is that each build system has its own way to specify custom
> flags, and some don’t even allow that.  So being able to manipulate flag
> lists is nice, but I’m afraid we wouldn’t be able to make much out of
> them.
>
> WDYT?
>
>> +(define-syntax define-record-type-with-accessor-list
>> +  (syntax-rules ()
>> +    "Macro to define a srfi-9 record
>> +with accessor list bound to accessor-list-name.
>
> Is this really needed?  Would ‘define-record-type*’ from (guix records)
> do the job?
>
>> +(define-record-type-with-accessor-list <flag-list>
>> +  (make-flag-list c-flags
>> +                  cpp-flags
>> +                  c++-flags
>> +                  fc-flags
>> +                  f-flags
>> +                  gcj-flags
>> +                  ld-flags
>> +                  objc-flags
>> +                  objc++-flags)
>
> I’m not convinced we need to list all these flags, but again, that
> depends on how we end up using it.
>
> On one hand that’s already too many flags, and we’d be passing the same
> options to all of them anyway–like -fstack-protector, -fPIE, etc.
>
> On the other hand, it’s very much GCC- and autotool-centric.
>
> [...]
>
>> +(define fortify-flag-list
>> +  (flag-list
>> +   #:CPPFLAGS '("-D_FORTIFY_SOURCE=2")))
>> +
>> +(define stackprotector-flag-list
>> +  (flag-list
>> +   #:CFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:CXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:FCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:FFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:GCJFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:OBJCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> +   #:OBJCXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")))
>> +
>> +(define stackprotectorstrong-flag-list
>> +  (flag-list
>> +   #:CFLAGS '("-fstack-protector-strong")
>> +   #:CXXFLAGS '("-fstack-protector-strong")
>> +   #:FCFLAGS '("-fstack-protector-strong")
>> +   #:FFLAGS '("-fstack-protector-strong")
>> +   #:GCJFLAGS '("-fstack-protector-strong")
>> +   #:OBJCFLAGS '("-fstack-protector-strong")
>> +   #:OBJCXXFLAGS '("-fstack-protector-strong")))
>
> I’ve been thinking we should experiment with these various options.  The
> way I’d do it now would be by running:
>
>   ./configure x y z CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-fstack-protector
>
> This would be just automatically added to #:configure-flags in
> gnu-build-system.scm.
>
> Of course, some packages would ignore them and others would break, but
> that’s part of the game.  It largely have to be approached on a
> case-by-case basis.
>
Yes, I grep for `fstack-protector-strong' in the guix code base and no
matches are found. It appears no packages are setting this flag
currently. I think this flag (perhaps also a couple others) should be
set by default since they help protect against buffer overflow
<https://en.wikipedia.org/wiki/Buffer_overflow_protection>.

> Thoughts?
>
> Ludo’.

How do you people think?

Cheers,
Alex

  reply	other threads:[~2015-12-25 15:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-31 13:56 [PATCH 1/2] Add (guix build build-flags) Alex Vong
2015-11-05 21:55 ` Ludovic Courtès
2015-12-25 15:38   ` Alex Vong [this message]
2015-12-30 16:06     ` Hardening Ludovic Courtès
2016-08-16 23:57       ` Hardening Leo Famulari
2016-08-17  6:49         ` Hardening Ricardo Wurmus
2016-08-17 13:48           ` Hardening Alex Vong
2016-08-17 20:28             ` Hardening ng0
2016-08-19  9:30               ` Hardening ng0
2016-08-20 16:45               ` Hardening Alex Vong
2016-09-02 13:08         ` Hardening Ludovic Courtès
2016-09-03 11:34           ` Hardening ng0
  -- strict thread matches above, loose matches on Subject: below --
2015-10-25  6:11 [PATCH 1/2] Add (guix build build-flags) Alex Vong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2o2a68b.fsf@gmail.com \
    --to=alexvong1995@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).