[MIR] vde2

[Joseph Coffland]

Binary package hint: vde2

I've check the https://wiki.ubuntu.com/MainInclusionProcess requirements. I believe vde2 meets all of these. It is also already in Debian sid http://packages.debian.org/source/sid/vde2.

Including vde2 in main would allow KVM to build dep libvde-dev and to build with native VDE support by default. This would be very beneficial for those of us using VDE for virtual networking of VMs in Ubuntu.

Currently I am rebuilding the KVM source package with libvde-dev installed and VDE support is enabled automatically.

[Michael Terry (mterry)]

Is native VDE support part of a blueprint or just a nice-to-have? I'm trying to get a sense of rationale/importance.

[Joseph Coffland (jcoffland)]

vde2 makes it possible to create a virtual network for your VMs. This is an important tool for cloud computing. If Ubuntu wants to compete as a cloud computing solution this is a critical piece to the puzzle.

It shouldn't be much work to move vde2 into main. The package is well supported and tested. The KVM package will automatically build with vde2 support if it is added as a build dependency which can't happen until vde2 is brought in to main. The ultimate goal is to have vde2 support in KVM.

[Kees Cook (kees)]

Without sign-in from the Ubuntu KVM maintainers, I'd rather not commit to having this in main. It is a rather large bit of code, includes daemons, etc. I think making sure this is integrated sanely is the first step. Main promotion can happen later.

[Launchpad Janitor (janitor)]

[Expired for vde2 (Ubuntu) because there has been no activity for 60 days.]

[Ihor Kaharlichenko (madkinder)]

Is there any news regarding this issue? What do we need to know/whom to ask in order to make it fixed?

[Joseph Coffland (jcoffland)]

I'm still waiting for this as well. No one seems to want to do it.

Should be easy since it's already been a Debian package for several years. Just needs to be included in main and added as a build dep of kvm. No other configuration required as far as I know.

Regarding kees concern about adding a daemon in main, vde_switch is very quite. It uses very little memory and almost no CPU. I haven't had any problems running it for months. Much better behaved than other daemons already in main like pulseaudio.

I've been rebuilding the kvm package from source. Works fine and automatically configures vde support as long as the vde2 package is installed before the kvm package is built.

I carefully read the requirements for MIR and followed directions. I would be nice to know that if you RTFM your voice will be heard. Nudge nudge.

[Michael Terry (mterry)]

I think the best way forward for this is to file a bug against kvm in Ubuntu and suggest adding vde2 as a dependency/recommends. If this happens and vde2 is well-integrated into kvm, you should re-open this bug.

[Joseph Coffland (jcoffland)]

@Michael Terry I reported this against vde2 over a year ago. Then I was told I needed to file a MIR.

The bug report you are suggesting already exists: bug 253230. Here's a line from that report, "It's been open for years and lead to nothing."

  1) There is clearly demand for vde2 support in KVM.
  2) It's fairly simple to add.
  3) Nearly all the work is already done.
  4) It's sat around for years with no action.

I know how hard it is to manage a public bug tracker. I've got first hand experience. I can only imagine how difficult it is to do so for an entire Linux distribution. So I feel your pain. But how can we make this happen? How much noise do I need to make to get some oil?

[Michael Terry (mterry)]

Joseph, ah! Thanks for the bug link. That provides some of the missing rationale and history behind this MIR.

I understand your frustration, but part of the reason for this particular delay is that the people reviewing MIRs are busy and not domain experts in everything. Because the original description didn't reference bug 253230, from our perspective, this request didn't seem to flow naturally from a desire of the kvm packagers to use vde2. Now that I see that a developer with domain knowledge (Dustin Kirkland) would enable vde2 support if it were in main and requested that you file this MIR, it makes sense to proceed.

Obviously, this won't get into Ubuntu 11.10. But it's reasonable that it could for 12.04. Thanks Joseph for sticking with it so far.

Kees's point about the daemon was likely less about its resource requirements than possible security issues. This should be reviewed by Ubuntu's security team, so I'm assigning to them.

[Joseph Coffland (jcoffland)]

@Michael Terry I guess I should have linked to the original bug in the first place. I don't mean to be a pain but some times you have to whine a little to get things rolling.

Hopefully security won't be an issue. The Debian guys are pretty good about this stuff and it passed there approval. But of course a proper check is in order. Anything I can do to help here?

Thanks!

[Serge Hallyn (serge-hallyn)]

@mterry,

I assume that there is nothing for now for the server team to do then, right? (AIUI we can't put the vde lib in build-depends for kvm without those libs being in main).

Just making sure - thanks!

[Michael Terry (mterry)]

Joseph and Serge, not much to do yet, unless you're on the security team. After 11.10 is out and there's a development lull, occasionally poking security people on IRC (judiciously!) might speed things up.

[Jamie Strandboge (jdstrand)]

I'm in the kvm session (UDS P) right now, and it is unclear if the server team actually wants this. If someone from the server team can confirm that this is in fact desired by the team, I'd be happy to review it. Reassigning to server team for now.

[Joseph Coffland (jcoffland)]

Dustin Kirkland (kirkland) - Server team member - wrote in the related bug 253230:

  "Actually, I had to revert this change. libvdeplug2-dev (vde2) is in Universe. We'll need to get an MIR filed/approved before we can have kvm build-dep on it."

Now that we have the MIR maybe Dustin can approve this so the security team can move forward on it.

Thanks!

[Serge Hallyn (serge-hallyn)]

@Jamie: In my opinion the answer is "users want it, so server team wants it." I realize that even if there were time, MIR team is overloaded at the moment. So I'd like to talk to you about this again at UDS.

[Serge Hallyn (serge-hallyn)]

Hi Jamie,

this is desired by the server team :)

[Serge Hallyn (serge-hallyn)]

Bump - is this one feasible for raring? It would be one less bit of delta from debian's qemu.

[Seth Arnold (seth-arnold)]

- No CVE history
- No init scripts, cron jobs, dbus services, fscaps, setuid, sudo
- Limited use of setuid(2), more extensive use of chown(2) indicates much
  expects to run as root
- No binaries use PIE or BINDNOW
- No testsuite
- Daemons started with if-up-down.d scripts; some daemons can be configured
  to listen externally
- Some daemons do not daemonize themselves; others do, cryptcap does poorly
- postrm cleans up postinst
- Extensive compiler warnings:
  - Ignores return values from many instances of write(2), writev(2),
    chown(2), asprintf(3), fchdir(2), daemon(3), pipe(2)
- Memory allocations rarely checked for failure
- Some string copies are safe; others are needlessly complicated and ignore
  useful standardized library functions such as strdup(3)
- Code rarely checks for error conditions, or emits error conditions that
  are not checked by calling functions
- HOME environment variable is assumed to be safe, probably fine
- Uses OpenSSL solely for hard-coded Blowfish use
- Calls EVP_CIPHER_CTX_cleanup() after every packet; only calls
  EVP_CIPHER_CTX_init() once at first use. I do not know if this is safe or
  not.
- crc32 code is broken (compares crc32 values with strncmp(3) rather than
  memcmp(3)) (https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/1119988)
- crc32 code may contain BE/LE bug (untested)
- Some routines leak memory under failure conditions
- Some CPP macros are poorly implemented, shows disregard for professional
  programming practices

NAK as it stands. There are a number of problems and I'd prefer to keep
this out of main. If this software is strategic, then we could probably
support it if the compiler warnings were fixed, memory allocations
return codes checked and handled, dlopen concerns addressed, PIE and
BINDNOW enabled, add AppArmor profiles provided for binaries processing
untrusted input, and fix bugs #1119977 #1119982 #1119983 #1119984
#1119985 #1119999.

Thanks

[Jamie Strandboge (jdstrand)]

Thanks for the review Seth. Marking "Won't Fix" for now. If someone wants to take up the development work needed, then please assign to yourself and mark as "In Progress".

[Marco Giusti (marco-giusti)]

Would it impratical/impossibile to include only libvdeplug in main and leave all the other vde's packages in universe?

[Michael Terry (mterry)]

@mg, yes that is an option. Having just libvdeplug would be enough to enable kvm's integration for vde without having to promote the rest of vde. But there's little evidence that the security issues Seth found are not present in libvdeplug...

[Marco Giusti (marco-giusti)]

@mterry, thank you for your kind reply. Because I read the code, I could say that many of Seth's objections do not apply anymore. The libvdeplug2's code base is also pretty small: 885 lines of code with comments, empty lines and the relative header. I would be glad to take care of any issues proposed against this specific library.

[Michael Terry (mterry)]

Seth, do you want to comment? Looks like maybe we can avoid the worst of your findings if we merely promote the library itself and leave the other binaries in universe. That would at least unblock KVM from supporting it.

I don't know if you happen to remember which of your comments applied to the library vs the main vde app.

[Marco Giusti (marco-giusti)]

Any progress on this?

[Sebastian Unger (sebunger44)]

Is it really this hard to get 885 lines of code promoted into main?

[Serge Hallyn (serge-hallyn)]

It's very hard, and it should be.

I'm not on the security team, but I suspect they'd be more inspired to "just take another look" if someone went through Seth's feedback in comment #18 and for each item (plus each bug that he lists) say whether you believe it is fixed. For instance he lists bug 1119984. Is it solved, or can it be ignored if we go with @mterry's suggestion since it's not in the library part?

[Jamie Strandboge (jdstrand)]

Part of the requirements for main inclusion is a bug subscriber who will maintain the package in Ubuntu outside of security updates. Will the server team sign up for maintenance? Please resubscribe back to ubuntu-security if so.

[Christian Ehrhardt  (paelzer)]

Not volunteering to own this for now - set Won't Fix to be out of re-triage