Disable custom CFLAGS

[Jonas Jelten]

This came up because our LTO build flags let the build fail.

Upstream has requested in https://github.com/ipxe/ipxe/pull/1521 and https://github.com/ipxe/ipxe/issues/1515 that Debian/Ubuntu should not modify compiler flags since this can introduce bugs for the built ROMs.

We should remove our patches to adjust CFLAGS and just go with the package's defaults.

Since this is for building ROMs even generating/splitting out debugging symbols is probably not worth keeping the flags.

[Lukas Märdian (slyon)]

This is request stands in contrast to the intention of "dpkg-buildflags", as used in Debian & Ubuntu to customize the corresponding distribution to their specific needs.

Ideally, we want to have all packages built using as similar buildflags as possible, as this influences Ubuntu's performance and correctness efforts. So a balance needs to be hit between upstream demands and downstream optimizations.

Certainly, if a specific build-flag causes issues (such as LTO), this can be disabled, e.g.:
https://wiki.ubuntu.com/ToolChain/LTO#Implementation

[Christian Ehrhardt (paelzer)]

Both statements are true,
- we generally want the central build flags
- in this case they might conflict with the way the code operates
=> Discussion it is

Rom's are often trying really hard to replicate sometimes arcane behavior.
Strict control of the flags is part of it and worth reconsidering for that package.

Upstream is not willing to allow any flags, probably fed up with too many things that turned out to be due to different flags used. And hence they requested us to please consider removing the old change that does so.

I have asked Jonas to work on this, create this bug for tracking and ask security what they think, as it would also drop e.g. hardening flags.

[Jonas Jelten (jj)]

What does the security team think about removing our added CFLAGS and just using what upstream recommends?

[Christian I. Niksson (nikize)]

Building packages with same CFLAGS makes sense for binaries running in the same system. So for applications it is good.

But here we are talking about firmware or bootloader, which is **not** running on Ubuntu. It is only compiled there, and then runs on bare metal, or in an emulator which should emulate bare metal.

Trying to make the argument that everything should be using dpkg-buildflags would then also extend to any other distro, or release of Microsoft Windows, running inside an emulator on top of Ubuntu.

I do hope that this steems from some misunderstanding of what iPXE is and how it is used.

It could be argued that the tools built and then used during the build process should use modified CFLAGS, but does it really make sense to care about that for a tool that runs once during the build process and is then thrown away?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Seth Arnold (seth-arnold)]

I'm fine with our ipxe packages using strictly the flags that the iPXE team wants.

Our CFLAGS mangling is intended to broadly raise the security mitigations applied to all our software and software that is built on Ubuntu.

Different packages will handle the mitigations better than others, and certainly the pre-boot environment that iPXE inhabits will have a different set of requirements than most of the software we ship, and it sounds like the iPXE team has strong opinions on the appropriate flags to use, probably grown from experience debugging problems in an environment that's very challenging to debug. It's worth deferring to their expertise here, not least because we may be causing them additional support burdens through our choices.

If they haven't reviewed the available security mitigations flags lately, I'd like to encourage them (or anyone, really) to read through https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++ for a good overview of the options available. These mitigations really are useful, and I frequently hear from pen-testers that they are an actual impediment to exploit authors, and the pre-boot environment also feels like it would benefit from their help. But I don't know which ones are appropriate and which ones are not.

Thanks so much for raising the question.

[Lukas Märdian (slyon)]

Thanks for the discussion. I agree with comments #4 & #6.

Let's encourage upstream to double-check their hardening flags, but otherwise stick to their choice of CFLAGS.

[Marc Deslauriers (mdeslaur)]

I also agree with comments #4 and #6. If the distro CFLAGS are causing problems, +1 to removing the patch.

[Jonas Jelten (jj)]

fix committed in 1.21.1+git-20250602.5b3ebf8b+dfsg-1ubuntu2

release is waiting for proposed migration https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ipxe

[Launchpad Janitor (janitor)]

This bug was fixed in the package ipxe - 1.21.1+git-20250602.5b3ebf8b+dfsg-1ubuntu3

---------------
ipxe (1.21.1+git-20250602.5b3ebf8b+dfsg-1ubuntu3) questing; urgency=medium

  * d/t/control: skip-not-installable rom-* tests (LP: #1677874)

ipxe (1.21.1+git-20250602.5b3ebf8b+dfsg-1ubuntu2) questing; urgency=medium

  * d/p/respect-CPPFLAGS-CFLAGS-LDFLAGS-presets: removed due to upstream
    request (LP: #2121439)

 -- Lukas Märdian <email address hidden> Mon, 29 Sep 2025 11:45:57 +0200