linux-kernel - Re: [PATCH 00/10] x86: Add support for running as secondary Jailhouse guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4fd4a154-4f84-9ee4-a96f-23a84e7bc75c@siemens.com>
Date:   Mon, 20 Nov 2017 08:00:20 +0100
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>
Cc:     x86@...nel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        jailhouse-dev@...glegroups.com
Subject: Re: [PATCH 00/10] x86: Add support for running as secondary Jailhouse
 guest

On 2017-11-18 22:15, H. Peter Anvin wrote:
> On 11/15/17 23:26, Jan Kiszka wrote:
>> This series paves the way to run Linux in so-called non-root cells
>> (guest partitions) of the Jailhouse hypervisor.
>>
>> Jailhouse [1] was started 4 years ago as an open-source (GPL) leight-
>> weight hypervisor that statically partitions SMP systems. It's unique in
>> that it uses one Linux instance, the root cell, as boot loader and
>> management console. Jailhouse targets use cases for hard real-time and
>> safety-critical systems that KVM cannot cater due to its inherent
>> complexity.
>>
>> Jaihouse can run bare-metal, free and closed-source RTOSes as secondary
>> guests and, with this series, also x86 Linux instances. While ARM and
>> ARM64 non-root Linux guests are feasible without extra patches, thanks
>> to the high configurability via device trees, x86 requires special
>> platform support, mostly to step away from non-existing resources in a
>> non-root Jailhouse cell.
>>
> 
> Could you please write a single summary about the virtualization holes
> in Jailhouse that you are papering over?

Actually, we are not virtualizing any full device in Jailhouse. That is
an architectural decision that allows to keep the critical code base
very small (9200 LOC on Intel right now). So, anything that is not there
multiple times is not exposed or problematic state modifications are
blocked.

That leaves the non-root cells with:
- local CPU resources (processor, LAPIC etc.)
- exclusive memory regions
- exclusive PCI devices (or functions)
- read access to the PM timer (as clocksource)
- exclusively assigned pins on the IOAPIC (if any - it's not
  recommended to partition it)
- virtual shared memory devices for inter-cell communication

Thus, the list of non-existing x86 resources and features:
- LPC with all its legacy devices like PIT, PIC, RTC, SMBus etc.
  (unless you decide to pass one through exclusively)
- HPET
- normal PCI bus topology
- BIOS / UEFI firmware services, including ACPI enumeration (that lacks
  means to describe absence of PC platform devices anyway)
- mass storage or network virtualization - sharing such devices is not
  in the scope of the hypervisor
- no restart interface

Deviations and restrictions:
- CPU start address is configurable, typically set to 0 - but that's
  handled by the boot loader (comes with Jailhouse)
- LAPIC can only be operated in flat mode, and the content of LDR is
  frozen

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux