request to sign software

request to sign software

[Joanna Rutkowska]

[-- Attachment #1.1: Type: text/plain, Size: 619 bytes --]

Keir, Jeremy,

Just a rather obvious request that you digitally sign all the published
tgz packages, as well as hg/git tags, so that it was possible to ensure
that the software I download from xen.org (or fetch from Jeremy's GIT)
is authentic. This is especially important for those people who would
like to build (and distribute!) their own products based on Xen.

Hopefully you can start doing this with the upcoming 4.0.0 and 3.4.3
versions of Xen, and the "official" pvops kernels (hopefully there will
be some pvops commit tagged as "official"? I assume from
xen/stale-2.6.32.x?)

Thanks,
joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: request to sign software

[Jeremy Fitzhardinge]

On 03/28/2010 03:02 AM, Joanna Rutkowska wrote:
> Just a rather obvious request that you digitally sign all the published
> tgz packages, as well as hg/git tags, so that it was possible to ensure
> that the software I download from xen.org (or fetch from Jeremy's GIT)
> is authentic. This is especially important for those people who would
> like to build (and distribute!) their own products based on Xen.
>
> Hopefully you can start doing this with the upcoming 4.0.0 and 3.4.3
> versions of Xen, and the "official" pvops kernels (hopefully there will
> be some pvops commit tagged as "official"? I assume from
> xen/stale-2.6.32.x?)
>    

(I prefer to call it "stable", but I can see how one might get them 
confused ;)

That's an interesting idea.  But I don't think we have any 
infrastructure in place to make those signatures meaningful (ie, some 
way of usefully connecting a particular signature to a particular 
maintainer).

I guess the logical thing would be for xen.org to have a GPG cert, which 
could then sign our individual certs.  (Or something.  How does web of 
trust extend to "I'm confident this changeset is valid"?)  Then its just 
a problem of how to propagate the xen.org cert in some way so that some 
way that everyone agrees is meaningful.

On the other hand, I'm not sure how much value such signatures would 
have.  At the moment they would just certify "this is something I 
committed", but with not particular guarantees about any of the 
properties of that commit.   Commits to the stable (or any branch, of 
either kernel or Xen) are really a matter of best effort, but they may 
still be broken, insecure, etc.  Anyone using those trees bears some 
responsibility for making sure they meet their particular requirements 
(or delegate those qualification checks to someone they trust, like a 
distro).

If we added a specific meanings to tags (like, "this has passed 
automatic regression testing"), then adding a signature would perhaps be 
more meaningful.  But that signature would presumably be added by the 
test infrastructure rather than a committer.

Signatures on tar files makes a bit more sense, because they don't have 
the backing of git/hg to guarantee the integrity of the file contents, 
but there's still the question of how to make those signatures meaningful.

     J

Re: request to sign software

[Joanna Rutkowska]

[-- Attachment #1.1: Type: text/plain, Size: 4684 bytes --]

On 03/29/2010 07:47 PM, Jeremy Fitzhardinge wrote:
> On 03/28/2010 03:02 AM, Joanna Rutkowska wrote:
>> Just a rather obvious request that you digitally sign all the published
>> tgz packages, as well as hg/git tags, so that it was possible to ensure
>> that the software I download from xen.org (or fetch from Jeremy's GIT)
>> is authentic. This is especially important for those people who would
>> like to build (and distribute!) their own products based on Xen.
>>
>> Hopefully you can start doing this with the upcoming 4.0.0 and 3.4.3
>> versions of Xen, and the "official" pvops kernels (hopefully there will
>> be some pvops commit tagged as "official"? I assume from
>> xen/stale-2.6.32.x?)
>>    
> 
> (I prefer to call it "stable", but I can see how one might get them
> confused ;)
> 
> That's an interesting idea.  But I don't think we have any
> infrastructure in place to make those signatures meaningful (ie, some
> way of usefully connecting a particular signature to a particular
> maintainer).
> 
> I guess the logical thing would be for xen.org to have a GPG cert, which
> could then sign our individual certs.  (Or something.  How does web of
> trust extend to "I'm confident this changeset is valid"?)  Then its just
> a problem of how to propagate the xen.org cert in some way so that some
> way that everyone agrees is meaningful.
> 
gpg --gen-key

...and then publish it on xen.org and sent to xen-devel. The list is
mirrored in a few places, so it would not be trivial for the attacker to
subvert the public key in all the public archives. Users can always use
more than one different internet connections to verify the key, to get
around potential compromise at an ISP level.

This could be your "master key" and then you could simply sign other
keys (e.g. Jermey's, Keir's, etc) with this master key (simple gpg -s,
no certs, no web of trust, needed).

> On the other hand, I'm not sure how much value such signatures would
> have.  At the moment they would just certify "this is something I
> committed", but with not particular guarantees about any of the
> properties of that commit.   Commits to the stable (or any branch, of
> either kernel or Xen) are really a matter of best effort, but they may
> still be broken, insecure, etc.  Anyone using those trees bears some
> responsibility for making sure they meet their particular requirements
> (or delegate those qualification checks to someone they trust, like a
> distro).
> 

Digital signature are *not* meant to assure any property of the signed
entity, except for its integrity and authenticity. It's perfectly ok
that you might sign a buggy version of Xen or pvops kernel. Signing is
*not* assuring correctness!

The decision of whether to trust or not the vendor (e.g. Citrix, Jeremy,
etc) is beyond the scope of digital signatures.

However, once I made a decision to trust e.g. Ctrix and let their
hypervisor run on my hardware, in my network, and have access to all my
data, then I would like to make sure that it is only Cirtix that I need
to trust really. Not tens of other engineers that are in between me and
Citrix (or even more precisely Jeremy or Keir). Those tens (or
hundreds?) other people I need to trust today (i.e. when your software
is not signed) are e.g.:
1) all the IT stuff at Citrix that have access to xen.org webserver,
2) all the IT stuff at the data center where Citrix servers are hosted,
3) all the IT stuff having access to all the network routers (especially
at the ISP) that are between me and xen.org (or git.kernel.org)

And I also need to trust e.g. that WPA2 is secure, so I can assume that
when I'm downloading the latest Xen when sitting in my living room over
WiFi, that nobody that is in my vicinity can subvert this transmission
(which is, of course, HTTP over WiFi).

> If we added a specific meanings to tags (like, "this has passed
> automatic regression testing"), then adding a signature would perhaps be
> more meaningful.  But that signature would presumably be added by the
> test infrastructure rather than a committer.
> 

Please do not confuse digital signatures with a certification process.

Also, look at The Linus Tree, it has all the tags digitally signed, e.g:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tag;h=4ac8e07ee3f251ae32329a24e0b01a316b21ead9

And final argument -- one of the Xen's main selling points (especially
in case of client hypervisors) is *security*. You cannot build secure
product from building blocks that you cannot verify are coming from the
right supplier (that you chose to trust).

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: request to sign software

[Keir Fraser]

On 29/03/2010 22:09, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
wrote:

> ...and then publish it on xen.org and sent to xen-devel. The list is
> mirrored in a few places, so it would not be trivial for the attacker to
> subvert the public key in all the public archives. Users can always use
> more than one different internet connections to verify the key, to get
> around potential compromise at an ISP level.
> 
> This could be your "master key" and then you could simply sign other
> keys (e.g. Jermey's, Keir's, etc) with this master key (simple gpg -s,
> no certs, no web of trust, needed).

I chatted with Ian Jackson about this, and our thought was to generate a
xen.org master key which we would keep safe in Cambridge: only he and I
would have copies of it (the two of us, for redundancy). We can also
generate a software-signing key, signed by the master key, which we actually
use for the business of signing releases from the xen-*.hg and
qemu-xen-*.git repositories.

We weren't sure it makes sense for Jeremy to sign anything since he's not
actually making releases out of his repository. If we decide that Jeremy
should sign things I think it best he makes his own key and we sign it with
the master key.

 -- Keir

Re: request to sign software

[Joanna Rutkowska]

[-- Attachment #1.1: Type: text/plain, Size: 1800 bytes --]

On 03/30/2010 09:00 AM, Keir Fraser wrote:
> On 29/03/2010 22:09, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
> wrote:
> 
>> ...and then publish it on xen.org and sent to xen-devel. The list is
>> mirrored in a few places, so it would not be trivial for the attacker to
>> subvert the public key in all the public archives. Users can always use
>> more than one different internet connections to verify the key, to get
>> around potential compromise at an ISP level.
>>
>> This could be your "master key" and then you could simply sign other
>> keys (e.g. Jermey's, Keir's, etc) with this master key (simple gpg -s,
>> no certs, no web of trust, needed).
> 
> I chatted with Ian Jackson about this, and our thought was to generate a
> xen.org master key which we would keep safe in Cambridge: only he and I
> would have copies of it (the two of us, for redundancy). We can also
> generate a software-signing key, signed by the master key, which we actually
> use for the business of signing releases from the xen-*.hg and
> qemu-xen-*.git repositories.
> 
> We weren't sure it makes sense for Jeremy to sign anything since he's not
> actually making releases out of his repository. If we decide that Jeremy
> should sign things I think it best he makes his own key and we sign it with
> the master key.
> 
Right. But I think it would make lots of sense for Jeremy to tag, at
least some of the pvops branches (stable-2.6.{31.32}.x), anyway.
Otherwise this every-changing repo might scare away lots of people.
Perhaps Jeremy could apply some tag (and sign it) every week, or after
some more major merges, etc.

Would be nice e.g. to have some particular commit from the pvops marked
as the official release for the upcoming Xen 4.0.0, wouldn't it?

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: request to sign software

[Keir Fraser]

On 30/03/2010 10:46, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
wrote:

> Right. But I think it would make lots of sense for Jeremy to tag, at
> least some of the pvops branches (stable-2.6.{31.32}.x), anyway.
> Otherwise this every-changing repo might scare away lots of people.
> Perhaps Jeremy could apply some tag (and sign it) every week, or after
> some more major merges, etc.
> 
> Would be nice e.g. to have some particular commit from the pvops marked
> as the official release for the upcoming Xen 4.0.0, wouldn't it?

Indeed it would.

 K.

Re: request to sign software

[Ian Jackson]

Keir Fraser writes ("Re: [Xen-devel] request to sign software"):
> I chatted with Ian Jackson about this, and our thought was to generate a
> xen.org master key which we would keep safe in Cambridge: only he and I
> would have copies of it (the two of us, for redundancy). We can also
> generate a software-signing key, signed by the master key, which we actually
> use for the business of signing releases from the xen-*.hg and
> qemu-xen-*.git repositories.

Right.  I think the best plan is to have a master key we use for
certifying other keys, including probably a single key for each
relevant tree.

So we'll have a key for xen-*.hg which we'll use with the hg repo
signing support to sign 4.0.0, a key for qemu-xen-*.git likewise, and
probably at least one more key for signing tarball releases.

I trust Jeremy can generate his own special key for generating a
signed tag for a suitable pvops version.  Jeremy ?

The public half of the master key at least (and perhaps some of the
others) will be on the website and I'll cross-certify it with my own
personal PGP keys.

Ian.

Weird RAM handling with Xen 3.4.3-RC3

[Thomas Goirand]

Hi,

Using the latest Debian SID Xen kernel (pv_ops 2.6.32-4) that I compiled
in Lenny, I had weird RAM handling issues. Let me explain.

If in grub, I put:

kernel          /boot/xen-3.4-amd64.gz dom0_mem=2048M

then when starting KDM, it gets stuck and doesn't work. If I press e in
grub, remove the dom0_mem part, then my laptop is able to boot and start
X window. Quite annoying, because I quite want to use the directive. It
might be linked to the experimental version of the graphic driver that
I'm using, but I also read that others had issues with X, so I thought
this could be interesting.

Then another very strange behavior. Once I start using xend, I do:

root@GPLHost:buzzig>_ ~# xm info
total_memory           : 3990
free_memory            : 131
root@GPLHost:buzzig>_ ~# xm list
Name     ID   Mem VCPUs  State    Time(s)
Domain-0  0  3800     2  r-----   54.8
root@GPLHost:buzzig>_ ~# xm mem-set Domain-0 2048
root@GPLHost:buzzig>_ ~# xm list
Name     ID   Mem VCPUs  State    Time(s)
Domain-0  0  2048     2  r-----   56.3
root@GPLHost:buzzig>_ ~# xm info
total_memory           : 3990
free_memory            : 1113

After I set my dom0 to use 2048 MB of RAM, I get only 1113 MB of free
RAM. It as if a part of the RAM (829 MB of RAM) has gone! Quite wacko
isn't it? Could it be that the memory management is broken somehow? What
is going on here?

I posted the above to the Debian pkg-xen list, and Ian suggested me to
also send it here.

Thomas

Re: request to sign software

[Joanna Rutkowska]

[-- Attachment #1.1: Type: text/plain, Size: 871 bytes --]

On 03/29/2010 07:47 PM, Jeremy Fitzhardinge wrote:
> On 03/28/2010 03:02 AM, Joanna Rutkowska wrote:
>> Just a rather obvious request that you digitally sign all the published
>> tgz packages, as well as hg/git tags, so that it was possible to ensure
>> that the software I download from xen.org (or fetch from Jeremy's GIT)
>> is authentic. This is especially important for those people who would
>> like to build (and distribute!) their own products based on Xen.
>>
>> Hopefully you can start doing this with the upcoming 4.0.0 and 3.4.3
>> versions of Xen, and the "official" pvops kernels (hopefully there will
>> be some pvops commit tagged as "official"? I assume from
>> xen/stale-2.6.32.x?)
>>    
> 
> (I prefer to call it "stable", but I can see how one might get them
> confused ;)
> 
Sorry, just noticed this. Wasn't intentional ;)

j.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel