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. 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.
