Re: Hardened toolchain

[Maxime Devos]

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.


signature.asc
Description: This is a digitally signed message part

Re: Hardened toolchain

[zimoun]

Hi Maxime,

On Mon, 02 May 2022 at 18:25, Maxime Devos  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]

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.


signature.asc
Description: This is a digitally signed message part

Re: Hardened toolchain

[Katherine Cox-Buday]

zimoun  writes:

> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  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

[Development of GNU Guix and the GNU System distribution.]

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

> Hi,
>
> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  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: 
> 
>

Re: Hardened toolchain

[zimoun]

Hi,

On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  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: 

Re: Hardened toolchain

[Aurora]

Vagrant Cascadian  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

[Aurora]

Katherine Cox-Buday  writes:

> Aurora  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]

On 2022-04-28, Aurora wrote:
> Katherine Cox-Buday  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


signature.asc
Description: PGP signature

Re: Hardened toolchain

[Katherine Cox-Buday]

Aurora  writes:

> Katherine Cox-Buday  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  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]

raingloom  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

[raingloom]

On Fri, 15 Apr 2022 15:36:25 -0500
Nathan Dehnel  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)

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 Sat, 16 Apr 2022 00:04:37 +0800
Zhu Zihao  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

[Zhu Zihao]

> 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


signature.asc
Description: PGP signature

Re: Hardened toolchain

[jbranso]

April 14, 2022 3:00 PM, "Development of GNU Guix and the GNU System 
distribution."
 wrote:

> Mar 29, 2022, 10:15 by l...@gnu.org:
> 
>> Hi,
>> 
>> Maxim Cournoyer  skribis:
> 
> Maxime Devos  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

[Development of GNU Guix and the GNU System distribution.]

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

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Maxime Devos  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

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Maxime Devos  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

[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.courno...@gmail.com:

> Hi,
>
> Maxime Devos  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  wrote:
> Maxime Devos  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

[Maxim Cournoyer]

Hi,

Maxime Devos  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

[Maxime Devos]

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.


signature.asc
Description: This is a digitally signed message part

Re: Hardened toolchain

[zimoun]

Hi,

On Sat, 26 Mar 2022 at 20:33, kias...@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, kias...@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

[Development of GNU Guix and the GNU System distribution.]

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

> Hi Simon,
>
> Mar 25, 2022, 22:54 by zimon.touto...@gmail.com:
>
>> Hi,
>>
>> On Fri, 25 Mar 2022 at 20:39, kias...@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 (# ?))
>>>    217:50 18 (lp (# ?))
>>>    217:50 17 (lp (# ?))
>>>    217:50 16 (lp (# ?))
>>>    217:50 15 (lp (# ?))
>>>    217:50 14 (lp (# ?))
>>>    217:50 13 (lp (# ?))
>>>    217:50 12 (lp (# ?))
>>>    217:50 11 (lp (# ?))
>>>    217:50 10 (lp (# ?))
>>>    217:50  9 (lp (# ?))
>>>    217:50  8 (lp (# ?))
>>>    217:50  7 (lp (# ?))
>>>    217:50  6 (lp (# ?))
>>>    217:50  5 (lp (# ?))
>>>    217:50  4 (lp (# ?))
>>>    217:33  3 (lp (# ?))
>>>     159:9  2 (_ #(#(# #f) #f))
>>>     159:9  1 (_ #(#(# #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

[Development of GNU Guix and the GNU System distribution.]

Hi Simon,

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

> Hi,
>
> On Fri, 25 Mar 2022 at 20:39, kias...@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 (# ?))
>>    217:50 18 (lp (# ?))
>>    217:50 17 (lp (# ?))
>>    217:50 16 (lp (# ?))
>>    217:50 15 (lp (# ?))
>>    217:50 14 (lp (# ?))
>>    217:50 13 (lp (# ?))
>>    217:50 12 (lp (# ?))
>>    217:50 11 (lp (# ?))
>>    217:50 10 (lp (# ?))
>>    217:50  9 (lp (# ?))
>>    217:50  8 (lp (# ?))
>>    217:50  7 (lp (# ?))
>>    217:50  6 (lp (# ?))
>>    217:50  5 (lp (# ?))
>>    217:50  4 (lp (# ?))
>>    217:33  3 (lp (# ?))
>>     159:9  2 (_ #(#(# #f) #f))
>>     159:9  1 (_ #(#(# #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

[zimoun]

Hi,

On Fri, 25 Mar 2022 at 20:39, kias...@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 (# ?))
>    217:50 18 (lp (# ?))
>    217:50 17 (lp (# ?))
>    217:50 16 (lp (# ?))
>    217:50 15 (lp (# ?))
>    217:50 14 (lp (# ?))
>    217:50 13 (lp (# ?))
>    217:50 12 (lp (# ?))
>    217:50 11 (lp (# ?))
>    217:50 10 (lp (# ?))
>    217:50  9 (lp (# ?))
>    217:50  8 (lp (# ?))
>    217:50  7 (lp (# ?))
>    217:50  6 (lp (# ?))
>    217:50  5 (lp (# ?))
>    217:50  4 (lp (# ?))
>    217:33  3 (lp (# ?))
>     159:9  2 (_ #(#(# #f) #f))
>     159:9  1 (_ #(#(# #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

[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 (# ?))
   217:50 18 (lp (# ?))
   217:50 17 (lp (# ?))
   217:50 16 (lp (# ?))
   217:50 15 (lp (# ?))
   217:50 14 (lp (# ?))
   217:50 13 (lp (# ?))
   217:50 12 (lp (# ?))
   217:50 11 (lp (# ?))
   217:50 10 (lp (# ?))
   217:50  9 (lp (# ?))
   217:50  8 (lp (# ?))
   217:50  7 (lp (# ?))
   217:50  6 (lp (# ?))
   217:50  5 (lp (# ?))
   217:50  4 (lp (# ?))
   217:33  3 (lp (# ?))
    159:9  2 (_ #(#(# #f) #f))
    159:9  1 (_ #(#(# #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 kias...@tutanota.com:

> Mar 22, 2022, 19:06 by zimon.touto...@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, kias...@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 

Re: Hardened toolchain

[Development of GNU Guix and the GNU System distribution.]

Mar 22, 2022, 19:06 by zimon.touto...@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, kias...@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,

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


On Tue, 22 Mar 2022 at 18:23, kias...@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