[MIR] systemtap

[Robert Ancell]

Availability: In Debian and Ubuntu universe
Rationale: Require for ust (MIR bug 1203589)
Security: No know security problems
Quality assurance: No known problems
UI standards: N/A
Dependencies: All in main
Standards compliance: Compliant
Maintenance: Continue to sync from Debian, issues managed by Canonical

[Michael Terry (mterry)]

I'm still looking at this, but the tests should be run. They aren't run during build because they are designed to be run against an installed systemtap, but that's where dep8 comes in. Especially now that dep8 results are used for proposed migration.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526957 for a discussion of the tests in Debian and a link to a git repo that enables dep8 tests.

[Michael Terry (mterry)]

Another blocker is the lack of a team subscriber in Ubuntu. Some team should be helping to maintain this in Ubuntu and be subscribed to bugs. Arguably closing bug 1144040 in the process.

This will also need a quick security audit.

 I like that we're in sync right now, and it seems well maintained in Debian. Packaging is complex, but clean. Besides the above 3 issues (tests, subscriber, security), looks good.

[Seth Arnold (seth-arnold)]

Why does Mir need to dynamically insert tracing code into the kernel?

Thanks

[Timo Juhani Lindfors (timo-lindfors)]

Is that for use with lttng user space tracepoints? Do they need CONFIG_UPROBES? (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691167 )

[Jamie Strandboge (jdstrand)]

I would quite prefer systemtap not be promoted to main because it actually does have a security history:
CVE-2008-1514
CVE-2009-0784
CVE-2009-2911
CVE-2009-4273
CVE-2010-0411
CVE-2010-0412
CVE-2010-4170
CVE-2010-4171
CVE-2011-1769
CVE-2011-1781
CVE-2011-2502
CVE-2011-2503
CVE-2012-0875

Can someone please answer Seth's question?

[Jamie Strandboge (jdstrand)]

Sorry, CVE-2008-1514 was in the kernel, not systemtap.

[Timo Juhani Lindfors (timo-lindfors)]

I'd also like to understand the motivation behind this but meanwhile you should note that most of the security vulnerabilities can only be exploited by users that have been added to the privileged stapusr group. Just installing the package does not make you vulnerable.

[Frank Ch. Eigler (fche)]

Seth, the lttng-ust development bits don't require systemtap as a whole, but the sys/sdt.h header file.
(Systemtap is not for only kernel instrumentation these days, by the way; with dyninst can be used pure-userspace.)

[Jamie Strandboge (jdstrand)]

If that's the case, then we don't need a security review. systemtap the *source* and the systemtap-sdt-dev binary can go to main, but everything else should stay in universe.

[Jamie Strandboge (jdstrand)]

Note, /usr/bin/dtrace is shipped in systemtap-sdt-dev. It is a python program and would not run privileged, so it doesn't need the review either.

[Robert Ancell (robert-ancell)]

Team subscribed to bugs

[Robert Ancell (robert-ancell)]

Debian bug about enabling tests:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526957

[Michael Terry (mterry)]

OK, the systemtap-sdt-dev package can be promoted, but only that one. If it's just that package, we can skip the security review and the test requirement. But if we ever revisit promoting more, we should do both.

[Colin Watson (cjwatson)]

Moved to main. (component-mismatches-proposed wanted the systemtap-doc binary package as well, which is clearly harmless so I included it.)