I was examining what would happen if I ballooned a guest down to 15 MB
in size, and besides the obvious (kernel kills everything in sight :-), I
found a non-trivial CPU denial of service problem with xenconsoled.
When I ballooned the guest down the DomU kernel went mental printing out
Out of Memory: Kill process 2 (migration/0) score 0 and children.
Out of Memory: Kill process 2 (migration/0) score 0 and children.
Out of Memory: Kill process 2 (migration/0) score 0 and children.
Out of Memory: Kill process 2 (migration/0) score 0 and children.
.....
over & over again, as fast as it could - using 100% of CPU time allocated
to that DomU by the schedular. This isn't a problem in itself because with
sensible schedular settings the impact on other DomU's would be minimal.
The problem is that at the same time, xenconsoled consumes 100% of the CPU
time available to Domain-0 trying to read the console data generated by the
DomU OS. It is processing the console data from DomU, even though there are
no (xm console) client sessions with the slave end of the Psuedo-TTY open.
Now the particular ballooning scenario I used falls under the "don't do that
then" category, but more generally this is still a problem. Any DomU OS can
inflict a CPU denial of service attack on Domain-0 (and thus other Dom-U)
simply by generating a huge quantity of data on its (serial) console - either
accidentally, or maliciously
I've been looking at the the xenconsoled source to see if there's any way
this can be resolved. With no xm console clients attached, the xenconsoled
is spinning
select(10, [5 6 7 8 9], [6], NULL, NULL) = 1 (in [5])
read(5, "\24\0\0\0", 4) = 4
mremap(0x2aaaaaac0000, 1052672, 1052672, MREMAP_MAYMOVE) = 0x2aaaaaac0000
ioctl(5, EVIOCGKEYCODE, 0x7fffc89a1f50) = 0
mremap(0x2aaaaaac0000, 1052672, 1052672, MREMAP_MAYMOVE) = 0x2aaaaaac0000
write(5, "\24\0\0\0", 4) = 4
Which corresponds to handle_ring_read() in tools/console/daemon/io.c What
I'd like to do is figure out a way to avoid processing the ring buffer if
there are is no client connected to the /dev/pts/NNN slave tty associated
with the domain. I tried to detect presence of a client by adding the master
TTY filehandle to the writefds set in select(), but it appears the master
end of a tty is signalled writable even if the other end is disconnected.
Does anyone know of any alternative approach to detecting whether the fd
for the master end of a psuedo-TTY, has a its end slave open / active ?
Without being able to detect this I don't see any good way to avoid the DOS
attack in the general case - only other option would be to start dropping
data once > a certain rate, but this isn't really very desirable because
there are (debug) scenarios in which you really do want the ability to
capture all data.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home