* 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?
>
> 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.
--
Gustavo Lima Chaves
Intel - Open Source Technology Center
--
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.
