[siemens/jailhouse] 68683f: x86: Add MSR whitelisting to to-do list

2 visualizações
Pular para a primeira mensagem não lida

GitHub

não lida,
18 de mar. de 2015, 11:37:1018/03/2015
para jailho...@googlegroups.com
Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: 68683f312a2707c0cd95a87c5e4785834935d892
https://github.com/siemens/jailhouse/commit/68683f312a2707c0cd95a87c5e4785834935d892
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)

Changed paths:
M TODO.md
M hypervisor/arch/x86/vmx.c

Log Message:
-----------
x86: Add MSR whitelisting to to-do list

We currently allow access to all MSRs except for APIC-related ones. This
has to be changed into a whitelist approach to avoid that the cell
manipulates a CPU state in a way we didn't validate as safe.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 63ed0e3bc18c22bf3db33062a3075638f88adaa5
https://github.com/siemens/jailhouse/commit/63ed0e3bc18c22bf3db33062a3075638f88adaa5
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-16 (Mon, 16 Mar 2015)

Changed paths:
M hypervisor/arch/x86/vcpu.c

Log Message:
-----------
x86: Fix comment wording

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: d402606264776b0cb0f7ca29373d88f8e1009512
https://github.com/siemens/jailhouse/commit/d402606264776b0cb0f7ca29373d88f8e1009512
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)

Changed paths:
M hypervisor/arch/x86/svm.c

Log Message:
-----------
x86: Drop redundant stgi from SVM's vcpu_deactivate_vmm

Already done via arch_cpu_restore -> vcpu_exit.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: bf25925811c28f62a38032e949e5ec401045aaf6
https://github.com/siemens/jailhouse/commit/bf25925811c28f62a38032e949e5ec401045aaf6
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-17 (Tue, 17 Mar 2015)

Changed paths:
M hypervisor/arch/x86/include/asm/processor.h

Log Message:
-----------
x86: Reformat and extend CR0 constants

Encode CR0 constants in an easier readable form and add some bits we
will need soon. Also add a mask of the reserved bits that need to be
left as-is on modifications.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: d108d08cb6095082560055a97f8ebdd421d6ab60
https://github.com/siemens/jailhouse/commit/d108d08cb6095082560055a97f8ebdd421d6ab60
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/arch/x86/vmx.c

Log Message:
-----------
x86: Rework CR0/CR4 restriction handling for VMX

First of all, we want to reuse the restrictions also for setting the
host CRx values. And then the current implementation would benefit from
more documentation, caching of those static values and checking their
consistency across all CPUs.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 89e32d3de59c4a7ad5ad13ff74cbe87f3948b441
https://github.com/siemens/jailhouse/commit/89e32d3de59c4a7ad5ad13ff74cbe87f3948b441
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/arch/x86/include/asm/percpu.h
M hypervisor/arch/x86/include/asm/vcpu.h
M hypervisor/arch/x86/setup.c
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vmx.c

Log Message:
-----------
x86: Bring host CR0 into well-defined state during setup

Avoid any uncertainty about the state of CR0 left behind by Linux: leave
the architecturally reserved bits intact, respect the requirement VMX
has on CR0 bits and otherwise set our own state.

The resulting CPU-specific state will once be validated via a
to-be-defined platform hash.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 6cf474c26b97a1346b79e21d993d9b97566286e2
https://github.com/siemens/jailhouse/commit/6cf474c26b97a1346b79e21d993d9b97566286e2
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/arch/x86/include/asm/processor.h

Log Message:
-----------
x86: Reformat and cleanup CR4 constants

Encode CR0 constants in an easier readable form and remove unused PGE.
Also add a mask of the reserved bits that need to be left as-is on
modifications.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: d7ee075c88c01b5ee66e4d787aa980365d904214
https://github.com/siemens/jailhouse/commit/d7ee075c88c01b5ee66e4d787aa980365d904214
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/arch/x86/include/asm/percpu.h
M hypervisor/arch/x86/include/asm/vcpu.h
M hypervisor/arch/x86/setup.c
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vmx.c

Log Message:
-----------
x86: Bring host CR4 into well-defined state during setup

Analogously to CR0: Avoid any uncertainty about the state of CR4 left
behind by Linux: leave the architecturally reserved bits intact, respect
the requirement VMX has on CR4 bits and otherwise set our own state.

The resulting CPU-specific state will once be validated via a
to-be-defined platform hash.

A side effect of this change is the VMX's vcpu_exit will no longer clear
VMXE in CR4 but only in the cached Linux state that arch_cpu_restore
will write back.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 66be9980221867e245547b939026c9a5cf674327
https://github.com/siemens/jailhouse/commit/66be9980221867e245547b939026c9a5cf674327
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/include/jailhouse/printk.h

Log Message:
-----------
core: Introduce error return code tracing

A number of errors that can be reported during setup or while
reconfiguring cells are hard to trace down to their detailed reasons
because of the limited number of error codes available through POSIX.
This Introduces a non-invasive mechanism to instrument error return
paths in the hypervisor and report the origin of a specific error code
in the form

hypervisor/arch/x86/vmx.c:592: returning error -ENODEV

This can then be matched against the source code to find out which check
on the hardware, the system state or the configuration data failed
precisely.

The feature is off by default, requiring CONFIG_TRACE_ERROR to be set in
config.h.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 643ea82ff936464d372b5d64c2d339725c55f41f
https://github.com/siemens/jailhouse/commit/643ea82ff936464d372b5d64c2d339725c55f41f
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/control.c
M hypervisor/paging.c
M hypervisor/pci.c
M hypervisor/pci_ivshmem.c

Log Message:
-----------
core: Instrument relevant return paths for error tracing

This instruments return paths so that the origin of important errors can
be tracked down. Two so far explicit error outputs are replaced with
trace_error.

We do not instrument -ENOMEM cases unless they relate to allocations
from the remapping pool. All other -ENOMEM cases boil down to a too
small hypervisor region.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: 4e8c61ca0672e8ba1fe989233e8a7bde23ce5311
https://github.com/siemens/jailhouse/commit/4e8c61ca0672e8ba1fe989233e8a7bde23ce5311
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/arch/x86/apic.c
M hypervisor/arch/x86/ioapic.c
M hypervisor/arch/x86/svm.c
M hypervisor/arch/x86/vcpu.c
M hypervisor/arch/x86/vmx.c
M hypervisor/arch/x86/vtd.c

Log Message:
-----------
x86: Instrument relevant return paths for error tracing

Add trace_error to return paths so that the origin of important errors
can be tracked down.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Commit: e08b627d66cca998235a64d0bd72f5541ec28259
https://github.com/siemens/jailhouse/commit/e08b627d66cca998235a64d0bd72f5541ec28259
Author: Jan Kiszka <jan.k...@siemens.com>
Date: 2015-03-18 (Wed, 18 Mar 2015)

Changed paths:
M hypervisor/paging.c

Log Message:
-----------
core: Simplify error reporting of paging_init

If -ENOMEM shows up at the user, this always means we ran out of pages.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>


Compare: https://github.com/siemens/jailhouse/compare/9911f107f42c...e08b627d66cc
Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem