Hi, A while ago there was a quick chat on IRC about how XSM interacts with the idle domain. The conversation did not reach any clear conclusions so it might be a good idea to summarise the questions in an email.
Basically there were two questions in that conversation: 1. In its current state, are security modules able to limit what the idle domain can do? 2. Should security modules be able to restrict the idle domain? The first question came up during ongoing work in LiveUpdate. After an LU, the next Xen needs to restore all domains. To do that, some hypercalls need to be issued from the idle domain context and apparently XSM does not like it. We need to introduce hacks in the dummy module to leave the idle domain alone. Our work is not compiled with CONFIG_XSM at all, but with CONFIG_XSM, are we able to enforce security policies against the idle domain? Of course, without any LU work this does not make any difference because the idle domain does not do any useful work to be restricted anyway. Also, should idle domain be restricted? IMO the idle domain is Xen itself which mostly bootstraps the system and performs limited work when switched to, and is not something a user (either dom0 or domU) directly interacts with. I doubt XSM was designed to include the idle domain (although there is an ID allocated for it in the code), so I would say just exclude idle in all security policy checks. I may have missed some points in that discussion, so please feel free to add. Hongyan
