Bug 2196312

According to #2196282 this is only a problem for plugins that are dlopen'd, but rpm-sequoia doesn't work like that --
It provides a standard shared library with a C ABI that rpm is linked with.
Does that mean I don't need to do anything about rpm-sequoia, or does this problem also affect shared libraries in addition to dlopen'd objects?

Additionally, building with "-Z cf-protection" is not a good idea.
All "-Z" flags are unstable and only available on nightly Rust compilers (or in stable compilers in "bootstrap" mode).
I expect there will be an alternative non-unstable flag (probably something like "-C cf-protection" once this feature is stabilized in Rust upstream).

Also, if this feature should be enabled for ALL Rust builds once it's available in the Rust compiler (probably only for x86_64 builds?), then it should be added to the default compiler flags as they are defined [here] instead of modifying compiler flags in individual packages.

[here]: https://pagure.io/fedora-rust/rust-packaging/blob/main/f/macros.d/macros.rust#_40

(In reply to Fabio Valentini from comment #1)
> According to #2196282 this is only a problem for plugins that are dlopen'd,
> but rpm-sequoia doesn't work like that --
> It provides a standard shared library with a C ABI that rpm is linked with.
> Does that mean I don't need to do anything about rpm-sequoia, or does this
> problem also affect shared libraries in addition to dlopen'd objects?

The breakage is in packagekitd, where it looks like dnf is loaded as a plugin, which leads to rpm-sequoia being dlopen'd.  I haven't fully tested all paths yet, I hope to do that this week.

> Additionally, building with "-Z cf-protection" is not a good idea.
> All "-Z" flags are unstable and only available on nightly Rust compilers (or
> in stable compilers in "bootstrap" mode).
> I expect there will be an alternative non-unstable flag (probably something
> like "-C cf-protection" once this feature is stabilized in Rust upstream).

Yeah I agree that's a problem, but that would mean disabling shadow stack in all of the rust ecosystem (and everything that depends on it through dlopen) until the flag becomes stable.

> Also, if this feature should be enabled for ALL Rust builds once it's
> available in the Rust compiler (probably only for x86_64 builds?), then it
> should be added to the default compiler flags as they are defined [here]
> instead of modifying compiler flags in individual packages.
> 
> [here]:
> https://pagure.io/fedora-rust/rust-packaging/blob/main/f/macros.d/macros.
> rust#_40

Yes, that will likely be the route since the feature is already enabled by default in C/C++.  I've got a systemwide change proposal in the works for it.  I filed a rpm-sequoia bug separately because it affects the default installation.

(In reply to Siddhesh Poyarekar from comment #2)
> (In reply to Fabio Valentini from comment #1)
> > According to #2196282 this is only a problem for plugins that are dlopen'd,
> > but rpm-sequoia doesn't work like that --
> > It provides a standard shared library with a C ABI that rpm is linked with.
> > Does that mean I don't need to do anything about rpm-sequoia, or does this
> > problem also affect shared libraries in addition to dlopen'd objects?
> 
> The breakage is in packagekitd, where it looks like dnf is loaded as a
> plugin, which leads to rpm-sequoia being dlopen'd.  I haven't fully tested
> all paths yet, I hope to do that this week.

So ... packagekitd is dlopening libdnf, which is linked against librpm, which is linked against librpm-sequoia?
Well, PackageKit might go away in the near future with DNF5 so it might not be a problem for long :(

> > Additionally, building with "-Z cf-protection" is not a good idea.
> > All "-Z" flags are unstable and only available on nightly Rust compilers (or
> > in stable compilers in "bootstrap" mode).
> > I expect there will be an alternative non-unstable flag (probably something
> > like "-C cf-protection" once this feature is stabilized in Rust upstream).
> 
> Yeah I agree that's a problem, but that would mean disabling shadow stack in
> all of the rust ecosystem (and everything that depends on it through dlopen)
> until the flag becomes stable.

Depending on unstable flags like this is a massive risk for Fedora though. We would need to add "-Z cf-protection" *and* enable the Rust compiler's "bootstrap" mode. And this could break with any minor Rust update, and we get those every six weeks in Fedora - not every six *months* like in RHEL. I don't think adding this level of instability to a software stack that's increasingly important in Fedora would be acceptable. We already have one flag like this enabled ("-Z avoid-dev-deps") and I've already been thinking of ways to get rid of it for exactly those reasons.

> > Also, if this feature should be enabled for ALL Rust builds once it's
> > available in the Rust compiler (probably only for x86_64 builds?), then it
> > should be added to the default compiler flags as they are defined [here]
> > instead of modifying compiler flags in individual packages.
> > 
> > [here]:
> > https://pagure.io/fedora-rust/rust-packaging/blob/main/f/macros.d/macros.
> > rust#_40
> 
> Yes, that will likely be the route since the feature is already enabled by
> default in C/C++.  I've got a systemwide change proposal in the works for
> it.  I filed a rpm-sequoia bug separately because it affects the default
> installation.

Default installation .. of what? For example, Fedora Workstation ships at least four Rust libraries by default (librpm-sequoia, librsvg2, libblkio, libkrun), and these are only the ones that I could think of immediately).

(In reply to Fabio Valentini from comment #3)
> (In reply to Siddhesh Poyarekar from comment #2)
> > (In reply to Fabio Valentini from comment #1)
> > > Additionally, building with "-Z cf-protection" is not a good idea.
> > > All "-Z" flags are unstable and only available on nightly Rust compilers (or
> > > in stable compilers in "bootstrap" mode).
> > > I expect there will be an alternative non-unstable flag (probably something
> > > like "-C cf-protection" once this feature is stabilized in Rust upstream).
> > 
> > Yeah I agree that's a problem, but that would mean disabling shadow stack in
> > all of the rust ecosystem (and everything that depends on it through dlopen)
> > until the flag becomes stable.
> 
> Depending on unstable flags like this is a massive risk for Fedora though.
> We would need to add "-Z cf-protection" *and* enable the Rust compiler's
> "bootstrap" mode. And this could break with any minor Rust update, and we
> get those every six weeks in Fedora - not every six *months* like in RHEL. I
> don't think adding this level of instability to a software stack that's
> increasingly important in Fedora would be acceptable. We already have one
> flag like this enabled ("-Z avoid-dev-deps") and I've already been thinking
> of ways to get rid of it for exactly those reasons.

I am also considering that we could flip the default on *within* rustc, but I want to learn more about the impact of that, especially since there wouldn't be any (stable) way to turn it back off.

> > Yes, that will likely be the route since the feature is already enabled by
> > default in C/C++.  I've got a systemwide change proposal in the works for
> > it.  I filed a rpm-sequoia bug separately because it affects the default
> > installation.
> 
> Default installation .. of what? For example, Fedora Workstation ships at
> least four Rust libraries by default (librpm-sequoia, librsvg2, libblkio,
> libkrun), and these are only the ones that I could think of immediately).

Do any of those suffer the dlopen aspect though? If a non-CET Rust library is part of the initial load, the process just doesn't enter SHSTK mode at all.

(In reply to Josh Stone from comment #4)

> Do any of those suffer the dlopen aspect though? If a non-CET Rust library
> is part of the initial load, the process just doesn't enter SHSTK mode at
> all.

I don't know OTOH, and it's also not trivial to check, since many dlopen dependencies are not explicit somewhere. It might not be a problem, but it *could* be (really the best kind of future problem ...)

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.