Is it intentional that - large parts of stubdom build with -j1 only irrespective of the original make invocation? - all imported packages are out of date? - pciutils is being built without 64-bit support (visible via warnings issued from the qemu build)? - the build produces dozens of compiler warnings quite a few of which don''t look benign at all? - can''t be built with a read-only and/or symlinked source tree? Also, what''s the point of the install-stubdom dependency on install-tools? Shouldn''t the individual components'' builds be independent of one another? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich writes ("[Xen-devel] stubdom
questions"):> Is it intentional that
> - large parts of stubdom build with -j1 only irrespective of the original
> make invocation?
I think we had some makefile concurrency bugs and this is the workaround.
> - all imported packages are out of date?
Yes, this is intentional. We don''t want to update these unless
necessary, really.
> - pciutils is being built without 64-bit support (visible via warnings
issued
> from the qemu build)?
Does this have any other adverse consequence ?
> - the build produces dozens of compiler warnings quite a few of which
> don''t look benign at all?
No, that not intentional.
> - can''t be built with a read-only and/or symlinked source tree?
No, that not intentional.
> Also, what''s the point of the install-stubdom dependency on
> install-tools? Shouldn''t the individual components''
builds be
> independent of one another?
I don''t know. The stubdom build system is a bit of a mess,
unfortunately.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("[Xen-devel] stubdom questions"): >> - pciutils is being built without 64-bit support (visible via warnings issued >> from the qemu build)? > > Does this have any other adverse consequence ?Pass-through may not work for devices with 64-bit resources (I don''t think any virtual devices would try to use 64-bit addresses)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 9 Nov 2010, Jan Beulich wrote:> >>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > Jan Beulich writes ("[Xen-devel] stubdom questions"): > >> - pciutils is being built without 64-bit support (visible via warnings issued > >> from the qemu build)? > > > > Does this have any other adverse consequence ? > > Pass-through may not work for devices with 64-bit resources (I > don''t think any virtual devices would try to use 64-bit addresses)? >Good point. However the current qemu-xen is incapable of dealing with 64 bit BARS anyway AKAIK. It could become a problem when we start using upstream qemu though. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich, le Tue 09 Nov 2010 10:44:23 +0000, a écrit :> - the build produces dozens of compiler warnings quite a few of which > don''t look benign at all?On which parts? I guess updating them might fix these warnings, and if not, issues should rather be reported upstream.> - can''t be built with a read-only and/or symlinked source tree?I''ve never tried, actually.> Also, what''s the point of the install-stubdom dependency on > install-tools? Shouldn''t the individual components'' builds be > independent of one another?I don''t know why, but it''s changeset: 21760:84719437205c user: Keir Fraser <keir.fraser@citrix.com> date: Fri Jul 09 12:22:52 2010 +0100 summary: Makefile: Serialise stubdom build after tools Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 09.11.10 at 21:48, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote: > Jan Beulich, le Tue 09 Nov 2010 10:44:23 +0000, a écrit : >> - the build produces dozens of compiler warnings quite a few of which >> don''t look benign at all? > > On which parts? I guess updating them might fix these warnings, and if > not, issues should rather be reported upstream.Some of them in qemu, many in newlib, I don''t recall detail right now for the others. Updating is, as IanJ responded, not an option (and hence eventual reporting upstream is also not useful from stubdom building perspective). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("[Xen-devel] stubdom questions"): >> - all imported packages are out of date? > > Yes, this is intentional. We don''t want to update these unless > necessary, really.So even security problems fixed in upstream packages are deemed to be of no concern (or if they are, need to be handled manually by adding patches)?> The stubdom build system is a bit of a mess, unfortunately.Are there intentions to get this cleaned up? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-11-10 at 10:01 +0000, Jan Beulich wrote:> >>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > Jan Beulich writes ("[Xen-devel] stubdom questions"): > >> - all imported packages are out of date? > > > > Yes, this is intentional. We don''t want to update these unless > > necessary, really. > > So even security problems fixed in upstream packages are deemed > to be of no concern (or if they are, need to be handled manually by > adding patches)? > > > The stubdom build system is a bit of a mess, unfortunately. > > Are there intentions to get this cleaned up?Sadly intentions are no substitute for time/manpower. Sounds like a good idea to me though. Gianni _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich writes ("Re: [Xen-devel] stubdom
questions"):> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Yes, this is intentional. We don''t want to update these
unless
> > necessary, really.
>
> So even security problems fixed in upstream packages are deemed
> to be of no concern (or if they are, need to be handled manually by
> adding patches)?
The libraries underlying stubdom aren''t exposed directly to hostile
data; they communicate only with the qemu in stubdom, and dom0.
Communication with the untrusted guest is done by the qemu code.
Furthermore, the stubdom itself is supposed to be no more trusted than
the guest it is servicing. So I think in theory almost all security
bugs in these libraries should be unexploitable in the stubdom
context.
If you could point to a counterexample that would be very interesting.
> > The stubdom build system is a bit of a mess, unfortunately.
>
> Are there intentions to get this cleaned up?
In the long term yes, but I don''t think we have it as a priority.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel