On 2017-07-26 19:36, Gustavo Lima Chaves wrote: > * Jan Kiszka <[email protected]> [2017-07-26 07:28:06 +0200]: > >> On 2017-07-25 23:23, Gustavo Lima Chaves wrote: >>> * Jan Kiszka <[email protected]> [2017-07-25 08:11:32 +0200]: >>> >>> [...] >>> >>>>>> +// TODO: convert to whitelist >>>>>> static u8 __attribute__((aligned(PAGE_SIZE))) msr_bitmap[][0x2000/8] = { >>>>>> [ VMX_MSR_BMP_0000_READ ] = { >>>>>> [ 0/8 ... 0x7ff/8 ] = 0, >>>>>> -- >>>>>> 2.1.4 >>>>> >>>>> Just to get/align the rationale here on the MRS whitelist. The idea is to >>>>> expose the whitelist as root/inmate cell configs as well, just like the >>>>> PIO bitmap right now? If so, I wonder if having all accesses besides >>>>> those already treated denied and then working with a minimal set to have, >>>>> say, a bootable Linux inmate as a default config would be acceptable or >>>>> there is another idea... >>>>> >>>> >>>> The idea is to first of all try to define a static whitelist of MSRs >>>> that are safe to be handed out to the guest because they do not affect >>>> the integrity of the hypervisor on that same logical CPU, nor do they >>>> have cross-cell effects. If working out that list requires per-board >>>> configurations (maybe not unlikely), we may need to extend the config >>>> format as well. >>> >>> Thanks! What about MSRs that are the key/point-of-access for other >>> features, like power management (changing P/C-states on x86)? So is it >>> that the power management TODO entry is totally encompassed by the MSR >>> one or am I missing something? >> >> MSRs are one way to manage power on x86. mwait is another. This area >> requires a careful analysis and waits with some nasty dependencies on us >> (plus horrible ACPI complexity). So, MSRs access control will play a >> role for it but will solve it alone. > > Thanks again. I'm still wondering where is the desired direction here: > either to allow/disallow cells to reach knobs controlling > performance/sleep states or to control those at Jailhouse level. Also,
The general direction is always: allow what has no side-effects, deny or otherwise control what can do harm to other cells or the hypervisor itself. > can we skip ACPI altogether where we can (think intel_idle driver "The > intel_idle driver knows the sleep state capabilities of the processor > and ignores ACPI BIOS exported processor sleep states tables.")? I didn't look into any details here. I was just told that there are systems where the firmware comes with (OS-interpreted) ACPI code that switches power levels and where this needs to be done in order to avoid overheating. From hypervisor POV, we will need to understand and interpret the MSR or what-so-ever accesses in order to decide if an access is allowed or not. Power management access control is still a bit frightening to me, mostly because to the strong SoC / CPU model dependencies and the variations out there. Any first steps to make the issue more graspable, at least for one arch and vendor, would be welcome! Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
