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 .
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
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 al
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,
> quoti
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
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 wha
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 v
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 inte
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
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 lo
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 multi
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.
Every
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
>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 ha
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
> 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
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-de
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 [
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---
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
ben
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
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-pub
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 gc
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
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-gc
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:
>>
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 (# ?))
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 g
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
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-argument
30 matches
Mail list logo
