Hi all,
I created a proof of concept to communicate between guests (inside
dom0 or domU) in a Xen environment. You need to have kernel rights
(hypercalls are needed).
It use the machine-to-physical table to store informations. This table
is readable for all guests and writable for the part''s guest. The
principle is simple: write a tag and your data instead of addresses.
Other guests can read what you wrote and extract data. An half-duplex
channel can be created to share information between OS (Linux 2.6
x86-32 for now).
This PoC is not a new idea[1] but a practical issue. This one bypass
the Xen Policy checks as knew by developers[2].
The machine-to-physical table is really good for the performance
mapping but it would be a good idea to have one table for each guest
and protect it. I think it is not a big problem, it can be fast
(memory size and switch time). Another solution is to use a full
shadow page tables, but with a lower speed if it is a software
translation. If it is done like this, my PoC will be unusable. It will
also be good to prevent other guests to read the table and infer (with
Xen interrupts) a (basic) map of the physically mapped memory.
The code is a device driver who create /dev/xencc. The communication
protocol is based on tags. You need a different tag for each guest
(look at the source and change it for the second guest). For now, you
can only communicate between two guests. If you have not udev install
on your system, the device will not be created when you insert the
specific module[3]. In this case you need to create it by hand[4].
You can write[5] and read[6]. If you are risky you can change the
limit buffer size in the source. The channel bandwidth seams to be
good because it use an hypercall (mmu_update) to copy an entire range
of data at the same time. The drawback of this method is the consuming
memory. We are allocating addresses instead of 4 bytes (in x86-32
architecture), so we need to transmit data step-by-step. With a good
scheduling you can have a quick channel.
This is an unstable version, use it with caution!
Best regards,
Mickaël Salaün
1.
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xense-devel&i=003501c63303%245209cbd0%241c02000a%40Myong1
2.
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xen-devel&i=39CC97884CA19A4D8D6296FE94357BCB019EB0B2%40swsmsx404
3. insmod xencc.ko
4. mknod /dev/xencc c `grep misc /proc/devices | awk ''{print
$1}''`
`grep xencc /proc/misc | awk ''{print $1}''`
5. echo your msg > /dev/xencc
6. dd if=/dev/xencc count=1
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel
Hi all,
I created a proof of concept to communicate between guests (inside
dom0 or domU) in a Xen environment. You need to have kernel rights
(hypercalls are needed).
It use the machine-to-physical table to store informations. This table
is readable for all guests and writable for the part''s guest. The
principle is simple: write a tag and your data instead of addresses.
Other guests can read what you wrote and extract data. An half-duplex
channel can be created to share information between OS (Linux 2.6
x86-32 for now).
This PoC is not a new idea[1] but a practical issue. This one bypass
the Xen Policy checks as knew by developers[2].
The machine-to-physical table is really good for the performance
mapping but it would be a good idea to have one table for each guest
and protect it. I think it is not a big problem, it can be fast
(memory size and switch time). Another solution is to use a full
shadow page tables, but with a lower speed if it is a software
translation. If it is done like this, my PoC will be unusable. It will
also be good to prevent other guests to read the table and infer (with
Xen interrupts) a (basic) map of the physically mapped memory.
The code is a device driver who create /dev/xencc. The communication
protocol is based on tags. You need a different tag for each guest
(look at the source and change it for the second guest). For now, you
can only communicate between two guests. If you have not udev install
on your system, the device will not be created when you insert the
specific module[3]. In this case you need to create it by hand[4].
You can write[5] and read[6]. If you are risky you can change the
limit buffer size in the source. The channel bandwidth seams to be
good because it use an hypercall (mmu_update) to copy an entire range
of data at the same time. The drawback of this method is the consuming
memory. We are allocating addresses instead of 4 bytes (in x86-32
architecture), so we need to transmit data step-by-step. With a good
scheduling you can have a quick channel.
This is an unstable version, use it with caution!
Best regards,
Mickaël Salaün
1.
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xense-devel&i=003501c63303%245209cbd0%241c02000a%40Myong1
2.
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xen-devel&i=39CC97884CA19A4D8D6296FE94357BCB019EB0B2%40swsmsx404
3. insmod xencc.ko
4. mknod /dev/xencc c `grep misc /proc/devices | awk ''{print
$1}''`
`grep xencc /proc/misc | awk ''{print $1}''`
5. echo your msg > /dev/xencc
6. dd if=/dev/xencc count=1
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel