Xen devel - Sep 2004 - possible packet sniffer between domains?

I notice on some of my rx pages that there is more than one packet in the 
page ... this is the case where the packet is at (e.g.) offset 0x5e, and 
if I look at the page, there is a remnant of an IP packet at a lower 
offset. This remnant was a much larger packet, so only the first 32 bytes 
or so is there, but it is indeed there. 

In other words, bits of old packets are appearing in the pages along with 
the new packet. 

More interesting, the packets are ones that seem like they weren''t 
destined for my domain. 

Is it possible, in a multiple-domain situation, for DOM N+1 to see bits of 
packets for DOM N? Just wondering. 

I''m now feeding rx DHCP packets to Plan 9, it just doesn''t
like them for
some reason :-)

ron


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> In other words, bits of old packets are appearing in the pages along with 
> the new packet. 
> 
> More interesting, the packets are ones that seem like they weren''t
> destined for my domain. 
> 
> Is it possible, in a multiple-domain situation, for DOM N+1 to see bits of 
> packets for DOM N? Just wondering. 
Xen doesn''t scrub the pages that a domain gives up when it decreases
its memory reservation. Frontend drivers are continually decreasing
their memory reservation (because it gets increased again when they
receive packets) -- so automatic scrubbing of whole pages would slay
performance.

This might be a security problem for some people -- currently the
pages that are returned to Xen could have previously be used for any
purpose (e.g., they could be pages containg contents of arbitrary
files, or arbitrary VM pages from any running application).

A simple way to improve security would be for the frontend driver to
allocate ''rx buffers'' out of a dedicated slab cache. The
constructor
for the cache would zero out pages when they enter the cache. This
would improve security because the /only/ thing that you may end up
giving back to Xen without scrubbing is the contents of network
packets. In most cases you will assume that network packets don''t
contain unencrypted secrets since your network could be sniffed
anyway.

Further tricks would be needed if you care about not leaking
network-packet contents to other domains. For example, I think
in-kernel IPsec will attempt to decrypt packets ''in situ''.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> 
> This might be a security problem for some people -- currently the
> pages that are returned to Xen could have previously be used for any
> purpose (e.g., they could be pages containg contents of arbitrary
> files, or arbitrary VM pages from any running application).
yowza. Yes, this could be a security issue for some people :-)

The pages Plan 9 returns are going to get zero''ed. It might be a good
idea
to have a build option for domU (or even dom0) Linux/freebsd/etc. that
pages returned to Zen always get zero''d. 

ron


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> > This might be a security problem for some people -- currently the
> > pages that are returned to Xen could have previously be used for any
> > purpose (e.g., they could be pages containg contents of arbitrary
> > files, or arbitrary VM pages from any running application).
> 
> yowza. Yes, this could be a security issue for some people :-)
> 
> The pages Plan 9 returns are going to get zero''ed. It might be a
good idea
> to have a build option for domU (or even dom0) Linux/freebsd/etc. that
> pages returned to Zen always get zero''d. 
If you naively scub memory every time you allocate a network page,
your network performance will undoubtedly be affected.

I''ve checked in code for Linux that scrubs memory before freeing it to
Xen. Furthermore, after a guest has died, Xen will scrub its memory as
it becomes free. The exceptions to this scrubbing are:

 1. It can be entirely disabled via a config option under the
''XEN''
    menu in the Linux build configurator.

 2. Network-receive memory is allocated out of a dedicated slab-cache
    allocator. I only scrub memory when it enters the slab cache --
    this means that a guest may leak partial contents of
    previously-received network packets, but NOT arbitrary
    VM/buffer-cache pages. This is perfectly adequate if
    security-sensitive connections are end-to-end secured, as they
    should be.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel