4 ms·

> 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 pac

> 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.

wakawaka28 3y ago
>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.
- striking 3y ago
  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.
  - wakawaka28 3y ago
    >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.
- saurik 3y ago
  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 :/.
  - Arnavion 3y ago
    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.
  - wakawaka28 3y ago
    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.
kragen 3y ago
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/ http://www.catb.org/~esr/halloween/
- striking 3y ago
  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.

wakawaka28 3y ago

>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.

striking 3y ago
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.
- wakawaka28 3y ago
  >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.
saurik 3y ago
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 :/.
- Arnavion 3y ago
  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.
- wakawaka28 3y ago
  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.

kragen 3y ago

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/ http://www.catb.org/~esr/halloween/

striking 3y ago
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.