Hardened toolchain

Hardened toolchain

[zimoun]

Hi,

> I posted an initial message on help-guix about compiling a custom
> hardened gcc, but guix-devel is a better list to continue the
> discussion. I wanted to revisit compiling Guix packages with a
> hardened toolchain since many other distros do this to improve the
> security of their packages.

On help-guix, you mean this [1], right?

1: <https://yhetil.org/guix/MtzBL4o--3-2@tutanota.com/>


> Previous emails only mentioned passing hardening options to CFLAGS and
> LDFLAGS. Another important step is to compile features into GCC and
> binutils.  Specifically:

> * gcc can be compiled with `--enable-default-ssp --enable-default-pie`
> to enforce ssp and pic

You wrote [1]:

--8<---------------cut here---------------start------------->8---
(define-public gcc
  (package
    (inherit gcc)
    (arguments
     (substitute-keyword-arguments (package-arguments gcc)
     ((#:configure-flags flags
       `(append (list "--enable-default-ssp" "--enable-default-pie")
            ,flags)))))))
--8<---------------cut here---------------end--------------->8---

and from my understanding, it can lead to name clash because the symbol
'gcc' (define-public gcc) and the symbol 'gcc' (inherit gcc) are the
same but does not refer to the same thing.

Instead, let define as gcc-hardened or whatever else than 'gcc'.  Note
that it could be better to define a procedure taking a GCC package and
returning it with "hardened" options.  Untested,

--8<---------------cut here---------------start------------->8---
(define (make-gcc-hardened gcc)
  (package
    (inherit gcc)
    (arguments
     (substitute-keyword-arguments (package-arguments gcc)
     ((#:configure-flags flags
       `(append (list "--enable-default-ssp" "--enable-default-pie")
            ,flags)))))))

(define-public gcc-hardened
  (make-gcc-hardened gcc))
--8<---------------cut here---------------end--------------->8---

This way, it becomes easy to also get GCC@7 using such options.


> * binutils can be compiled with `--enable-relro --enable-pic` to
> enforce relro and pic

Yes.  Indeed, you need to adapt various tools from "gcc-toolchain" with
these hardened options.


> I'm not a toolchain expert by any means, but I think this is a good
> first step in improving Guix package security.

Once you have a new hardened gcc-toolchain, then you can use a package
transformation (with-c-toolchain) and recompile all the graph using this
new hardened gcc-toolchain for the packages you are interested in.

Include such and provide binary substitutes is another question. :-)
(maintenance burden, etc.)


Hope that helps

Cheers,
simon

Re: Hardened toolchain

[zimoun]

Hi,

(Although you know :) please keep CC guix-devel.) 


On Tue, 22 Mar 2022 at 18:23, kiasoc5@tutanota.com wrote:

>> --8<---------------cut here---------------start------------->8---
>> (define (make-gcc-hardened gcc)
>>  (package
>>  (inherit gcc)
>>  (arguments
>>  (substitute-keyword-arguments (package-arguments gcc)
>>  ((#:configure-flags flags
>>  `(append (list "--enable-default-ssp" "--enable-default-pie")
>>  ,flags)))))))
>>
>> (define-public gcc-hardened
>>  (make-gcc-hardened gcc))
>> --8<---------------cut here---------------end--------------->8---

[...]

>
> I get an error when I build with guix, if you could help find it that
> would be great.
>
> % ./pre-inst-env guix build -f hardened.scm
> /home/kiasoc5/build/guix-notes/hardening/hardened.scm:11:10: error: (substitute-keyword-arguments (package-arguments gcc) ((#:configure-flags flags (quasiquote (append (list "--enable-default-ssp" "--enable-default-pie") (unquote flags)))))): source expression failed to match any pattern

That’s because a typo. :-)

    ((#:configure-flags flags
                             ^

missing closing parenthesis.  Well, it looks like:

--8<---------------cut here---------------start------------->8---
(use-modules (gnu)
             (guix)
             (guix packages))

(use-package-modules gcc)

(define (make-gcc-hardened gcc)
  (package
    (inherit gcc)
    (arguments
     (substitute-keyword-arguments (package-arguments gcc)
       ((#:configure-flags flags)
        `(append (list "--enable-default-ssp"
                       "--enable-default-pie")
                 ,flags))))))

(define-public gcc-hardened
  (make-gcc-hardened gcc))

gcc-hardened
--8<---------------cut here---------------end--------------->8---

Then, this command

    guix build -f hardened.scm -n

returns:

--8<---------------cut here---------------start------------->8---
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation would be built:
   /gnu/store/3i6i3pqr5r7l1568b3hswbgych974aqw-gcc-10.3.0.drv
81.4 MB would be downloaded:
   /gnu/store/7vrx4p62bkmxzrxwqdc4il9hqyh1yngh-libstdc++-10.3.0
   /gnu/store/i459ksarhxysqb8gxa8hq6phl13d0q4a-libstdc++-headers-10.3.0
   /gnu/store/d3js6699lc1p0sw7p0dkafi0cn33sig6-gcc-10.3.0.tar.xz
--8<---------------cut here---------------end--------------->8---

I do not have tried to effectively build this gcc-hardened. :-)

Hope that helps.

Cheers,
simon

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Mar 22, 2022, 19:06 by zimon.toutoune@gmail.com:

> Hi,
>
> (Although you know :) please keep CC guix-devel.) 
>
Will remember to CC guix-devel next time.

> On Tue, 22 Mar 2022 at 18:23, kiasoc5@tutanota.com wrote:
>
>>> --8<---------------cut here---------------start------------->8---
>>> (define (make-gcc-hardened gcc)
>>>  (package
>>>  (inherit gcc)
>>>  (arguments
>>>  (substitute-keyword-arguments (package-arguments gcc)
>>>  ((#:configure-flags flags
>>>  `(append (list "--enable-default-ssp" "--enable-default-pie")
>>>  ,flags)))))))
>>>
>>> (define-public gcc-hardened
>>>  (make-gcc-hardened gcc))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>
> [...]
>
>>
>> I get an error when I build with guix, if you could help find it that
>> would be great.
>>
>> % ./pre-inst-env guix build -f hardened.scm
>> /home/kiasoc5/build/guix-notes/hardening/hardened.scm:11:10: error: (substitute-keyword-arguments (package-arguments gcc) ((#:configure-flags flags (quasiquote (append (list "--enable-default-ssp" "--enable-default-pie") (unquote flags)))))): source expression failed to match any pattern
>>
>
> That’s because a typo. :-)
>
Silly me, thanks for the catch. I'll let you know how the hardened gcc goes.

>  ((#:configure-flags flags
>  ^missing closing parenthesis.  Well, it looks like:
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (gnu)
>  (guix)
>  (guix packages))
>
> (use-package-modules gcc)
>
> (define (make-gcc-hardened gcc)
>  (package
>  (inherit gcc)
>  (arguments
>  (substitute-keyword-arguments (package-arguments gcc)
>  ((#:configure-flags flags)
>  `(append (list "--enable-default-ssp"
>  "--enable-default-pie")
>  ,flags))))))
>
> (define-public gcc-hardened
>  (make-gcc-hardened gcc))
>
> gcc-hardened
> --8<---------------cut here---------------end--------------->8---
>
> Then, this command
>
>  guix build -f hardened.scm -n
>
> returns:
>
> --8<---------------cut here---------------start------------->8---
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
> The following derivation would be built:
>  /gnu/store/3i6i3pqr5r7l1568b3hswbgych974aqw-gcc-10.3.0.drv
> 81.4 MB would be downloaded:
>  /gnu/store/7vrx4p62bkmxzrxwqdc4il9hqyh1yngh-libstdc++-10.3.0
>  /gnu/store/i459ksarhxysqb8gxa8hq6phl13d0q4a-libstdc++-headers-10.3.0
>  /gnu/store/d3js6699lc1p0sw7p0dkafi0cn33sig6-gcc-10.3.0.tar.xz
> --8<---------------cut here---------------end--------------->8---
>
> I do not have tried to effectively build this gcc-hardened. :-)
>
> Hope that helps.
>
> Cheers,
> simon
>

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

I managed to build hardened-gcc and hardened-binutils with the regular toolchain. Now I'm building them with a hardened C toolchain:

====hardened.scm====
(use-modules (gnu)
             (guix)
             (guix packages))

(use-package-modules gcc base commencement)

(define (make-gcc-hardened gcc)
  (package
    (inherit gcc)
    (arguments
     (substitute-keyword-arguments (package-arguments gcc)
       ((#:configure-flags flags)
        `(append (list "--enable-default-ssp"
                       "--enable-default-pie")
             ,flags))))))

(define-public gcc-hardened
  (make-gcc-hardened gcc))

(define (make-binutils-hardened binutils)
  (package
    (inherit binutils)
    (arguments
      (substitute-keyword-arguments (package-arguments binutils)
        ((#:configure-flags flags)
         `(append (list "--enable-relro"
                        "--enable-pic"
                        "--with-pic")
              ,flags))))))

(define-public binutils-hardened
  (make-binutils-hardened binutils))

(define-public gcc-toolchain-hardened
  (make-gcc-toolchain gcc-hardened))

;; TODO: apply binutils hardening
;; TODO: recompile graph with this toolchain
(define (package-with-c-toolchain-hardened package)
  (package-with-c-toolchain package `(("toolchain" ,gcc-toolchain-hardened)
                                      ("binutils" ,binutils-hardened))))

(define c-toolchain-packages
  (list gcc-hardened binutils-hardened))

;; gcc-hardened fails
(map package-with-c-toolchain-hardened c-toolchain-packages)
====hardened.scm====

I can build binutils-hardened with the hardened toolchain but not gcc-hardened:

====the middle of guix build -f hardened.scm====
building /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv...
Backtrace:
In ice-9/eval.scm:
   217:50 19 (lp (#<procedure 7ffff3fff5e0 at ice-9/eval.scm:282:?> ?))
   217:50 18 (lp (#<procedure 7ffff3fff580 at ice-9/eval.scm:282:?> ?))
   217:50 17 (lp (#<procedure 7ffff3fff4c0 at ice-9/eval.scm:649:?> ?))
   217:50 16 (lp (#<procedure 7ffff3fff300 at ice-9/eval.scm:282:?> ?))
   217:50 15 (lp (#<procedure 7ffff3fff2a0 at ice-9/eval.scm:649:?> ?))
   217:50 14 (lp (#<procedure 7ffff3fff140 at ice-9/eval.scm:282:?> ?))
   217:50 13 (lp (#<procedure 7ffff3fff120 at ice-9/eval.scm:282:?> ?))
   217:50 12 (lp (#<procedure 7ffff3fff100 at ice-9/eval.scm:282:?> ?))
   217:50 11 (lp (#<procedure 7ffff2c01f40 at ice-9/eval.scm:649:?> ?))
   217:50 10 (lp (#<procedure 7ffff2c01f20 at ice-9/eval.scm:282:?> ?))
   217:50  9 (lp (#<procedure 7ffff2c01f00 at ice-9/eval.scm:282:?> ?))
   217:50  8 (lp (#<procedure 7ffff2c01ee0 at ice-9/eval.scm:282:?> ?))
   217:50  7 (lp (#<procedure 7ffff2c01e80 at ice-9/eval.scm:649:?> ?))
   217:50  6 (lp (#<procedure 7ffff2c01e60 at ice-9/eval.scm:282:?> ?))
   217:50  5 (lp (#<procedure 7ffff2c20ed0 at ice-9/eval.scm:196:?> ?))
   217:50  4 (lp (#<procedure 7ffff2c01d20 at ice-9/eval.scm:282:?> ?))
   217:33  3 (lp (#<procedure 7ffff2c01b20 at ice-9/eval.scm:649:?> ?))
    159:9  2 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
    159:9  1 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
In unknown file:
           0 (string-append "LDFLAGS=" "-Wl,-rpath=" #f "/lib " "-W?" ?)

ERROR: In procedure string-append:
In procedure string-append: Wrong type (expecting string): #f
builder for `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed with exit code 1
build of /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv failed
View build log at '/var/log/guix/drvs/1n/lrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv.gz'.
guix build: error: build of `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed
====the middle of guix build -f hardened.scm====

I think #f is here because (assoc-ref inputs "gcc") returns #f since the toolchain uses gcc-hardened, not gcc. Any tips?

Thanks!

Mar 22, 2022, 20:02 by kiasoc5@tutanota.com:

> Mar 22, 2022, 19:06 by zimon.toutoune@gmail.com:
>
>> Hi,
>>
>> (Although you know :) please keep CC guix-devel.) 
>>
> Will remember to CC guix-devel next time.
>
>> On Tue, 22 Mar 2022 at 18:23, kiasoc5@tutanota.com wrote:
>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> (define (make-gcc-hardened gcc)
>>>> (package
>>>> (inherit gcc)
>>>> (arguments
>>>> (substitute-keyword-arguments (package-arguments gcc)
>>>> ((#:configure-flags flags
>>>> `(append (list "--enable-default-ssp" "--enable-default-pie")
>>>> ,flags)))))))
>>>>
>>>> (define-public gcc-hardened
>>>> (make-gcc-hardened gcc))
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>
>> [...]
>>
>>>
>>> I get an error when I build with guix, if you could help find it that
>>> would be great.
>>>
>>> % ./pre-inst-env guix build -f hardened.scm
>>> /home/kiasoc5/build/guix-notes/hardening/hardened.scm:11:10: error: (substitute-keyword-arguments (package-arguments gcc) ((#:configure-flags flags (quasiquote (append (list "--enable-default-ssp" "--enable-default-pie") (unquote flags)))))): source expression failed to match any pattern
>>>
>>
>> That’s because a typo. :-)
>>
> Silly me, thanks for the catch. I'll let you know how the hardened gcc goes.
>
>> ((#:configure-flags flags
>> ^missing closing parenthesis.  Well, it looks like:
>>
>> --8<---------------cut here---------------start------------->8---
>> (use-modules (gnu)
>> (guix)
>> (guix packages))
>>
>> (use-package-modules gcc)
>>
>> (define (make-gcc-hardened gcc)
>> (package
>> (inherit gcc)
>> (arguments
>> (substitute-keyword-arguments (package-arguments gcc)
>> ((#:configure-flags flags)
>> `(append (list "--enable-default-ssp"
>> "--enable-default-pie")
>> ,flags))))))
>>
>> (define-public gcc-hardened
>> (make-gcc-hardened gcc))
>>
>> gcc-hardened
>> --8<---------------cut here---------------end--------------->8---
>>
>> Then, this command
>>
>> guix build -f hardened.scm -n
>>
>> returns:
>>
>> --8<---------------cut here---------------start------------->8---
>> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> The following derivation would be built:
>> /gnu/store/3i6i3pqr5r7l1568b3hswbgych974aqw-gcc-10.3.0.drv
>> 81.4 MB would be downloaded:
>> /gnu/store/7vrx4p62bkmxzrxwqdc4il9hqyh1yngh-libstdc++-10.3.0
>> /gnu/store/i459ksarhxysqb8gxa8hq6phl13d0q4a-libstdc++-headers-10.3.0
>> /gnu/store/d3js6699lc1p0sw7p0dkafi0cn33sig6-gcc-10.3.0.tar.xz
>> --8<---------------cut here---------------end--------------->8---
>>
>> I do not have tried to effectively build this gcc-hardened. :-)
>>
>> Hope that helps.
>>
>> Cheers,
>> simon
>>
>
>

Re: Hardened toolchain

[zimoun]

Hi,

On Fri, 25 Mar 2022 at 20:39, kiasoc5@tutanota.com wrote:

> ====the middle of guix build -f hardened.scm====
> building /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv...
> Backtrace:
> In ice-9/eval.scm:
>    217:50 19 (lp (#<procedure 7ffff3fff5e0 at ice-9/eval.scm:282:?> ?))
>    217:50 18 (lp (#<procedure 7ffff3fff580 at ice-9/eval.scm:282:?> ?))
>    217:50 17 (lp (#<procedure 7ffff3fff4c0 at ice-9/eval.scm:649:?> ?))
>    217:50 16 (lp (#<procedure 7ffff3fff300 at ice-9/eval.scm:282:?> ?))
>    217:50 15 (lp (#<procedure 7ffff3fff2a0 at ice-9/eval.scm:649:?> ?))
>    217:50 14 (lp (#<procedure 7ffff3fff140 at ice-9/eval.scm:282:?> ?))
>    217:50 13 (lp (#<procedure 7ffff3fff120 at ice-9/eval.scm:282:?> ?))
>    217:50 12 (lp (#<procedure 7ffff3fff100 at ice-9/eval.scm:282:?> ?))
>    217:50 11 (lp (#<procedure 7ffff2c01f40 at ice-9/eval.scm:649:?> ?))
>    217:50 10 (lp (#<procedure 7ffff2c01f20 at ice-9/eval.scm:282:?> ?))
>    217:50  9 (lp (#<procedure 7ffff2c01f00 at ice-9/eval.scm:282:?> ?))
>    217:50  8 (lp (#<procedure 7ffff2c01ee0 at ice-9/eval.scm:282:?> ?))
>    217:50  7 (lp (#<procedure 7ffff2c01e80 at ice-9/eval.scm:649:?> ?))
>    217:50  6 (lp (#<procedure 7ffff2c01e60 at ice-9/eval.scm:282:?> ?))
>    217:50  5 (lp (#<procedure 7ffff2c20ed0 at ice-9/eval.scm:196:?> ?))
>    217:50  4 (lp (#<procedure 7ffff2c01d20 at ice-9/eval.scm:282:?> ?))
>    217:33  3 (lp (#<procedure 7ffff2c01b20 at ice-9/eval.scm:649:?> ?))
>     159:9  2 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
>     159:9  1 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
> In unknown file:
>            0 (string-append "LDFLAGS=" "-Wl,-rpath=" #f "/lib " "-W?" ?)
>
> ERROR: In procedure string-append:
> In procedure string-append: Wrong type (expecting string): #f
> builder for `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed with exit code 1
> build of /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv failed
> View build log at '/var/log/guix/drvs/1n/lrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv.gz'.
> guix build: error: build of `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed
> ====the middle of guix build -f hardened.scm====

You are creating a cycle, no?  It is not a DAG and so the transformation
fails, no?

For instance, this:

--8<---------------cut here---------------start------------->8---
(use-modules (guix packages)
             (gnu packages gcc)
             (gnu packages base))

(define make-gcc-toolchain
  (@@ (gnu packages commencement) make-gcc-toolchain))

(define gcc-bis
  (package
    (inherit gcc)
    (version (string-append (package-version gcc) "-bis"))))

(define gcc-toolchain-bis
  (make-gcc-toolchain gcc-bis glibc))

(define (package-with-c-toolchain-bis package)
  (package-with-c-toolchain
   package `(("toolchain" ,gcc-toolchain-bis))))


(package-with-c-toolchain-bis gcc-bis)
--8<---------------cut here---------------end--------------->8---

fails with the same message.  There is bootstrapping issue: the binary
of gcc-bis is required to compile the source of gcc-bis; where does come
from such binary of gcc-bis?


Considering your use case, you need:

 - gcc considered as binary seed
 
 - use this binary gcc with the hardened options to compile the source
   of GCC; resulting to the binary gcc-hardened-1

 - use this binary gcc-hardened-2 with the hardened options to recompile
   the source of GCC; resulting to the binary gcc-hardened-2

 - if checksum(gcc-hardened-1) == checksum(gcc-hardened-2)
   then use this binary to define a new toolchain
   else reach the fixed point

fixed point: use this binary gcc-hardened-{n-1} to compile the source of
  GCC and output the binary gcc-hardened-{n}; compare the checksum of
  the binary {n-1} and {n} and repeat until equality is reached.

Guix is not auto-magically resolving the fixed-point, i.e., it does not
unroll the cycle by magic. :-) You have to do it manually or write code
for automatise the process; described above.


Hope that helps.

Cheers,
simon

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Hi Simon,

Mar 25, 2022, 22:54 by zimon.toutoune@gmail.com:

> Hi,
>
> On Fri, 25 Mar 2022 at 20:39, kiasoc5@tutanota.com wrote:
>
>> ====the middle of guix build -f hardened.scm====
>> building /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv...
>> Backtrace:
>> In ice-9/eval.scm:
>>    217:50 19 (lp (#<procedure 7ffff3fff5e0 at ice-9/eval.scm:282:?> ?))
>>    217:50 18 (lp (#<procedure 7ffff3fff580 at ice-9/eval.scm:282:?> ?))
>>    217:50 17 (lp (#<procedure 7ffff3fff4c0 at ice-9/eval.scm:649:?> ?))
>>    217:50 16 (lp (#<procedure 7ffff3fff300 at ice-9/eval.scm:282:?> ?))
>>    217:50 15 (lp (#<procedure 7ffff3fff2a0 at ice-9/eval.scm:649:?> ?))
>>    217:50 14 (lp (#<procedure 7ffff3fff140 at ice-9/eval.scm:282:?> ?))
>>    217:50 13 (lp (#<procedure 7ffff3fff120 at ice-9/eval.scm:282:?> ?))
>>    217:50 12 (lp (#<procedure 7ffff3fff100 at ice-9/eval.scm:282:?> ?))
>>    217:50 11 (lp (#<procedure 7ffff2c01f40 at ice-9/eval.scm:649:?> ?))
>>    217:50 10 (lp (#<procedure 7ffff2c01f20 at ice-9/eval.scm:282:?> ?))
>>    217:50  9 (lp (#<procedure 7ffff2c01f00 at ice-9/eval.scm:282:?> ?))
>>    217:50  8 (lp (#<procedure 7ffff2c01ee0 at ice-9/eval.scm:282:?> ?))
>>    217:50  7 (lp (#<procedure 7ffff2c01e80 at ice-9/eval.scm:649:?> ?))
>>    217:50  6 (lp (#<procedure 7ffff2c01e60 at ice-9/eval.scm:282:?> ?))
>>    217:50  5 (lp (#<procedure 7ffff2c20ed0 at ice-9/eval.scm:196:?> ?))
>>    217:50  4 (lp (#<procedure 7ffff2c01d20 at ice-9/eval.scm:282:?> ?))
>>    217:33  3 (lp (#<procedure 7ffff2c01b20 at ice-9/eval.scm:649:?> ?))
>>     159:9  2 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
>>     159:9  1 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
>> In unknown file:
>>            0 (string-append "LDFLAGS=" "-Wl,-rpath=" #f "/lib " "-W?" ?)
>>
>> ERROR: In procedure string-append:
>> In procedure string-append: Wrong type (expecting string): #f
>> builder for `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed with exit code 1
>> build of /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv failed
>> View build log at '/var/log/guix/drvs/1n/lrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv.gz'.
>> guix build: error: build of `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed
>> ====the middle of guix build -f hardened.scm====
>>
>
> You are creating a cycle, no?  It is not a DAG and so the transformation
> fails, no?
>
Oh I didn't notice that. The example makes sense too.

> For instance, this:
>
> --8<---------------cut here---------------start------------->8---
> (use-modules (guix packages)
>  (gnu packages gcc)
>  (gnu packages base))
>
> (define make-gcc-toolchain
>  (@@ (gnu packages commencement) make-gcc-toolchain))
>
> (define gcc-bis
>  (package
>  (inherit gcc)
>  (version (string-append (package-version gcc) "-bis"))))
>
> (define gcc-toolchain-bis
>  (make-gcc-toolchain gcc-bis glibc))
>
> (define (package-with-c-toolchain-bis package)
>  (package-with-c-toolchain
>  package `(("toolchain" ,gcc-toolchain-bis))))
>
>
> (package-with-c-toolchain-bis gcc-bis)
> --8<---------------cut here---------------end--------------->8---
>
> fails with the same message.  There is bootstrapping issue: the binary
> of gcc-bis is required to compile the source of gcc-bis; where does come
> from such binary of gcc-bis?
>
>
> Considering your use case, you need:
>
>  - gcc considered as binary seed
>  
>  - use this binary gcc with the hardened options to compile the source
>  of GCC; resulting to the binary gcc-hardened-1
>
>  - use this binary gcc-hardened-2 with the hardened options to recompile
>  the source of GCC; resulting to the binary gcc-hardened-2
>
>  - if checksum(gcc-hardened-1) == checksum(gcc-hardened-2)
>  then use this binary to define a new toolchain
>  else reach the fixed point
>
> fixed point: use this binary gcc-hardened-{n-1} to compile the source of
>  GCC and output the binary gcc-hardened-{n}; compare the checksum of
>  the binary {n-1} and {n} and repeat until equality is reached.
>
Just so I understand, in other (imperative) words:

gcc-hardened-1 = gcc-hardened built with regular gcc
gcc-hardened-2 = gcc-hardened built with gcc-hardened-1
n = 1
while checksum(gcc-hardened-{n}) != checksum(gcc-hardened-{n+1}):
   gcc-hardened-{n+1} = gcc-hardened built with gcc-hardened-{n}
   n++
define the new toolchain with gcc-hardened-{n+1}


> Guix is not auto-magically resolving the fixed-point, i.e., it does not
> unroll the cycle by magic. :-) You have to do it manually or write code
> for automatise the process; described above.
>
Thanks, are there any examples in the code base that would be a good reference?

>
> Hope that helps.
>
> Cheers,
> simon
>

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Mar 26, 2022, 19:33 by kiasoc5@tutanota.com:

> Hi Simon,
>
> Mar 25, 2022, 22:54 by zimon.toutoune@gmail.com:
>
>> Hi,
>>
>> On Fri, 25 Mar 2022 at 20:39, kiasoc5@tutanota.com wrote:
>>
>>> ====the middle of guix build -f hardened.scm====
>>> building /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv...
>>> Backtrace:
>>> In ice-9/eval.scm:
>>>    217:50 19 (lp (#<procedure 7ffff3fff5e0 at ice-9/eval.scm:282:?> ?))
>>>    217:50 18 (lp (#<procedure 7ffff3fff580 at ice-9/eval.scm:282:?> ?))
>>>    217:50 17 (lp (#<procedure 7ffff3fff4c0 at ice-9/eval.scm:649:?> ?))
>>>    217:50 16 (lp (#<procedure 7ffff3fff300 at ice-9/eval.scm:282:?> ?))
>>>    217:50 15 (lp (#<procedure 7ffff3fff2a0 at ice-9/eval.scm:649:?> ?))
>>>    217:50 14 (lp (#<procedure 7ffff3fff140 at ice-9/eval.scm:282:?> ?))
>>>    217:50 13 (lp (#<procedure 7ffff3fff120 at ice-9/eval.scm:282:?> ?))
>>>    217:50 12 (lp (#<procedure 7ffff3fff100 at ice-9/eval.scm:282:?> ?))
>>>    217:50 11 (lp (#<procedure 7ffff2c01f40 at ice-9/eval.scm:649:?> ?))
>>>    217:50 10 (lp (#<procedure 7ffff2c01f20 at ice-9/eval.scm:282:?> ?))
>>>    217:50  9 (lp (#<procedure 7ffff2c01f00 at ice-9/eval.scm:282:?> ?))
>>>    217:50  8 (lp (#<procedure 7ffff2c01ee0 at ice-9/eval.scm:282:?> ?))
>>>    217:50  7 (lp (#<procedure 7ffff2c01e80 at ice-9/eval.scm:649:?> ?))
>>>    217:50  6 (lp (#<procedure 7ffff2c01e60 at ice-9/eval.scm:282:?> ?))
>>>    217:50  5 (lp (#<procedure 7ffff2c20ed0 at ice-9/eval.scm:196:?> ?))
>>>    217:50  4 (lp (#<procedure 7ffff2c01d20 at ice-9/eval.scm:282:?> ?))
>>>    217:33  3 (lp (#<procedure 7ffff2c01b20 at ice-9/eval.scm:649:?> ?))
>>>     159:9  2 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
>>>     159:9  1 (_ #(#(#<directory (guile-user) 7ffff3fd7c80> #f) #f))
>>> In unknown file:
>>>            0 (string-append "LDFLAGS=" "-Wl,-rpath=" #f "/lib " "-W?" ?)
>>>
>>> ERROR: In procedure string-append:
>>> In procedure string-append: Wrong type (expecting string): #f
>>> builder for `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed with exit code 1
>>> build of /gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv failed
>>> View build log at '/var/log/guix/drvs/1n/lrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv.gz'.
>>> guix build: error: build of `/gnu/store/1nlrgg5ryl486haw0kdqnbp4wa17lhwh-gcc-10.3.0.drv' failed
>>> ====the middle of guix build -f hardened.scm====
>>>

Here's a smaller example that has the same error:
===the file===
(use-modules (gnu)
             (guix)
             (guix packages))

(use-package-modules gcc base commencement)

(package-with-c-toolchain gcc `(("toolchain" ,(make-gcc-toolchain gcc))))
===the file===
===try to build it===
In unknown file:
           0 (string-append "LDFLAGS=" "-Wl,-rpath=" #f "/lib " "-W?" ?)

ERROR: In procedure string-append:
In procedure string-append: Wrong type (expecting string): #f
===try to build it===

The gcc package already exists! Why can't I build gcc with itself?


>> You are creating a cycle, no?  It is not a DAG and so the transformation
>> fails, no?
>>
> Oh I didn't notice that. The example makes sense too.
>
>> For instance, this:
>>
>> --8<---------------cut here---------------start------------->8---
>> (use-modules (guix packages)
>> (gnu packages gcc)
>> (gnu packages base))
>>
>> (define make-gcc-toolchain
>> (@@ (gnu packages commencement) make-gcc-toolchain))
>>
>> (define gcc-bis
>> (package
>> (inherit gcc)
>> (version (string-append (package-version gcc) "-bis"))))
>>
>> (define gcc-toolchain-bis
>> (make-gcc-toolchain gcc-bis glibc))
>>
>> (define (package-with-c-toolchain-bis package)
>> (package-with-c-toolchain
>> package `(("toolchain" ,gcc-toolchain-bis))))
>>
>>
>> (package-with-c-toolchain-bis gcc-bis)
>> --8<---------------cut here---------------end--------------->8---
>>
>> fails with the same message.  There is bootstrapping issue: the binary
>> of gcc-bis is required to compile the source of gcc-bis; where does come
>> from such binary of gcc-bis?
>>
>>
>> Considering your use case, you need:
>>
>> - gcc considered as binary seed
>>
>> - use this binary gcc with the hardened options to compile the source
>> of GCC; resulting to the binary gcc-hardened-1
>>
>> - use this binary gcc-hardened-2 with the hardened options to recompile
>> the source of GCC; resulting to the binary gcc-hardened-2
>>
>> - if checksum(gcc-hardened-1) == checksum(gcc-hardened-2)
>> then use this binary to define a new toolchain
>> else reach the fixed point
>>
>> fixed point: use this binary gcc-hardened-{n-1} to compile the source of
>> GCC and output the binary gcc-hardened-{n}; compare the checksum of
>> the binary {n-1} and {n} and repeat until equality is reached.
>>
> Just so I understand, in other (imperative) words:
>
> gcc-hardened-1 = gcc-hardened built with regular gcc
> gcc-hardened-2 = gcc-hardened built with gcc-hardened-1
> n = 1
> while checksum(gcc-hardened-{n}) != checksum(gcc-hardened-{n+1}):
>    gcc-hardened-{n+1} = gcc-hardened built with gcc-hardened-{n}
>    n++
> define the new toolchain with gcc-hardened-{n+1}
>
>
>> Guix is not auto-magically resolving the fixed-point, i.e., it does not
>> unroll the cycle by magic. :-) You have to do it manually or write code
>> for automatise the process; described above.
>>
> Thanks, are there any examples in the code base that would be a good reference?
>
>>
>> Hope that helps.
>>
>> Cheers,
>> simon
>>
>
>

Re: Hardened toolchain

[zimoun]

Hi,

On Sat, 26 Mar 2022 at 20:33, kiasoc5@tutanota.com wrote:

> Just so I understand, in other (imperative) words:
>
> gcc-hardened-1 = gcc-hardened built with regular gcc
> gcc-hardened-2 = gcc-hardened built with gcc-hardened-1
> n = 1
> while checksum(gcc-hardened-{n}) != checksum(gcc-hardened-{n+1}):
>    gcc-hardened-{n+1} = gcc-hardened built with gcc-hardened-{n}
>    n++
> define the new toolchain with gcc-hardened-{n+1}

To be totally correct:

binary gcc-hardened-1 = source gcc-hardened built with binary gcc
binary gcc-hardened-2 = source gcc-hardened built with binary gcc-hardened-1

where ’binary gcc’ is the binary seed of the bootstrap.



>> Guix is not auto-magically resolving the fixed-point, i.e., it does not
>> unroll the cycle by magic. :-) You have to do it manually or write code
>> for automatise the process; described above.
>>
> Thanks, are there any examples in the code base that would be a good
> reference?

(gnu packages commencement), I guess.


On Sat, 26 Mar 2022 at 23:02, kiasoc5@tutanota.com wrote:

> Here's a smaller example that has the same error:
>
> ===the file===
> (use-modules (gnu)
>              (guix)
>              (guix packages))
>
> (use-package-modules gcc base commencement)
>
> (package-with-c-toolchain gcc `(("toolchain" ,(make-gcc-toolchain gcc))))
> ===the file===

[...]

> The gcc package already exists! Why can't I build gcc with itself?

Well, the symbol ’gcc’ can refer to 3 things:

 - source
 - recipe for building the source
 - binary
 
Maybe I misunderstand you, but it appears to me that you want:

    binary1 = recipe built with binary0

but because ’package-with-c-toolchain’ is recursive, it reads, instead:

    binary0 = recipe built with binary0

so, it is a cycle.  You cannot build binary0 using this very same
binary0.

Therefore, you have to tweak and manually write the chain, i.e., unroll
the cycle.  For example, gcc-hardened-boot build with gcc (seed), then
gcc-hardened built with gcc-hardened-boot.  Once you have this binary
gcc-hardened, you can use it with package-with-c-toolchain; however, not
for rebuilding gcc-hardened-boot or gcc-hardened, otherwise you are
introducing a cycle.


Hope that helps.

Cheers,
simon

Re: Hardened toolchain

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
> > * gcc can be compiled with `--enable-default-ssp --enable-default-
> > pie`
> > to enforce ssp and pic
> 
> You wrote [1]:
> 
> --8<---------------cut here---------------start------------->8---
> (define-public gcc
>   (package
>     (inherit gcc)
>     (arguments
>      (substitute-keyword-arguments (package-arguments gcc)
>      ((#:configure-flags flags
>        `(append (list "--enable-default-ssp" "--enable-default-pie")
>             ,flags)))))))
> --8<---------------cut here---------------end--------------->8---

I think it would be a lot simpler to just add this to the 'standard'
gcc configure flags, in (gnu packages gcc), given that probably the
idea is to do this hardening for all packages?  Needs a world-rebuild
though.

Alternatively, the ssp and order hardening flags can be set in CFLAGS
for individual packages, maybe by default in 'gnu-build-system' and the
like.

Alternatively, you could look into how "--with-c-toolchain" does
things.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Hardened toolchain

[Maxim Cournoyer]

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

> zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
>> > * gcc can be compiled with `--enable-default-ssp --enable-default-
>> > pie`
>> > to enforce ssp and pic
>> 
>> You wrote [1]:
>> 
>> --8<---------------cut here---------------start------------->8---
>> (define-public gcc
>>   (package
>>     (inherit gcc)
>>     (arguments
>>      (substitute-keyword-arguments (package-arguments gcc)
>>      ((#:configure-flags flags
>>        `(append (list "--enable-default-ssp" "--enable-default-pie")
>>             ,flags)))))))
>> --8<---------------cut here---------------end--------------->8---
>
> I think it would be a lot simpler to just add this to the 'standard'
> gcc configure flags, in (gnu packages gcc), given that probably the
> idea is to do this hardening for all packages?  Needs a world-rebuild
> though.

+1.  The whole distribution can probably benefit from this hardening.

Maxim

Re: Hardened toolchain

[zimoun]

Hi,

On Sun, 27 Mar 2022 at 23:17, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> Maxime Devos <maximedevos@telenet.be> writes:

>> I think it would be a lot simpler to just add this to the 'standard'
>> gcc configure flags, in (gnu packages gcc), given that probably the
>> idea is to do this hardening for all packages?  Needs a world-rebuild
>> though.
>
> +1.  The whole distribution can probably benefit from this hardening.

(Parenthesis, the initial question is about how to create a custom gcc,
somehow whatever the options are about, and my answers are in this
direction and not in supporting directly in Guix some variants or even
create a new upstream .  To me, that “a lot simpler” is orthogonal. :-)
Closing parenthesis.)


Yes, for sure, it can be a good idea to follow the “Arch Linux” hardened
flags.  The two question I have are:

 1. Is it well-supported for cross-compiling?

 2. Do we introduce the hardened flags for compiling the hardened
 compiler?  Other said, at which bootstrap level in the chain do we
 introduce these hardened options?


Cheers,
simon

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Yes it would be easier to add the hardening flags to gcc directly, I just wasn't sure whether the maintainers would be open to the idea.

Since the default gcc toolchain version is still on gcc 10, the hardening flags could be added to gcc 11. Then the upgrade from gcc toolchain 10 to 11 can benefit from the hardening flags, and "only" 1 world rebuild is needed.

Mar 28, 2022, 03:17 by maxim.cournoyer@gmail.com:

> Hi,
>
> Maxime Devos <maximedevos@telenet.be> writes:
>
>> zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
>>
>>> > * gcc can be compiled with `--enable-default-ssp --enable-default-
>>> > pie`
>>> > to enforce ssp and pic
>>>
>>> You wrote [1]:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (define-public gcc
>>>   (package
>>>     (inherit gcc)
>>>     (arguments
>>>      (substitute-keyword-arguments (package-arguments gcc)
>>>      ((#:configure-flags flags
>>>        `(append (list "--enable-default-ssp" "--enable-default-pie")
>>>             ,flags)))))))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>
>> I think it would be a lot simpler to just add this to the 'standard'
>> gcc configure flags, in (gnu packages gcc), given that probably the
>> idea is to do this hardening for all packages?  Needs a world-rebuild
>> though.
>>
>
> +1.  The whole distribution can probably benefit from this hardening.
>
> Maxim
>

Re: Hardened toolchain

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Maxime Devos <maximedevos@telenet.be> writes:
>
>> zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
>>> > * gcc can be compiled with `--enable-default-ssp --enable-default-
>>> > pie`
>>> > to enforce ssp and pic
>>> 
>>> You wrote [1]:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> (define-public gcc
>>>   (package
>>>     (inherit gcc)
>>>     (arguments
>>>      (substitute-keyword-arguments (package-arguments gcc)
>>>      ((#:configure-flags flags
>>>        `(append (list "--enable-default-ssp" "--enable-default-pie")
>>>             ,flags)))))))
>>> --8<---------------cut here---------------end--------------->8---
>>
>> I think it would be a lot simpler to just add this to the 'standard'
>> gcc configure flags, in (gnu packages gcc), given that probably the
>> idea is to do this hardening for all packages?  Needs a world-rebuild
>> though.
>
> +1.  The whole distribution can probably benefit from this hardening.

That’s something worth trying in a branch off ‘core-updates’.

Stack smashing protection (SSP) may incur measurable run-time overhead
though so enabling that one by default may be less consensual.

There are other things that could be done in this area, often with no or
little overhead, such as building with -D_FORTIFY_SOURCE.  Doing that
transparently (without changing build systems) is a bit of a challenge
though.

Ludo’.

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Mar 29, 2022, 10:15 by ludo@gnu.org:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Maxime Devos <maximedevos@telenet.be> writes:
>>
>>> zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
>>>
>>>> > * gcc can be compiled with `--enable-default-ssp --enable-default-
>>>> > pie`
>>>> > to enforce ssp and pic
>>>>
>>>> You wrote [1]:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> (define-public gcc
>>>>   (package
>>>>     (inherit gcc)
>>>>     (arguments
>>>>      (substitute-keyword-arguments (package-arguments gcc)
>>>>      ((#:configure-flags flags
>>>>        `(append (list "--enable-default-ssp" "--enable-default-pie")
>>>>             ,flags)))))))
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>
>>> I think it would be a lot simpler to just add this to the 'standard'
>>> gcc configure flags, in (gnu packages gcc), given that probably the
>>> idea is to do this hardening for all packages?  Needs a world-rebuild
>>> though.
>>>
>>
>> +1.  The whole distribution can probably benefit from this hardening.
>>
>
> That’s something worth trying in a branch off ‘core-updates’.
>
> Stack smashing protection (SSP) may incur measurable run-time overhead
> though so enabling that one by default may be less consensual.
>
We could do it like how NixOS does it [1]. There can be a `harden?` list in the build system that contains a default set of flags. Packages that need to have less hardening for performance or other reasons can modify that list. I believe this was discussed in an old email (not this thread).

> There are other things that could be done in this area, often with no or
> little overhead, such as building with -D_FORTIFY_SOURCE.  Doing that
> transparently (without changing build systems) is a bit of a challenge
> though.
>
> Ludo’.
>
Where and how should the default make and ldflags be set? I guess they could be set in the build-system/*.scm.

[1] https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html

Re: Hardened toolchain

[jbranso]

April 14, 2022 3:00 PM, "Development of GNU Guix and the GNU System distribution."
<guix-devel@gnu.org> wrote:

> Mar 29, 2022, 10:15 by ludo@gnu.org:
> 
>> Hi,
>> 
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> 
> Maxime Devos <maximedevos@telenet.be> writes:
>> zimoun schreef op ma 21-03-2022 om 14:34 [+0100]:
> 
> * gcc can be compiled with `--enable-default-ssp --enable-default-
> pie`
> to enforce ssp and pic
>> You wrote [1]:
>> 
>> --8<---------------cut here---------------start------------->8---
>> (define-public gcc
>> (package
>> (inherit gcc)
>> (arguments
>> (substitute-keyword-arguments (package-arguments gcc)
>> ((#:configure-flags flags
>> `(append (list "--enable-default-ssp" "--enable-default-pie")
>> ,flags)))))))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> I think it would be a lot simpler to just add this to the 'standard'
>> gcc configure flags, in (gnu packages gcc), given that probably the
>> idea is to do this hardening for all packages? Needs a world-rebuild
>> though.
> 
> +1. The whole distribution can probably benefit from this hardening.
>> That’s something worth trying in a branch off ‘core-updates’.
>> 
>> Stack smashing protection (SSP) may incur measurable run-time overhead
>> though so enabling that one by default may be less consensual.
> 
> We could do it like how NixOS does it [1]. There can be a `harden?` list in the build system that
> contains a default set of flags. Packages that need to have less hardening for performance or other
> reasons can modify that list. I believe this was discussed in an old email (not this thread).

I like this idea.  I propose we make harden? default to #t.  That way practically most packages will be built with
hardened features.  Let's face it, I am a bit lazy, if I submit a package to guix, I am usually going to be it the easy way.  If the easy way is harden? #f, then that's is how I will submit it.  :)

> 
>> There are other things that could be done in this area, often with no or
>> little overhead, such as building with -D_FORTIFY_SOURCE. Doing that
>> transparently (without changing build systems) is a bit of a challenge
>> though.
>> 
>> Ludo’.
> 
> Where and how should the default make and ldflags be set? I guess they could be set in the
> build-system/*.scm.
> 
> [1] https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html

Re: Hardened toolchain

[Zhu Zihao]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

> I like this idea.  I propose we make harden? default to #t.  That way practically most packages will be built with
> hardened features. Let's face it, I am a bit lazy, if I submit a package to
> guix, I am usually going to be it the easy way. If the easy way is harden? #f,
> then that's is how I will submit it. :)

I suggest a build transform flag like `--hardened` for people who wants
a hardened software, just like `--tune` for SIMD instructions.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Hardened toolchain

[raingloom]

On Sat, 16 Apr 2022 00:04:37 +0800
Zhu Zihao <all_but_last@163.com> wrote:

> > I like this idea.  I propose we make harden? default to #t.  That
> > way practically most packages will be built with hardened features.
> > Let's face it, I am a bit lazy, if I submit a package to guix, I am
> > usually going to be it the easy way. If the easy way is harden? #f,
> > then that's is how I will submit it. :)  
> 
> I suggest a build transform flag like `--hardened` for people who
> wants a hardened software, just like `--tune` for SIMD instructions.

People shouldn't have to take extra steps and burn extra CPU cycles for
security. If I have to recompile everything to harden my system, I
likely won't bother.
Pretty much everyone benefits from hardening, but not everyone has the
resources and know how to do it manually. Just choosing what to harden
is already not a trivial question.

Re: Hardened toolchain

[Katherine Cox-Buday]

raingloom <raingloom@riseup.net> writes:

> People shouldn't have to take extra steps and burn extra CPU cycles
> for security.

To be clear, I don't have a strong opinion on this, but I wanted to give an alternative viewpoint: people shouldn't have to take extra steps and burn extra CPU cycles for performance.

Everyone has different threat models and needs. A lot of computers have CPU speculative execution attack mitigation disabled because those types of attacks will never affect those computers, and it reduces the performance of the CPU a lot.

I suggest we pick our default with care, and if possible with data about what most users would like.

-- 
Katherine

Re: Hardened toolchain

[Aurora]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Everyone has different threat models and needs. A lot of computers have CPU speculative execution attack mitigation disabled because those types of attacks will never affect those computers, and it reduces the performance of the CPU a lot.

There are multicore processors made in the last decade or two that
aren't affected by speculative execution vulnerabilities?

Re: Hardened toolchain

[Katherine Cox-Buday]

Aurora <rind38@disroot.org> writes:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
>> Everyone has different threat models and needs. A lot of computers
>> have CPU speculative execution attack mitigation disabled because
>> those types of attacks will never affect those computers, and it
>> reduces the performance of the CPU a lot.
>
> There are multicore processors made in the last decade or two that
> aren't affected by speculative execution vulnerabilities?

They are vulnerable to them, but not necessarily affected by them.
Consider a computer not networked to the internet and only running
trusted workloads (e.g. scientific HPC, etc.). This is why acknowledging that everyone has a different threat model is important.

I hope this helps to clarify.

Sincerely,
-- 
Katherine

Re: Hardened toolchain

[Aurora]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Aurora <rind38@disroot.org> writes:
>> There are multicore processors made in the last decade or two that
>> aren't affected by speculative execution vulnerabilities?
>
> They are vulnerable to them, but not necessarily affected by them.
> Consider a computer not networked to the internet and only running
> trusted workloads (e.g. scientific HPC, etc.). This is why acknowledging that everyone has a different threat model is important.
>
> I hope this helps to clarify.

It does help, that makes sense, thanks.

Re: Hardened toolchain

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On 2022-04-28, Aurora wrote:
> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
>> Everyone has different threat models and needs. A lot of computers have CPU speculative execution attack mitigation disabled because those types of attacks will never affect those computers, and it reduces the performance of the CPU a lot.
>
> There are multicore processors made in the last decade or two that
> aren't affected by speculative execution vulnerabilities?

There are some, such as the ARM-based Allwinner A64 used in in the
pinebook and pinephone. Probably various processors targeted at the
mobile market as well.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Hardened toolchain

[Aurora]

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2022-04-28, Aurora wrote:
>> There are multicore processors made in the last decade or two that
>> aren't affected by speculative execution vulnerabilities?
>
> There are some, such as the ARM-based Allwinner A64 used in in the
> pinebook and pinephone. Probably various processors targeted at the
> mobile market as well.

Oh that's neat, I'd thought effectively all multicore CPUs were
vulnerable.

Thanks.

Re: Hardened toolchain

[zimoun]

Hi,

On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès <ludo@gnu.org> wrote:

> Stack smashing protection (SSP) may incur measurable run-time overhead
> though so enabling that one by default may be less consensual.

That’s true and it could be an issue for HPC practitioners.  However,
quoting Wikipedia [1], for what it is worth:

--8<---------------cut here---------------start------------->8---
All Fedora packages are compiled with -fstack-protector since Fedora
Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
Every Arch Linux package is compiled with -fstack-protector since
2011.[22] All Arch Linux packages built since 4 May 2014 use
-fstack-protector-strong.[23] Stack protection is only used for some
packages in Debian,[24] and only for the FreeBSD base system since
8.0.[25] Stack protection is standard in certain operating systems,
including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.
--8<---------------cut here---------------end--------------->8---

Well, I miss if Guix is built using this ’-fstack-protector’ flag; or
whether it is included by default.


Cheers,
simon



1: <https://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_Compiler_Collection_(GCC)>

Re: Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

Apr 29, 2022, 10:31 by zimon.toutoune@gmail.com:

> Hi,
>
> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Stack smashing protection (SSP) may incur measurable run-time overhead
>> though so enabling that one by default may be less consensual.
>>
>
> That’s true and it could be an issue for HPC practitioners.  However,
> quoting Wikipedia [1], for what it is worth:
>
> --8<---------------cut here---------------start------------->8---
> All Fedora packages are compiled with -fstack-protector since Fedora
> Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
> packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
> Every Arch Linux package is compiled with -fstack-protector since
> 2011.[22] All Arch Linux packages built since 4 May 2014 use
> -fstack-protector-strong.[23] Stack protection is only used for some
> packages in Debian,[24] and only for the FreeBSD base system since
> 8.0.[25] Stack protection is standard in certain operating systems,
> including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.
> --8<---------------cut here---------------end--------------->8---
>
>
Anaconda (science package distribution) compiles their packages with a variety of security flags. These include PIE, SSP, fortify, RELRO, NOW. https://www.anaconda.com/blog/improved-security-performance-in-anaconda-distribution-5


> Well, I miss if Guix is built using this ’-fstack-protector’ flag; or
> whether it is included by default.
>

Are /any/ build flags used by default? I  think right now only an empty list is used for makeflags by default. It also depends on the configuration for gcc and binutils, they can be set to enforce SSP and others by default.


> Cheers,
> simon
>
>
>
> 1: <https://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_Compiler_Collection_(GCC)>
>

Re: Hardened toolchain

[Katherine Cox-Buday]

zimoun <zimon.toutoune@gmail.com> writes:

> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Stack smashing protection (SSP) may incur measurable run-time
>> overhead though so enabling that one by default may be less
>> consensual.
>
> That’s true and it could be an issue for HPC practitioners.  However,
> quoting Wikipedia [1], for what it is worth:
>
> All Fedora packages are compiled with -fstack-protector since Fedora
> Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
> packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
> Every Arch Linux package is compiled with -fstack-protector since
> 2011.[22] All Arch Linux packages built since 4 May 2014 use
> -fstack-protector-strong.[23] Stack protection is only used for some
> packages in Debian,[24] and only for the FreeBSD base system since
> 8.0.[25] Stack protection is standard in certain operating systems,
> including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.

For me at least, this is a compelling argument for also defaulting to more secure, but possibly slower, build flags. (Full disclosure: I would personally benefit from the security over performance model of defaults).

But I think we should state our reasons plainly in the documentation, and provide an easy way for those who need performance to "recompile the world".

-- 
Katherine

Re: Hardened toolchain

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

zimoun schreef op vr 29-04-2022 om 12:31 [+0200]:
> > Stack smashing protection (SSP) may incur measurable run-time
> > overhead
> > though so enabling that one by default may be less consensual.
> 
> That’s true and it could be an issue for HPC practitioners.  [...]

I'm not sure if this wasn't already mentioned, but HPC practicioners
can already use --tune.  Maybe HPC practicioners can have --without-
hardening.  However, in the computing I do that needs to be high
performance (*), it seems that the expensive computations are matrix
multiplications, eigenvector decompositions and the like.  I wouldn't
expect those kind of things to be hindered by hardening.

(*) In my case, this is not about supercomputers or computer clusters,
but about having software run fast enough on the hardware that is
available.  In some situations, that's a fancy supercomputer, but often
a simple laptop can do ... if the software is sufficiently optimised.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Hardened toolchain

[zimoun]

Hi Maxime,

On Mon, 02 May 2022 at 18:25, Maxime Devos <maximedevos@telenet.be> wrote:
> zimoun schreef op vr 29-04-2022 om 12:31 [+0200]:
>> > Stack smashing protection (SSP) may incur measurable run-time
>> > overhead
>> > though so enabling that one by default may be less consensual.
>> 
>> That’s true and it could be an issue for HPC practitioners.  [...]
>
> I'm not sure if this wasn't already mentioned, but HPC practicioners
> can already use --tune.  Maybe HPC practicioners can have --without-
> hardening.  However, in the computing I do that needs to be high
> performance (*), it seems that the expensive computations are matrix
> multiplications, eigenvector decompositions and the like.  I wouldn't
> expect those kind of things to be hindered by hardening.
>
> (*) In my case, this is not about supercomputers or computer clusters,
> but about having software run fast enough on the hardware that is
> available.  In some situations, that's a fancy supercomputer, but often
> a simple laptop can do ... if the software is sufficiently optimised.

I agree that HPC practitioners can burn some CPU cycles and recompile the
world if they care so much about run-time performances.

To me, it is the same trade-off by HPC folks as custom / performance vs
portable / pre-built. :-)


Cheers,
simon

Re: Hardened toolchain

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

zimoun schreef op ma 02-05-2022 om 19:41 [+0200]:
> > (*) In my case, this is not about supercomputers or computer
> > clusters, but about having software run fast enough on the hardware
> > that is available.  In some situations, that's a fancy
> > supercomputer, but often a simple laptop can do ... if the software
> > is sufficiently optimised.
> 
> I agree that HPC practitioners can burn some CPU cycles and recompile
> the world if they care so much about run-time performances.
> 
> To me, it is the same trade-off by HPC folks as custom / performance
> vs portable / pre-built. :-)

I didn't mean rebuilding the world, only things like numpy, openblas,
fftw and maybe glibc -- avoiding rebuilding dependents, with the grafts
mechanism used by --tune.

Greetiings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Hardened toolchain

[Nathan Dehnel]

>People shouldn't have to take extra steps and burn extra CPU cycles for
security. If I have to recompile everything to harden my system, I
likely won't bother.
>Pretty much everyone benefits from hardening, but not everyone has the
resources and know how to do it manually. Just choosing what to harden
is already not a trivial question.

Then have hardened be the default and have --hardened=off be the
package transform option?

Re: Hardened toolchain

[raingloom]

On Fri, 15 Apr 2022 15:36:25 -0500
Nathan Dehnel <ncdehnel@gmail.com> wrote:

> >People shouldn't have to take extra steps and burn extra CPU cycles
> >for  
> security. If I have to recompile everything to harden my system, I
> likely won't bother.
> >Pretty much everyone benefits from hardening, but not everyone has
> >the  
> resources and know how to do it manually. Just choosing what to harden
> is already not a trivial question.
> 
> Then have hardened be the default and have --hardened=off be the
> package transform option?

Yes, that seems like a better solution. Maybe call it
--without-hardening, to match the current convention.
(Like --with-latest, --without-tests, etc)

Hardened toolchain

[kiasoc5--- via Development of GNU Guix and the GNU System distribution.]

I posted an initial message on help-guix about compiling a custom hardened gcc, but guix-devel is a better list to continue the discussion. I wanted to revisit compiling Guix packages with a hardened toolchain since many other distros do this to improve the security of their packages.

Previous emails  only mentioned passing hardening options to CFLAGS and LDFLAGS. Another important step is to compile features into GCC and binutils. Specifically:

* gcc can be compiled with `--enable-default-ssp --enable-default-pie` to enforce ssp and pic
* binutils can be compiled with `--enable-relro --enable-pic` to enforce relro and pic

I'm not a toolchain expert by any means, but I think this is a good first step in improving Guix package security.

1. https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html