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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 21/06/16 16:11, Ian Jackson wrote:
> 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.

...or libvirt, or xapi (should it ever be ported to libxl).

I think that having the option to pass an fd in would be useful and will
probably be wanted at some point; I think libvirt for instance should
probably be modified to use such an interface once it's available to
connect qemu to virtlogd.

> 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.

I wouldn't object to the functionality being in libxl, but it seems to
me like libxlu might be a better fit.

 -George

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