Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"):
> Here is what we have gathered so far:
...
> We can, however, just make recommendation that system administrators can
> easily set up and call it a day. There are suggestions that we can
> recommend conserver or sympathy, but I haven't seen a concrete viable
> proposal yet. What I hope is that we can have a document in tree in the
> end.

sympathy would need some extra engineering to become suitable.  It's
also not widely adopted.  (Not even in Debian, yet.  Sorry about that,
but in my defence it's not my project...)

> Another way is to invent our own "virtlogd" -- it could be a new daemon,
> it could be xenconsoled. The major concern is that we're adding a
> critical component to the system and it may not scale well. We can make
> a compromise by using non-blocking fd to make the new component less
> critical and doesn't hinder scalability.

I think this is probably the best answer.  We already have most of
this in the form of xenconsoled.

> Another way is to alter libxl API and ask the application to pass in a
> fd for logging. The major concern is that this is not suitable in the
> context of a security issue.

Any solution needs to work for xl as well as other users of libxl.  So
this is not a description of a solution option; rather it is a
proposal to move the functionality/glue/problem/whatever out of libxl
into xl.

IMO it would be best to come up with a solution that is suitable for
all users of libxl, and put it in libxl.  If this is not possible then
whatever we implement could go in libxlu.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel