If any Ubuntu maintainers are listening: PLEASE STOP DOING THIS (github.com)

How many build systems are that broken, and unpatchably so?

Why should it not? For the most part this flag seems to be working. And it improves security. Windows can't do something like that for most of the software targeting it because it's all in binary form. For the software available through the default Ubuntu repos, source is available, so Ubuntu can offer this.

Do you have a case in point?

I've seen plenty of things were they couldn't meet the demand, but were they were simply taking the high ground?

The introduction of https://software.intel.com/sites/default/files/managed/4d/2a... has as much detail as I could ask for. Seems the GCC flag only enables the Intel implementation for now

Do you know what this flag considers to be a "valid" control flow transfer? The documentation makes it sound that this feature can safely be enabled all the time. But the linked article suggests otherwise...

The GCC docs seem basically useless. I have no idea if GCC plans to keep it like this forever but, right now, this is about x86's CET features. CET is an Intel spec that adds two very loosely related features: Indirect Branch Tracking (IBT) and Shadow Stacks (SHSTK). Neither is supported yet by upstream Linux.

IBT is a rather weak indirect-branch-and-call protection scheme. IMO it's weak enough that it has dubious value, and software-only schemes can be a lot stronger. The main benefits of IBT are that it can guarantee that a program won't, even when attacked, jump to the middle of an instruction and that, since IBT is a hardware mitigation, it can provide a degree of protection against Spectre-like attacks. Specifically, the CPU won't speculatively branch to an address that isn't an indirect branch target.

SHSTK is a very strong return address protection. With SHSTK on, it's really quite difficult to convince the CPU to let RET branch to anywhere other than were the original CALL came from. This even integrates with the page tables -- the memory it uses cannot be written by normal stores. The latter part is a large part of why this isn't upstream yet: the x86 pagetable format is already a technically-indebted mess, and SHSTK makes it worse in ways that are quite nasty. It'll get sorted out eventually.

You can find SHSTK in Zen 3 (yes, AMD brought Intel's feature to market before Intel -- go AMD!) and, apparently, in one Tiger Lake part. The latter also supports IBT.

You can play with the GCC support by compiling a trivial program like this:

    void test(void (*fn)())
    {
     fn();
    }

(no Godbolt link because I didn't figure out how to extract the right output from Godbolt.) If you compile with -S -fcf-protection=branch, the indirect jump is unchanged but the function itself gets an endbr64 (or endbr32) instruction at the beginning. That's a new special NOP that means "this is a valid indirect branch target". The CPU will only allow indirect branches that land on an endbr64 instruction, so the actual indirect jump in this function is unchanged. I think GCC is clever enough to omit the endbr64 if it can prove that the address of the function is not taken.

The other interesting thing that GCC does is to emit this:

            .section        .note.gnu.property,"a"
            .align 8
            .long    1f - 0f
            .long    4f - 1f
            .long    5
    0:
            .string  "GNU"
    1:
            .align 8
            .long    0xc0000002
            .long    3f - 2f
    2:
            .long    0x3
    3:
            .align 8

The 0x3 changes depending on the -fcf-protection option. This is a magic incantation for the benefit of the linker and kernel declaring whether this object supports IBT and/or SHSTK. This way you don't crash if you link a non-endbr-instrumented file into a IBT-using program.

Note that SHSTK support doesn't affect the code at all. The CALL and RET magic is handled by the CPU, and library functions like setjmp use special new instructions in order to keep working.

There is also CPU support for CET and IBT in the kernel. SHSTK in the kernel is a huge mess. Specifically, the x86 architecture is starting to fall apart -- there are various ill-conceived features like SYSCALL, NMI, the machine check architecture, and some fancy virtualization features that, collectively, conspire to make it extremely complicated to correctly handle all types of interrupts and interrupt-like events. SHSTK-in-kernel makes it worse, and I don't think anyone wants to try to deal with this yet. I and others have been badgering Intel and AMD for quite some time to do something about the mess that x86 kernel entries have become, and so far there are no results.

I'd imagine the problem is that iPXE is preboot firmware, so the emitted setjmp/longjmp builtins assume a shadow stack that's set up, etc.

Ubuntu should not enable the flag when -ffreestanding is set.

    #include <setjmp.h>
    
    void __attribute__((noinline)) test(jmp_buf buf)
    {
     __builtin_longjmp(buf, 1);
    }
    
    int main()
    {
     jmp_buf buf;
     if (__builtin_setjmp(buf) == 0)
      test(buf);
     return 0;
    }

Depends what you're looking for. If you're used to Ubuntu you'll find Debian to be similar: just a less-polished, less-branded UI and maybe slightly older (perhaps more stable) packages.

You might also like Fedora as a pretty mainstream, up to date desktop distro, but under the hood you'll find more differences like rpm instead of apt.

edit: I'd add that Linux distros are complicated: the issue in this article is hardly a reason to leave Ubuntu if it's otherwise working well for you.

I have found the one big feature of Ubuntu that I miss in Debian is PPAs. Other than that it's largely the same. Configuring the system requires more file editing and command line work than I remember with Ubuntu, but the documentation helps quite a bit.

EDIT: By default, non-free drivers are placed in a separate repository, and receive less support. In my case the biggest pain has been Nvidia drivers. I needed a cheap card to drive an HDMI display and all they had at the store was a GT710. That meant installing the proprietary drivers, since the free alternative had poor performance last time I checked. Every few updates it breaks, and I need to reinstall it and sign the kernel module each time. That is something to watch out for if you switch over.

Debian is usually a great and pretty stable ecosystem choice. Also APT makes it easy to manage third party repositories (package pinning).

One big advantage I see with other distributions is that the release support cycles are longer (5y+).

But it will greatly depend on your usage, we are pretty happy with Debian running on somewhat 300+ machines.

OpenSUSE is the one I landed on, and it's been great.

I keep hearing high praise about Manjaro too, that it's solid, fast, and newbie-friendly; but I haven't tried it out myself yet.

FreeBSD.

There is a mess of things wrong with the linux ecosystem and a lot of it comes down to packaging systems and package management. Once you get over a little learning curve, working with FreeBSD is a breath of fresh air.

Depends on your needs. Is it desktop? Is it server? Is it container base? If there any specific software/hardware you rely on? Etc. There's no "best alternative".

I used Debian for years, it is stable and has very few surprises. Ubuntu is a clone of Debian and can be a bit buggy. That been said Ubuntu is great for trying new things. Probably my favourite distro of late is Fedora, works well, the s/w packaging system is stable and quite user friendly. My advice is try them all. Oh and FreeBSD.

openSUSE

For desktop use, check out Mint.

>When can we have a system that updates itself without breaking stuff?

We did, it was called CentOS.

You probably installed those things with some third-party installer, instead of through the package manager. You can't expect Ubuntu to know about that. The only way it could not break those things is by never upgrading the kernel.

It also gained them a reputation as literally the only operating system that cares one whit for backwards compatibility, which is one of the reasons it has such high penetration, especially in enterprise. Linux explicitly has no kernel ABI guarantees, and Apple gleefully breaks shit between minor releases.