Comment 10 for bug 1220950

>> I explicitly do not like "the ability to modify the guest". I'm very
>> much adverse to Microsoft's attempt at the same thing in
>> walinux-agent, giving their hypervisor the ability to run arbitrary code
>> as root inside the instance. I think this is unsupportable design and do
>> not want to facilitate it.

> This concern is really about the images, not about the fitness of the
> package for main.

Only "sort of".

> I also think that the concern is valid for systems where there is a
> facility for first boot provisioning, but invalid on systems where agent
> provisioning is needed. And I think that this is really an ideological
> one. To say that we don't want to facilitate it means that we are
> leaving users that use or run on first-bootless hypervisors. But the
> same could be said for chef and puppet, and other configuration
> management suites; the difference here is who is running the code.

Yes. That is the important difference. If a user changes something in
their "first boot" code, and it breaks, its their fault, or at very least
they have control to fix it, because they (should) know exactly what they
changed, and can update or address it.

If the hypervisor changes the code that *it* chooses to execute on the
users' behalf from inside their VMs, and *that* breaks, whose fault is it?

My issue with this is not hypervisor vendor nor hypervisor specific. The
issue is that some party other than the user is going to attempt to
execute code inside the instance, and that Ubuntu cannot know what that
code is, nor control its behavior or release process. In order to be
"cross distro", this code is quite likely to do things like check
/etc/lsb_release or /etc/issue, and try to derive information from other
files in /etc/ (/etc/udev.d, /etc/shadow ..). It also possibly does
things that Ubuntu would not certify as "supported". Perhaps it enables
additional repositories or loads additional kernel modules.

There is no sane way in which Ubuntu could hope to keep our code working
across releases or even within an SRU. Any change Ubuntu makes can
potentially break this code.

There is essentialy no difference here between *user* written code that
does that and hypervisor-vendor written code, other than who can fix the
code. If the change comes from the hypervisor, then the user quite
possibly has no way to fix, and Ubuntu quite possibly has no way to fix.
This leaves the user and ubuntu dependent on the hypervisor to never break
anything.

There is a shift here from the "platform" that code ran on being bios and
hardware to being some all knowing entity that changes from day to day.
From the OS perspective, this is very difficult to support.
That is what scares me.

>> Arguably, in a cloud scenerio, a user has to inherently trust the
>> vendor..

>> If our goal is to be the best operating system in the cloud, then
>> providing for a supported, official way to provision on systems like
>> WIndows Azure and VMware just make sesne. Ideology asside, the question
>> should be whether the package meets the contraints of main inclusion
>> and if the package is useful.

Its not just idealogy. By putting this in main, we're essentially
promising that we're not going to break it in an SRU for 5 years, and we
have no real way of doing that.

I agree that its possible I'm overstating this. I don't know just how
clever the hypervisor thinks it is, but by providing the interface to
execute arbitrary code, we're explicitly allowing it to "do whatever you
want". And by inclusion by default, we're passing that agreement on to
the end user.

I consider that level of trust significantly different than the inherent
trust in a cloud provider to not do things like poke at an instances'
memory and glean information from that.