Il 27/04/2013 22:57, Blue Swirl ha scritto: >> The questions are, in order of importance: >> >> (1) what privileges would this require in the guest? Answer: a lot. >> >> (2) is this likely to happen by chance? Answer: no, not at all. >> >> (3) is there a workaround? Answer: yes, disable in-kernel irqchip. > > These questions ask if there is a risk of benevolent guests performing > these activities and I agree that the chances are close to zero. > > But the interesting question is to ask if a malevolent guest can bring > down a VM uncontrollably this way and I think it only needs a few > elevated privileges in a guest to do this.
If you have them, isn't it simpler to just turn off the VM (using APM or ACPI)? Also, killing your guest is not a very interesting thing to do once you've gotten elevated privileges. ;) >> Simply setting IO_APIC_DEFAULT_ADDRESS is also flawed in my opinion. >> I'm not sure the in-kernel irqchip handles correctly an overlap between >> the IOAPIC and LAPIC regions, maybe an abort is predictable after all. > > At least the guest needs to be stopped. Perhaps we should have a > common function which does this and logs the guest error so we can > start replacing calls to abort() with it. Yes, that's a good idea. We can reuse the internal error runstate for that. Paolo
