4 ms·

There's a chance that there could be a useful intersection between 'mature, useful but risky troubleshooting tool' (SystemTap) and 'modern, resource-bounded tra

by jka 7y ago

There's a chance that there could be a useful intersection between 'mature, useful but risky troubleshooting tool' (SystemTap) and 'modern, resource-bounded tracing interface' (BPF) here. SystemTap has implemented prototype support[1] for BPF, although I'd expect it's not yet widely used or tested. BPF itself has had a bit of a history of security issues[2] but it appears to be stabilizing, and can theoretically be a lot safer than approaches like SystemTap which require runtime kernel-level code to be inserted. [1] - https://sourceware.org/git/?p=systemtap.git;a=blob;f=README;h=e14cdf97abe13a470d9fa674a34fb7bc5f49ba3c;hb=HEAD#l110 https://sourceware.org/git/?p=systemtap.git;a=blob;f=README;... [2] - https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=BPF https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=BPF

znpy 7y ago
The problem is probably Ubuntu. Systemtap works beautifully under rhel/centos, but it's a pain to make it work on Ubuntu. This has slown down adoption by a lot. We could have had dynamic tracing in gnu/Linux a lot earlier if Ubuntu had done a better job at supporting it. This is no surprise though: canonical has often refused to adopt stuff that have been thoroughly tested and vetted in the rhel world: think of firewalld Vs ufw. Or selinux Vs apparmor. Or cockpit, that has no equivalent in the canonical world afaik.
- simion314 7y ago
  >This is no surprise though: canonical has often refused to adopt stuff that have been thoroughly tested and vetted in the rhel world: think of firewalld Vs ufw. Or selinux Vs apparmor. Or cockpit, that has no equivalent in the canonical world afaik. Ubuntu is baded on Debian, if Red Hat stuff is not in Debian is hard to blame Canonical and not Debian but let me know this mental gymnastics of blame shifting
  - IntelMiner 7y ago
    Ubuntu is based on Debian, but /is/ not Debian It's worth noting that Canonical also has a pretty well-known history of being a "bad player" in the wider community. They rarely upstream patches, break things and very much try to "do their own thing" The more cynical of us think its Canonical attempting to segment Ubuntu off from the wider Linux ecosystem to force some kind of "vendor lock-in" by virtue of being the "newbie friendly" Linux option Some of the more egregious examples of things they forked were "small" pieces of the stack. Like the entire fucking desktop environment (Unity) and display server (Mir). Relying on things like Ubuntu-specific forks of GTK and other critical components, which is why those technologies never appeared in other distributions Anecdotally I've also been told by people who work at Red Hat that a lot of Canonical employees were picked up about a year ago after being terminated (allegedly) for attempting to upstream the code they worked on Feel free to wave it off as "mental gymnastics" or "blame shifting" but I do genuinely believe that Canonical has an intentionally poisonous effect on the wider Linux ecosystem
    - simion314 7y ago
      Unity was not a fork but a new project, so use a bit of logic and less emotion and honestly answer this "Who forked GNOME2 and GNOME3 ? " because you have a ton of GNOME forks because but if Canonical does it's own DE is evil but if someone forks MAte,Elementary,Cinemon etc is cool. I think unless Canonical removed a lot of RedHat tech from Debian and replaced it with their own then you are just complaining that Debian is not a big fan of RH tech.
  - readams 7y ago
    selinux at least has always been a nightmare on rhel for me.
    - jandrese 7y ago
      Apparmor is no picnic either. I appreciate that they have all of these graphical tools to help diagnose problems and notifications that appear on the desktop when something is blocked, but that is less helpful on a minimal headless server install where you're more likely to have those features turned on.
- pstrateman 7y ago
  systemd was designed at redhat by a redhat engineer. that it doesn't work on anything else properly is pretty clearly a feature, not a bug
  - viraptor 7y ago
    The parent comment was about systemtap, not systemd. + that's a very cynical opinion without supporting information.
ajross 7y ago
> theoretically be a lot safer I can see a practical argument for safety, but the theory is exactly the same here: both techniques inject arbitrary runtime code into the kernel. That code could do bad things, and so it has to be validated. The location of the validation in the architecture is different, but it's a practical difference. As far as my personal opinion? ?!@$#!@ just pick one, folks. The time for dueling tracing paradigms was like 8 years ago.

by jka 7y ago

znpy 7y ago

The problem is probably Ubuntu. Systemtap works beautifully under rhel/centos, but it's a pain to make it work on Ubuntu. This has slown down adoption by a lot. We could have had dynamic tracing in gnu/Linux a lot earlier if Ubuntu had done a better job at supporting it. This is no surprise though: canonical has often refused to adopt stuff that have been thoroughly tested and vetted in the rhel world: think of firewalld Vs ufw. Or selinux Vs apparmor. Or cockpit, that has no equivalent in the canonical world afaik.

simion314 7y ago
>This is no surprise though: canonical has often refused to adopt stuff that have been thoroughly tested and vetted in the rhel world: think of firewalld Vs ufw. Or selinux Vs apparmor. Or cockpit, that has no equivalent in the canonical world afaik. Ubuntu is baded on Debian, if Red Hat stuff is not in Debian is hard to blame Canonical and not Debian but let me know this mental gymnastics of blame shifting
- IntelMiner 7y ago
  Ubuntu is based on Debian, but /is/ not Debian It's worth noting that Canonical also has a pretty well-known history of being a "bad player" in the wider community. They rarely upstream patches, break things and very much try to "do their own thing" The more cynical of us think its Canonical attempting to segment Ubuntu off from the wider Linux ecosystem to force some kind of "vendor lock-in" by virtue of being the "newbie friendly" Linux option Some of the more egregious examples of things they forked were "small" pieces of the stack. Like the entire fucking desktop environment (Unity) and display server (Mir). Relying on things like Ubuntu-specific forks of GTK and other critical components, which is why those technologies never appeared in other distributions Anecdotally I've also been told by people who work at Red Hat that a lot of Canonical employees were picked up about a year ago after being terminated (allegedly) for attempting to upstream the code they worked on Feel free to wave it off as "mental gymnastics" or "blame shifting" but I do genuinely believe that Canonical has an intentionally poisonous effect on the wider Linux ecosystem
  - simion314 7y ago
    Unity was not a fork but a new project, so use a bit of logic and less emotion and honestly answer this "Who forked GNOME2 and GNOME3 ? " because you have a ton of GNOME forks because but if Canonical does it's own DE is evil but if someone forks MAte,Elementary,Cinemon etc is cool. I think unless Canonical removed a lot of RedHat tech from Debian and replaced it with their own then you are just complaining that Debian is not a big fan of RH tech.
- readams 7y ago
  selinux at least has always been a nightmare on rhel for me.
  - jandrese 7y ago
    Apparmor is no picnic either. I appreciate that they have all of these graphical tools to help diagnose problems and notifications that appear on the desktop when something is blocked, but that is less helpful on a minimal headless server install where you're more likely to have those features turned on.
pstrateman 7y ago
systemd was designed at redhat by a redhat engineer. that it doesn't work on anything else properly is pretty clearly a feature, not a bug
- viraptor 7y ago
  The parent comment was about systemtap, not systemd. + that's a very cynical opinion without supporting information.

ajross 7y ago

> theoretically be a lot safer I can see a practical argument for safety, but the theory is exactly the same here: both techniques inject arbitrary runtime code into the kernel. That code could do bad things, and so it has to be validated. The location of the validation in the architecture is different, but it's a practical difference. As far as my personal opinion? ?!@$#!@ just pick one, folks. The time for dueling tracing paradigms was like 8 years ago.