* Re: [Qemu-devel] [RFC] host and guest kernel trace merging [not found] ` <20160304111933.GB626@stefanha-x1.localdomain> @ 2016-03-04 13:23 ` Steven Rostedt [not found] ` <20160307151705.GD20937@stefanha-x1.localdomain> 0 siblings, 1 reply; 3+ messages in thread From: Steven Rostedt @ 2016-03-04 13:23 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Luiz Capitulino, kvm, yoshihiro.yunomae.ez, mtosatti, qemu-devel, linux-trace-users, peterx, stefanha, pbonzini On Fri, 4 Mar 2016 11:19:33 +0000 Stefan Hajnoczi <stefanha@gmail.com> wrote: > > 2. Build a trace-cmd-server > > > > Which does the following: > > > > 1. Receive trace-cmd record commands from a guest, > > to be performed in the host > > Sometimes the opposite is desirable: the host controls tracing inside > the guest. Any thoughts on this use case? My idea for a trace-cmd server, is to have a --client operation, for running on the guest. trace-cmd server --client <connection> The connection will be some socket, either network or something directly attached to the host. Then on the host, we can have trace-cmd server --connect <guest> Where the server will create a connection to the guest. And then, you could run on the host: trace-cmd record <host-events> --connect <guest> <guest-events> And this will start recording host events, and then connect to the local server that connects to the guest(s) and that will start tracing on the guest as well. Then events on the guest will be passed to the host server. Something like this is my idea. We can work out the details on the best way to get things working. We may be able to eliminate the host server middle man. But I envision that we need a trace-cmd server running on the guest to start off the commands. The problem I have with the guest server, and something that we may be able to fix later on, but should always keep it in the back of our minds, is the security issue. For this to work, the guest server needs to run as root. It will have an open socket (network or to host), that will enable tracing on the guest. There needs to be some sort of verification on that connection to prevent anyone from connecting to it. In the protocol for the connection between guest and host, I'll currently add a "security" feature, that will allow the guest to tell whomever is connecting to it, what type of security feature it wants. For now it will be TRACE_CMD_NO_SECURITY. But that will have to change in the future. -- Steve > > > 2. Read the TSC offset for vCPUs being traced > > > > 3. Read the CPU frequency for --ts2secs > > > > 4. Receive the guest.dat from the guest and store it together > > with the host's > > > > I'd suggest the default communication between guest and > > host be via networking. Then we add vsock support when it's > > available. ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20160307151705.GD20937@stefanha-x1.localdomain>]
* Re: [Qemu-devel] [RFC] host and guest kernel trace merging [not found] ` <20160307151705.GD20937@stefanha-x1.localdomain> @ 2016-03-07 15:49 ` Steven Rostedt [not found] ` <56DDA7E2.3050506@redhat.com> 0 siblings, 1 reply; 3+ messages in thread From: Steven Rostedt @ 2016-03-07 15:49 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Stefan Hajnoczi, Luiz Capitulino, kvm, yoshihiro.yunomae.ez, mtosatti, qemu-devel, linux-trace-users, peterx, pbonzini On Mon, 7 Mar 2016 15:17:05 +0000 Stefan Hajnoczi <stefanha@redhat.com> wrote: > qemu-guest-agent runs inside the guest and replies to RPC commands from > the host. It is used for backups, shutdown, network configuration, etc. > From time to time people have wanted the ability to execute an arbitrary > command inside the guest and return the output. This functionality has > never been merged, probably for the security reason. How's the connection set up. That is, how does it know the commands are coming from the host? And how does it know that the commands from the host is from a trusted source? If the host is compromised, is there anything keeping an intruder from controlling the guest? > > A tracing server that runs inside the guest is comparable to > qemu-guest-agent. As long as the tracing server requires manual > commands to start it and does not run by default, then I think the > security issue can be kept at bay. It's a powerful tool that requires > explicit guest administrator action to enable. This isn't something I would expect to be started by default. My worry is that once it is started, then you open up a connection that can be attached by pretty much anyone. We could make a network socket that only communicates with the host, but even that worries me. I'm worried that the host may have actors that might compromise the system. -- Steve ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <56DDA7E2.3050506@redhat.com>]
* Re: [Qemu-devel] [RFC] host and guest kernel trace merging [not found] ` <56DDA7E2.3050506@redhat.com> @ 2016-03-07 16:26 ` Steven Rostedt 0 siblings, 0 replies; 3+ messages in thread From: Steven Rostedt @ 2016-03-07 16:26 UTC (permalink / raw) To: Eric Blake Cc: Stefan Hajnoczi, kvm, Stefan Hajnoczi, yoshihiro.yunomae.ez, mtosatti, qemu-devel, peterx, Luiz Capitulino, linux-trace-users, pbonzini On Mon, 7 Mar 2016 09:10:10 -0700 Eric Blake <eblake@redhat.com> wrote: > On 03/07/2016 08:49 AM, Steven Rostedt wrote: > > On Mon, 7 Mar 2016 15:17:05 +0000 > > Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > > >> qemu-guest-agent runs inside the guest and replies to RPC commands from > >> the host. It is used for backups, shutdown, network configuration, etc. > >> From time to time people have wanted the ability to execute an arbitrary > >> command inside the guest and return the output. This functionality has > >> never been merged, probably for the security reason. > > > > How's the connection set up. That is, how does it know the commands are > > coming from the host? And how does it know that the commands from the > > host is from a trusted source? If the host is compromised, is there > > anything keeping an intruder from controlling the guest? > > qemu-guest-agent uses a virtio channel, so only the host can be driving > that channel. But how can a guest know that it trusts the host? It > can't. A compromised host implicitly compromises all guests, and that's > always been the case. At least qemu-guest-agent doesn't make the window > any larger. > I should have been a bit more clear about what I meant by "host is compromised". I should have asked, what about untrusted tasks on the host. Is the channel protected where only admin users can access it? Of course, one of my concerns with the trace-cmd server is that it may require a network connection, because doesn't a virtio channel require to be initialized at boot up? Where the host must have an active listener when the guest starts? Or am I thinking about something else. -- Steve ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-03-07 16:26 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20160303143501.0edf21a2@redhat.com> [not found] ` <20160304111933.GB626@stefanha-x1.localdomain> 2016-03-04 13:23 ` [Qemu-devel] [RFC] host and guest kernel trace merging Steven Rostedt [not found] ` <20160307151705.GD20937@stefanha-x1.localdomain> 2016-03-07 15:49 ` Steven Rostedt [not found] ` <56DDA7E2.3050506@redhat.com> 2016-03-07 16:26 ` Steven Rostedt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).