[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xenconsoled CPU denial of service problem
On 29/8/06 4:59 pm, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > Ah, that's very handy. Looking at the xenconsoled code I think I've worked > out how to slow things down - although I'm not entirely sure I'm correctly > activating the throttling - basically I'm delaying the calls to the methods > xc_evtchn_notify & xc_evtchn_unmask after consuming data - is this the > correct approach ? Yes, the essence of your approach is exactly right. Delaying the unmask is the critical thing -- there's not really any need to delay the notification (in fact I don't think you should bother). But by delaying the unmask you avoid any possibility of a DoS attack on that interdomain link -- without this the domU could potentially hose the dom0 with lots of pointless event-channel notifications. This is theoretically a problem on every one of our split drivers (xenstore, blk, net) so it'd be good to think of the most general possible solution we can think of here that we can apply to every backend. > The patch sets > - data size 5 kb > - period 200 ms > - delay 200 ms A few comments: * I think the 'delay' parameter is not really useful. Think of this simply as a simple credit-based scheduler that replenishes credit every 'period'. So in this case you get 5kB every 200ms. If the domU offers more data in a period, it must wait until its credit is replenished at the end of the current 200ms period. * I'm not sure bytes of data is the right thing to limit here. The main thing that hoses domain0 is the repeated rescheduling of the console daemon, and that is fundamentally caused by event-channel notifications. So it might make sense to rate limit the number of times we read the event-channel port from xc_evtchn_pending -- e.g., no more than 10 times a second (should be plenty). This has a few advantages: 1. Looking just at data transferred doesn't stop a malicious domain from hosing you with no-op event-channel notifications; 2. This is a fundamental metric that can be measured and rate-limited on all backend interfaces, so perhaps we can come up with some common library of code that we apply to all backends/daemons. It may turn out we need to rate limit on data *as well*, if it turns out that sinking many kilobytes of data a second is prohibitively expensive, but I doubt this will happen. For a start, the strict limiting of notifications will encourage data to get queued up and improve batching of console data, and batches of data should be processed quite efficiently. This same argument extends to other backends (e.g., batching of requests in xenstored, netback, blkback, etc). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |