Hacker News Reader

Comment by kragen | Hacker News Reader

[flagged]

> It's a very simple approach. All it does is insert an ELF "note" into generated binaries that declare these deps. This information can then be consumed by package managers, initrd generators and other tools.

Lots of things already `dlopen`, lots of things already obscure their true dependencies by doing so. This RFC only provides a new section for those things to declare their dependencies without making the OS responsible for loading them. I think this actually improves the world for everyone, rather than just Microsoft.

Anyone is welcome to make contributions to Linux or the surrounding ecosystem.

>Lots of things already `dlopen`, lots of things already obscure their true dependencies by doing so. This RFC only provides a new section for those things to declare their dependencies without making the OS responsible for loading them.

The OS should be responsible for opening dependencies. Otherwise you get an unaccountable mess. The ELF note shit is just giving users a false sense of security.

>Anyone is welcome to make contributions to Linux or the surrounding ecosystem.

Ha! This certainly isn't true. Even if it was, the source of "contributions" deserves scrutiny.

At least on Linux and macOS, the "OS" never was responsible for this and I at least do not believe that it should become responsible for this; the kernel merely parses the header to see if it lists an "interpreter" and, if it does (as dynamic executables do), it loads that one binary (it might also load the original binary and pass its address as an argument to the interpreter). The interpreter is usually going to be something like /lib/ld.so, and is provided by the C standard library you linked against. You might have multiple copies that work very differently, and a new programming language can implement one that is nothing like the one from glibc or adds new features, etc. This program then parses the executable and does the moral equivalent of a dlopen on all of the dependencies.

That said, I do agree that doing this in "notes" is dumb, and if they need some new feature of ELF like "alternatives" they should at least be coordinating this with glibc if not deferring the spec entirely to them. Hell: given that they previously were actually linking these things, I don't understand why a lazy loaded weak symbol wouldn't work. Does ELF not support those somehow? I thought it did. I don't think systemd is at all the best project to be trying to think through this stuff as they are always much happier adding a new complex mechanism when existing ones would work fine. If ELF is currently missing lazy loading, they should work with glibc to add that feature correctly, not try to end-to-end it through the notes field :/.

To your last point, doing it without involving glibc does have the advantage that it'll also work with musl, instead of starting yet another flamewar about missing non-standard features in musl.

The whole ELF interpreter thing is a security hole as far as I'm concerned. I'm not an expert on it but as far as I know, the existence of ELF interpreters seems to make it impossible to get a definitive list of dependencies.

Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader, I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run. This is a completely unserious take that continues to misread the motivations of the RFC (it's not about security) and couldn't even be applied even to just the core of most actually used Linux userlands without an absurd amount of work (think of PAM modules and friends).

Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details.

>it's not about security

The comments here suggest otherwise. It certainly can't provide a security function.

>Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader,

I didn't propose that but certainly the ability to load and execute code from anywhere is a vulnerability waiting to happen. Not being able to accurately enumerate dependencies is also an issue. If the OS was solely responsible for locating and loading dependencies, you could analyze any executable in isolation and get a definitive list of dependencies.

>I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run.

Just because it is that way now doesn't mean it needs to be.

>Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details.

They do make contributions. But large corporations aren't "anyone" and their contributions are not unquestionable. They do have their own interests which are in conflict with the broader open-source ecosystem.

yes, the particular decisions could be fine or terrible; but having microsoft employees make them is a terrible idea

i mean microsoft is still the same company that makes your linux installations unbootable regularly when you install or upgrade windows, and which doesn't allow you to install linux on arm hardware designed for linux

i don't think they've changed that much since http://www.catb.org/~esr/halloween/

I was under the impression that many large corporate actors with interests in proprietary hardware and software make regular contributions to the Linux kernel and ecosystem.

Also, why does the person making the change matter? If they're not a vexatious time waster, then who cares who they are as long as the changes are coherent?

Finally, I'll note that the GitHub issue linked is against systemd/systemd. It's not a binding change to the entire ELF format, it's a request for maintainers of distros to comment on whether or not adding this optional field might be helpful to them. They can just say "no", and who published the RFC remains irrelevant.

What's the conflict? Microsoft now ships a Linux subsystem that's used by Docker for Windows. There's convergent interests here.

i'm not suggesting we try to stop microsoft from using linux, but they certainly shouldn't be making key architectural decisions

Is there evidence that any Microsoft execs are pressuring Poettering? Wouldn't other people that work on systemd and linux object to poor architectural decisions? This is a key feature of open source development, it's just not so easily subverted.

I mean, Microsoft pays him a regular paycheck. I think you're moving the goalpost quite a bit to ask that the community accept anyone's contributions until solid proof of malicious intent is shown.

Are you prepared to accept my contribution? I sign my name "JiaT57notThatJiaTan"

I'm not moving any goalposts, you're saying someone with decades of open source kernel development and a solid reputation is no longer trustworthy because of who now signs that paycheque. That's just nonsense, and has nothing to do with the scenario you posed.

HN Guidelines Checklist:

   [ ] When disagreeing, please reply to the argument instead of calling names. For example, arguing with "nonsense" and "has nothing to do with the scenario" detract from HN
   [ ] Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. Avoid saying "I'm not ___" in a reflexive way
   [ ] Please don't use Hacker News for political or ideological battle. That tramples curiosity such as for Lenart Poettering's "a solid reputation"
   [ ] Please don't complain that a submission is inappropriate.

This is not a "key architectural decision", it's a proposal for an informal standard on where/how to stick some metadata in an executable binary.

Most distributions care more about whether people deliver software that solves real problems, than worries about some contributor's employer's behaviour from the last century.

Not just the core of Linux user land, but also the pre-linux boot process with systemd-boot. Don't forget that MS has enormous influence over UEFI too.

MS is gaining a lot of technical influence in the open source world. As soon as the regulatory environment shifts, they're going to take advantage of that.

> wait, is poettering literally deciding how the core of linux userland should work, while also working at microsoft as an employee?

Only if we let him. Viva la open source!

Did you just travel here from 2003?

For someone who works at MS, I'm surprised he didn't try to add delay-load imports to ELF instead, which is the PE equivalent that's existed in Windows since Win32.

> glaring conflict of interest

Can you expand on that?

http://www.catb.org/~esr/halloween/

Well fair enough, I remember that with great excitement back in the day. Is it possible that MSFT has moved on from this perspective?

Reply on news.ycombinator.com