In the DRAKVUF system that's exactly what I do, I mark the page execute only so that the guest is unable to locate/overwrite injected breakpoints without notice. If it were to overwrite injected breakpoints with its own, then we would be able to tell that the trap is both for external and internal use. So there isn't much of an issue there. The main issue is with the racecondition in multi-vCPU guests when the purely external-use breakpoint has to be removed to allow the guest to continue. It can be solved nicely though with altp2m. I did a write-up for the Xen blog about it a couple months ago and sent it to publicity but has not appeared yet. Lars?
Tamas,
it hasn't because I was under the impression that Razvan and you disagreed on some aspects of the article. And then I forgot to chase either of you. I am happy with the article: feel free to upload it to the blog (or let me know, if I should) and press the button. Apologies
I think there are a couple of minor knit-picks, such as replace "In the latest release of Xen last summer several new features have been introduced" In "Xen 4.6 several new features have been introduced" ... assuming 4.6 is correct
I will reply to publicity
Regards Lars
|
