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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel