What fields should be used for reporting shared memory?

What fields should be used for reporting shared memory?

[Martin Kletzander]

[-- Attachment #1.1: Type: text/plain, Size: 1091 bytes --]

Hi,

I am going through the fields in the dictionary and I can't find any
name to use for the following scenario.

We (libvirt) are running virtual machines and there's a thing nowadays,
that people like to use, called ivshmem (Inter-VM SHared MEMory).  From
host's point of view this is just a shared memory region accessed by
multiple VMs (and possibly to host as well).  The machine maps the
shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to
be mapped) *or* it can communicate with a server over UNIX socket and
that server handles interrupts and also tells the client which shared
memory region to map.  Talking about information we have; in server-less
setup it's the shared memory region that is shared, in the server
scenario it is the socket.  That's information we can output.

So my question is, when starting a domain or hot-(un)plugging, what
naming should we use for this kind of device and what are the things
that we should describe about it?  Basically, how would you like the
message to look?

Thanks in advance for any info.

Have a nice day,
Martin

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What fields should be used for reporting shared memory?

[Steve Grubb]

Hello,

I apologize for the delay.

On Tuesday, March 14, 2017 7:42:27 AM EDT Martin Kletzander wrote:
> I am going through the fields in the dictionary and I can't find any
> name to use for the following scenario.
> 
> We (libvirt) are running virtual machines and there's a thing nowadays,
> that people like to use, called ivshmem (Inter-VM SHared MEMory).  From
> host's point of view this is just a shared memory region accessed by
> multiple VMs (and possibly to host as well).  The machine maps the
> shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to
> be mapped) *or* it can communicate with a server over UNIX socket and
> that server handles interrupts and also tells the client which shared
> memory region to map.

If both of these result in a path, then I think we want to log it as a 
resource event.

> Talking about information we have; in server-less
> setup it's the shared memory region that is shared, in the server
> scenario it is the socket.  That's information we can output.

Above you mentioned that the server communicates which region to map. Can you 
explain what that means?

> So my question is, when starting a domain or hot-(un)plugging, what
> naming should we use for this kind of device and what are the things
> that we should describe about it?  Basically, how would you like the
> message to look?

We need a record recording what is getting assigned to the VM. In the case of 
the /dev/shm, you can record that as a path which must be escaped. In the case 
of the server, I think we still need to understand what is happening. Just 
recording a socket number or path is not terribly useful in reconstructing the 
resources given to the VM.

Audit events have to tell a story. There is a subect, object, action, and 
results. It kind of needs to be a sentence. "libvirtd successfully assigned 
____ to vm-name."

-Steve

> Thanks in advance for any info.
> 
> Have a nice day,
> Martin

Re: What fields should be used for reporting shared memory?

[Martin Kletzander]

[-- Attachment #1.1: Type: text/plain, Size: 2451 bytes --]

On Thu, Mar 16, 2017 at 09:04:52PM -0400, Steve Grubb wrote:
>Hello,
>
>I apologize for the delay.
>
>On Tuesday, March 14, 2017 7:42:27 AM EDT Martin Kletzander wrote:
>> I am going through the fields in the dictionary and I can't find any
>> name to use for the following scenario.
>>
>> We (libvirt) are running virtual machines and there's a thing nowadays,
>> that people like to use, called ivshmem (Inter-VM SHared MEMory).  From
>> host's point of view this is just a shared memory region accessed by
>> multiple VMs (and possibly to host as well).  The machine maps the
>> shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to
>> be mapped) *or* it can communicate with a server over UNIX socket and
>> that server handles interrupts and also tells the client which shared
>> memory region to map.
>
>If both of these result in a path, then I think we want to log it as a
>resource event.
>

Yes, and they both are resources in its sense. So you are talking
particularly about the resrc= field?  Should that also have category and
class or anything else set?  Or do you mean we report the path in the
resrc= field?

>> Talking about information we have; in server-less
>> setup it's the shared memory region that is shared, in the server
>> scenario it is the socket.  That's information we can output.
>
>Above you mentioned that the server communicates which region to map. Can you
>explain what that means?
>

The server sends a file descriptor to the VM over the socket, details
can be found here:

http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem-spec.txt#l151

>> So my question is, when starting a domain or hot-(un)plugging, what
>> naming should we use for this kind of device and what are the things
>> that we should describe about it?  Basically, how would you like the
>> message to look?
>
>We need a record recording what is getting assigned to the VM. In the case of
>the /dev/shm, you can record that as a path which must be escaped. In the case
>of the server, I think we still need to understand what is happening. Just
>recording a socket number or path is not terribly useful in reconstructing the
>resources given to the VM.
>
>Audit events have to tell a story. There is a subect, object, action, and
>results. It kind of needs to be a sentence. "libvirtd successfully assigned
>____ to vm-name."
>
>-Steve
>
>> Thanks in advance for any info.
>>
>> Have a nice day,
>> Martin
>
>

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What fields should be used for reporting shared memory?

[Steve Grubb]

On Monday, March 20, 2017 7:36:14 AM EDT Martin Kletzander wrote:
> On Thu, Mar 16, 2017 at 09:04:52PM -0400, Steve Grubb wrote:
> >Hello,
> >
> >I apologize for the delay.
> >
> >On Tuesday, March 14, 2017 7:42:27 AM EDT Martin Kletzander wrote:
> >> I am going through the fields in the dictionary and I can't find any
> >> name to use for the following scenario.
> >> 
> >> We (libvirt) are running virtual machines and there's a thing nowadays,
> >> that people like to use, called ivshmem (Inter-VM SHared MEMory).  From
> >> host's point of view this is just a shared memory region accessed by
> >> multiple VMs (and possibly to host as well).  The machine maps the
> >> shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to
> >> be mapped) *or* it can communicate with a server over UNIX socket and
> >> that server handles interrupts and also tells the client which shared
> >> memory region to map.
> >
> >If both of these result in a path, then I think we want to log it as a
> >resource event.
> 
> Yes, and they both are resources in its sense. So you are talking
> particularly about the resrc= field?  Should that also have category and
> class or anything else set?  Or do you mean we report the path in the
> resrc= field?

No, I mean we would want the path to the memory in a VIRT_RESOURCE event. :-)  
How about something like this:

type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 
msg='virt=kvm resrc=shmem reason=start vm="rhel7.3" uuid=a7708061-
faa0-42ce-897a-e92fb75fcf1d size=4194304 path="/dev/shm/my_shmem1" exe="/usr/
sbin/libvirtd" hostname=? addr=? terminal=? res=success'

Having the full path would make it more normal when reporting on files in use.


> >> Talking about information we have; in server-less
> >> setup it's the shared memory region that is shared, in the server
> >> scenario it is the socket.  That's information we can output.
> >
> >Above you mentioned that the server communicates which region to map. Can
> >you explain what that means?
> 
> The server sends a file descriptor to the VM over the socket, details
> can be found here:
> 
> http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem-spec.txt
> #l151

This one is harder. What we really want to know is the size information. But 
libvirtd doesn't have it I assume. That makes it sound like ivshmem should log 
it, but it probably doesn't know the reason, vm name, or uuid or anything 
else. So, this is probably not good.

I guess about all that you can say is that a ivshmem-socket is being assigned. 
I guess let's do it like this:

type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 
msg='virt=kvm resrc=ivshmem-socket reason=start vm="rhel7.3" uuid=a7708061-
faa0-42ce-897a-e92fb75fcf1d ivshmem="my_shmem2" exe="/usr/sbin/libvirtd" 
hostname=? addr=? terminal=? res=success'

-Steve

> >> So my question is, when starting a domain or hot-(un)plugging, what
> >> naming should we use for this kind of device and what are the things
> >> that we should describe about it?  Basically, how would you like the
> >> message to look?
> >
> >We need a record recording what is getting assigned to the VM. In the case
> >of the /dev/shm, you can record that as a path which must be escaped. In
> >the case of the server, I think we still need to understand what is
> >happening. Just recording a socket number or path is not terribly useful
> >in reconstructing the resources given to the VM.
> >
> >Audit events have to tell a story. There is a subect, object, action, and
> >results. It kind of needs to be a sentence. "libvirtd successfully assigned
> >____ to vm-name."
> >
> >-Steve
> >
> >> Thanks in advance for any info.
> >> 
> >> Have a nice day,
> >> Martin

Re: What fields should be used for reporting shared memory?

[Martin Kletzander]

[-- Attachment #1.1: Type: text/plain, Size: 4444 bytes --]

On Mon, Mar 20, 2017 at 06:21:53PM -0400, Steve Grubb wrote:
>On Monday, March 20, 2017 7:36:14 AM EDT Martin Kletzander wrote:
>> On Thu, Mar 16, 2017 at 09:04:52PM -0400, Steve Grubb wrote:
>> >Hello,
>> >
>> >I apologize for the delay.
>> >
>> >On Tuesday, March 14, 2017 7:42:27 AM EDT Martin Kletzander wrote:
>> >> I am going through the fields in the dictionary and I can't find any
>> >> name to use for the following scenario.
>> >>
>> >> We (libvirt) are running virtual machines and there's a thing nowadays,
>> >> that people like to use, called ivshmem (Inter-VM SHared MEMory).  From
>> >> host's point of view this is just a shared memory region accessed by
>> >> multiple VMs (and possibly to host as well).  The machine maps the
>> >> shared memory given a name (e.g. name "asdf" results in /dev/shm/asdf to
>> >> be mapped) *or* it can communicate with a server over UNIX socket and
>> >> that server handles interrupts and also tells the client which shared
>> >> memory region to map.
>> >
>> >If both of these result in a path, then I think we want to log it as a
>> >resource event.
>>
>> Yes, and they both are resources in its sense. So you are talking
>> particularly about the resrc= field?  Should that also have category and
>> class or anything else set?  Or do you mean we report the path in the
>> resrc= field?
>
>No, I mean we would want the path to the memory in a VIRT_RESOURCE event. :-)
>How about something like this:
>
>type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0
>auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023
>msg='virt=kvm resrc=shmem reason=start vm="rhel7.3" uuid=a7708061-
>faa0-42ce-897a-e92fb75fcf1d size=4194304 path="/dev/shm/my_shmem1" exe="/usr/
>sbin/libvirtd" hostname=? addr=? terminal=? res=success'
>
>Having the full path would make it more normal when reporting on files in use.
>
>
>> >> Talking about information we have; in server-less
>> >> setup it's the shared memory region that is shared, in the server
>> >> scenario it is the socket.  That's information we can output.
>> >
>> >Above you mentioned that the server communicates which region to map. Can
>> >you explain what that means?
>>
>> The server sends a file descriptor to the VM over the socket, details
>> can be found here:
>>
>> http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem-spec.txt
>> #l151
>
>This one is harder. What we really want to know is the size information. But
>libvirtd doesn't have it I assume. That makes it sound like ivshmem should log
>it, but it probably doesn't know the reason, vm name, or uuid or anything
>else. So, this is probably not good.
>
>I guess about all that you can say is that a ivshmem-socket is being assigned.
>I guess let's do it like this:
>
>type=VIRT_RESOURCE msg=audit(1488441043.591:2977): pid=25464 uid=0
>auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023
>msg='virt=kvm resrc=ivshmem-socket reason=start vm="rhel7.3" uuid=a7708061-
>faa0-42ce-897a-e92fb75fcf1d ivshmem="my_shmem2" exe="/usr/sbin/libvirtd"
>hostname=? addr=? terminal=? res=success'
>

Sorry for resurrecting this old thread.  I was under the impression that
I replied to you and no matter how much I look I can't find the reply.

I agree with everything with one exception.  I would change the
ivshmem="my_shmem2" to path="/path/to/ivshmem.socket".  That will also
clearly show what VMs share the shm objects.

If that's OK with you, I can propose the patch for libvirt in a little while.

>-Steve
>
>> >> So my question is, when starting a domain or hot-(un)plugging, what
>> >> naming should we use for this kind of device and what are the things
>> >> that we should describe about it?  Basically, how would you like the
>> >> message to look?
>> >
>> >We need a record recording what is getting assigned to the VM. In the case
>> >of the /dev/shm, you can record that as a path which must be escaped. In
>> >the case of the server, I think we still need to understand what is
>> >happening. Just recording a socket number or path is not terribly useful
>> >in reconstructing the resources given to the VM.
>> >
>> >Audit events have to tell a story. There is a subect, object, action, and
>> >results. It kind of needs to be a sentence. "libvirtd successfully assigned
>> >____ to vm-name."
>> >
>> >-Steve
>> >
>> >> Thanks in advance for any info.
>> >>
>> >> Have a nice day,
>> >> Martin
>
>

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]