Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[intrigeri]

Hi,

Guillem Jover (2022-09-23):
> On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
>> According to
>> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
>> _FORTIFY_SOURCE=3 improves memory management protections. It requires
>> glibc 2.34. It's been supported in Clang "for some time" and support
>> was added to GCC 12. I understand it has some performance impact.
>
> It would be nice to understand what's the impact here. Paul Wise also
> mentioned a thread on .

Unfortunately, I'm not knowledgeable enough in this area to provide
this information.

> If the intention is to update the default, then that would require a
> discussion on d-d:
>
>   
> 

My proposal, at least at this stage, is to *not* update the default:

>> I suppose we don't want to switch hardening=fortify fortification
>> level 3, at least to start with.

It may be that the cost (performance) / benefit (security) needs to be
assessed on a per-package basis, which would prevent us from ever
making this the default. Anyway, IMO that's a discussion for years
from now: we'll see how it works for distros that enable this feature,
and once it is available in an opt-in manner, it'll be easier to
gather the data we need to decide.

>> So perhaps a new hardening=XYZ flag could allow package maintainers to
>> opt-in?
>
> The main problem is that any new feature added to an area such as
> hardening will be automatically picked up by anything that is
> currently specifying hardening=all. :/

Ouch. Thanks, I did not think of this. That indeed makes it difficult
to add any new hardening build flag in an iterative manner :/

> I've been pondering about managing this kind of thing via
> , but I
> don't think that would even help with the =all problem. So I was
> thinking a potential solution would be to version the =all request
> somehow.
>
> We'd have =all meaning level 0, then say =all-v1 for the new defaults,
> that would also mean we can safely add new features that will not be
> part of the current =all.

Sounds good!

Should we track this versioning as a separate bug report, that would
block this one?

Thanks for your constructive reply,
cheers!

Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[Guillem Jover]

Control: tags -1 moreinfo

On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: wishlist

> According to
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
> _FORTIFY_SOURCE=3 improves memory management protections. It requires
> glibc 2.34. It's been supported in Clang "for some time" and support
> was added to GCC 12. I understand it has some performance impact.

It would be nice to understand what's the impact here. Paul Wise also
mentioned a thread on .

If the intention is to update the default, then that would require a
discussion on d-d:

  


> I suppose we don't want to switch hardening=fortify fortification
> level 3, at least to start with.
> 
> So perhaps a new hardening=XYZ flag could allow package maintainers to
> opt-in?

The main problem is that any new feature added to an area such as
hardening will be automatically picked up by anything that is
currently specifying hardening=all. :/

I've been pondering about managing this kind of thing via
, but I
don't think that would even help with the =all problem. So I was
thinking a potential solution would be to version the =all request
somehow.

We'd have =all meaning level 0, then say =all-v1 for the new defaults,
that would also mean we can safely add new features that will not be
part of the current =all.

Thanks,
Guillem

Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[intrigeri]

Package: dpkg-dev
Version: 1.21.9
Severity: wishlist

Hi,

According to
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
_FORTIFY_SOURCE=3 improves memory management protections. It requires
glibc 2.34. It's been supported in Clang "for some time" and support
was added to GCC 12. I understand it has some performance impact.

I suppose we don't want to switch hardening=fortify fortification
level 3, at least to start with.

So perhaps a new hardening=XYZ flag could allow package maintainers to
opt-in?

Cheers!