Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

[Xen.org security team <security@xen.org>]

[-- Attachment #1: Type: text/plain, Size: 9157 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
                                 version 9

        Information leak via side effects of speculative execution

UPDATES IN VERSION 9
====================

"Stage 1" pagetable isolation (PTI) Meltdown fixes for Xen are
available.

"Comet" updates to shim code (4.10 branch):
 * Include >32vcpu workaround in shim branch so that all shim
   guests can boot without hypervisor changes.
 * Fix shim build on systems whose find(1) lacks -printf
 * Place shim trampoline at page 0x1 to avoid having 0 mapped
(4.8 "Comet" users are using the 4.10 shim and may want to update.)

ISSUE DESCRIPTION
=================

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks.  This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor.  Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead.  Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks.  On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/
  https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.)  However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.

IMPACT
======

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes.  For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware.  Consult your
operating system provider for more information.

NOTE ON TIMING
==============

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable.  Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer.  ARM
has information on affected models on the following website:
   https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable.  (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen.  PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by page-table isolation ("PTI").
See Resolution below.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode.  This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10 and Xen 4.8.   Please read
README.which-shim to determine which shim is suitable for you.


$ sha256sum xsa254*/*
1cba14ff83844d001d6c8a74afc3f764f49182cc7a06bb4463548450ac96cc2f  xsa254/README.comet
cddd78cd7a00df9fa254156993f0309cea825d600f5ad8b36243148cf686bc9b  xsa254/README.pti
3ef42381879befc84aa78b67d3a9b7b0cd862a2ffa445810466e90be6c6a5e86  xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849  xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8  xsa254/pvshim-converter.pl
$

RESOLUTION
==========

These are hardware bugs, so technically speaking they cannot be
properly fixed in software.  However, it is possible in many cases to
provide patches to software to work around the problems.


There is no available resolution for SP1.  A solution may be available
in the future.

We are working on patches which mitigate SP2 but these are not
currently available.  Given that the vulnerabilities are now public,
these will be developed and published in public, initially via
xen-devel.


SP3 can be mitigated by page-table isolation ("PTI").

We have a "stage 1" implementation.  It allows 64-bit PV guests to be
run natively while restricting what can be accessed via SP3 to the Xen
stack of the current pcpu (which may contain remnants of information
from other guests, but should be much more difficult to attack
reliably).

Unfortunately these "stage 1" patches incur a non-negligible
performance overhead; about equivalent to the "PV shim" approaches
above.  Moving to plain HVM or PVH guests is recommended where
possible.  For more information on that, see below.

Patches for the "stage-1" PTI implementation are available in the Xen
staging-NN branches for each Xen revision.  See README.pti for
specific revisons.


NOTE ON LACK OF EMBARGO
=======================

The timetable and process were set by the discloser.

After the intensive initial response period for these vulnerabilities
is over, we will prepare and publish a full timeline, as we have done
in a handful of other cases of significant public interest where we
saw opportunities for process improvement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJaX4QSAAoJEIP+FMlX6CvZubQH/iuxfjnW24mzMX+hVughCH5Q
PKoZiNDnKMoWCzztrRjMNNcXRFcLAo+IU/+jWdjytJr5ISvNtICPtU6mzRTduqRe
KwfvOxrX8bfkoxJWdM7g4ux6sGTNKGS27+HaJYHNBypPexmwQwb/GBJnp+Yj+TRJ
0p+OGvN/F+gVBrOm17rD2/NE2jwDLa3WAX/oS12WaTJtwvnnFjTKmNAKj4XU3FRs
PMZdmE6Iimix5rA6YlYLmmsVrS+kD9B7SSU2CRX0wqOQcFpLn1ZM1QXQ7ux7p9+I
bAE7EMrA28ZJ+TS8H+1AYYL8e8xvo2/KIXPjEKsEAEr1nXIEOciSuVjHByvTGbQ=
=2SAx
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa254/README.comet --]
[-- Type: application/octet-stream, Size: 2896 bytes --]

			    PV-in-PVH shim
                            ==============

Summary
-------

This README describes one of three mitigation strategies for Meltdown.

The basic principle is to run PV guests (which can read all of host
memory due to the hardware bugs) as PVH guests (which cannot, at least
not due to Meltdown).  The PV environment is still provided to the
guest by an embedded copy of Xen, the "shim".  This version of the
shim is codenamed "Comet".

Unlike Vixen, Comet requires modifications to the toolstack and host
hypervisor.

Note that both of these shim-based approaches prevent attacks on the
host, but leave the guest vulnerable to Meltdown attacks by its own
unprivileged processes; this is true even if the guest OS has KPTI or
similar Meltdown mitigation.

Versions for Xen 4.8 and 4.10 are available.

What you will need
------------------

 * You will need the xen.git with the following tags:
  - For 4.10: 4.10.0-shim-comet-3
  - For 4.8:  4.8.3pre-shim-comet-2   and  4.10.0-shim-comet-3

Build instructions: 4.10
------------------------

1. Build a 4.10+ system
    git clone git://xenbits.xenproject.org/xen.git xen.git
    cd xen.git
    git checkout 4.10.0-shim-comet-3

Do a build and install as normal.  The shim will be built as part of the
normal build process, and placed with other 'system' binaries where the
toostack knows how to find it.

Build instructions: 4.8
-----------------------

The code for shim itself is not backported to 4.8.  4.8 users should
use a shim built from 4.10-based source code; this can be simply
dropped into a Xen 4.8 installation.

1. Build a 4.8+ system with support for running PVH, and for pvshim:

    git clone git://xenbits.xenproject.org/xen.git xen.git
    cd xen.git
    git checkout 4.8.3pre-shim-comet-2

  Do a build and install as normal.

2. Build a 4.10+ system to be the shim:

    git clone git://xenbits.xenproject.org/xen.git xen.git
    cd xen.git
    git checkout 4.10.0-shim-comet-3
    ./configure
    make -C tools/firmware/xen-dir

  And then install the shim executable where
  the 4.8 pv shim mode tools expect to find it

    cp tools/firmware/xen-dir/xen-shim /usr/lib/xen/boot/xen-shim
    cp tools/firmware/xen-dir/xen-shim /usr/local/lib/xen/boot/xen-shim

  This step is only needed to boot guests in "PVH with PV shim"
  mode; it is not needed when booting PVH-supporting guests as PVH.


Usage instructions
------------------

* Converting a PV config to a PVH shim config

- Remove any reference to 'builder' (e.g., `builder="generic"`)
- Add the following two lines:
  type="pvh"
  pvshim=1

* Converting a PV config to a PVH config

If you have a kernel capable of booting PVH, then PVH mode is both
faster and more secure than PV or PVH-shim mode.

- Remove any reference to 'builder' (e.g., `builder="generic"`)
- Add the following line:
  type="pvh"

* There is no need to reboot the host.

[-- Attachment #3: xsa254/README.pti --]
[-- Type: application/octet-stream, Size: 2280 bytes --]

                      Xen page-table isolation (XPTI)
                      ===============================

Summary
-------

This README gives references for one of three mitigation strategies
for Meltdown.

This series is a first-class migitation pagetable isolation series for
Xen.  It is available for Xen 4.6 to Xen 4.10 and later.

Precise git commits are as follows:

4.10:

7cccd6f748ec724cf9408cec6b3ec8e54a8a2c1f x86: allow Meltdown band-aid to be disabled
234f481337ea1a93db968d614649a6bdfdc8418a x86: Meltdown band-aid against malicious 64-bit PV guests
57dc197cf0d36c56ba1d9d32c6a1454bb52605bb x86/mm: Always set _PAGE_ACCESSED on L4e updates
910dd005da20f27f3415b7eccdf436874989506b x86/entry: Remove support for partial cpu_user_regs frames

4.9:

dc7d46580d9c633a59be1c3776f79c01dd0cb98b x86: allow Meltdown band-aid to be disabled
1e0974638d65d9b8acf9ac7511d747188f38bcc3 x86: Meltdown band-aid against malicious 64-bit PV guests
87ea7816247090e8e5bc5653b16c412943a058b5 x86/mm: Always set _PAGE_ACCESSED on L4e updates
2213ffe1a2d82c3c9c4a154ea6ee252395aa8693 x86/entry: Remove support for partial cpu_user_regs frames

4.8:

31d38d633a306b2b06767b5a5f5a8a00269f3c92 x86: allow Meltdown band-aid to be disabled
1ba477bde737bf9b28cc455bef1e9a6bc76d66fc x86: Meltdown band-aid against malicious 64-bit PV guests
049e2f45bfa488967494466ec6506c3ecae5fe0e x86/mm: Always set _PAGE_ACCESSED on L4e updates
a7cf0a3b818377a8a49baed3606bfa2f214cd645 x86/entry: Remove support for partial cpu_user_regs frames

4.7:

e19d0af4ee2ae9e42a85db639fd6848e72f5658b x86: allow Meltdown band-aid to be disabled
e19517a3355acaaa2ff83018bc41e7fd044161e5 x86: Meltdown band-aid against malicious 64-bit PV guests
9b76908e6e074d7efbeafe6bad066ecc5f3c3c43 x86/mm: Always set _PAGE_ACCESSED on L4e updates
0e6c6fc449000d97f9fa87ed1fbe23f0cf21406b x86/entry: Remove support for partial cpu_user_regs frames

4.6:

44ad7f6895da9861042d7a41e635d42d83cb2660 x86: allow Meltdown band-aid to be disabled
91dc902fdf41659c210329d6f6578f8132ee4770 x86: Meltdown band-aid against malicious 64-bit PV guests
a065841b3ae9f0ef49b9823cd205c79ee0c22b9c x86/mm: Always set _PAGE_ACCESSED on L4e updates
c6e9e6095669b3c63b92d21fddb326441c73712c x86/entry: Remove support for partial cpu_user_regs frames

[-- Attachment #4: xsa254/README.vixen --]
[-- Type: application/octet-stream, Size: 2738 bytes --]

                PV-in-HVM shim with "sidecar" ISO
                =================================

Summary
-------

This README describes one of three mitigation strategies for Meltdown.

The basic principle is to run PV guests (which can read all of host
memory due to the hardware bugs) as HVM guests (which cannot, at least
not due to Meltdown).  The PV environment is still provided to the
guest by an embedded copy of Xen, the "shim".  This version of the
shim is codenamed "Vixen".

In order to boot the shim with an unmodified toolstack, you also
provide a special disk containing the shim and the guest kernel (or
pvgrub); this is called the "sidecar".

Note that both of these shim-based approaches prevent attacks on the
host, but leave the guest vulnerable to Meltdown attacks by its own
unprivileged processes; this is true even if the guest OS has KPTI or
similar Meltdown mitigation.

What you will need
------------------

 * Your host must be able to run grub-mkrescue to generate a .iso
 * You will therefore need xorriso and mtools
 * You must be using xl and able to use an alternative your guest config

 * You will need the script "pvshim-converter.pl"
  - This relies on perl-json
 * You will need the xen.git tag 4.9.1-shim-vixen-1


Instructions
------------

1. On a suitable system (perhaps a different host)
    git clone git://xenbits.xenproject.org/xen.git xen.git
    cd xen.git
    git checkout 4.9.1-shim-vixen-1

If you need bi-directional console and don't mind a less-tested patch,
you can apply the patch found in this email:

    marc.info/?i=<1515604552-9205-1-git-send-email-srn@prgmr.com>

build a xen hypervisor binary as usual:

    make xen

If your default version of python is python 3, you may need to add the following:

    make PYTHON=python2 xen

This will build a file
    xen/xen.gz

2. Copy that file to your dom0.

Ideally someplace like /usr/lib/xen/boot/xen-vixen.gz

3. Copy the script pvshim-converter to your dom0 and make
   it executable:
      chmod +x pvshim-converter.pl

4. For each guest

  (i) if the guest is currently booted with pygrub you must first
   switch to direct kernel boot (by manually copying the kernel and
   initramfs out of the guest, and configuring the command line in the
   domain configuration file), or pvgrub.

  (ii) run
      ./pvshim-converter.pl --shim=/usr/lib/xen/boot/xen-vixen.gz /etc/xen/GUEST.cfg /etc/xen/GUEST.with-shim-cfg

  (iii) shut the guest down cleanly

  (iv) create the guest with the new config
      xl create /etc/xen/GUEST.with-shim-cfg

  (v) Check that it boots properly.  xl console should work.

  (vi) Make arrangements so that autostarting of the guest will use
     the new config file rather than the old one


[-- Attachment #5: xsa254/README.which-shim --]
[-- Type: application/octet-stream, Size: 4010 bytes --]

		   How to decide which shim to use
		   ===============================

A work-around to Meltdown (aka "SP3" or "Variant 3") on Intel
processors is to run guests in HVM or PVH mode.

Note this shim-based approach prevents attacks on the host, but leaves
the guest vulnerable to Meltdown attacks by its own unprivileged
processes; this is true even if the guest OS has KPTI or similar
Meltdown mitigation.

Some guests are difficult to convert to running in HVM or PVH mode,
either due to lack of partitioning / MBR, or due to kernel
compatibilities.  As an emergency backstop, there are two approaches,
which we've codenamed "Vixen" and "Comet".  Both involve running an
embedded copy of Xen (called a "shim") within the HVM or PVH guest to
provide the native PV interface.

Below describes the properties, and who might want to use each one.

NOTE: Both shims require host patches to boot on AMD hosts.  This
shouldn't be an issue, as SP3 does not affect systems running on AMD.

Vixen
-----

Vixen has the following properties:
 * Runs the shim in an HVM guest.
 * It requires no hypervisor or toolstack changes, nor does it require
   a host reboot.
 * It has been extensively tested in Amazon's deployment for versions
   of Xen going back to 3.4
 * Guest reboots are required
 * Guest configs must be fed through a converter program
 * The converter program spits out a small guest-specific .iso
   image (we call this a "sidecar") used for booting
 * Because the result is an HVM guest, this approach involves
   running qemu as a PC emulator (this is done automatically)
 * Some common features are not supported:
  - Ballooning
  - Migration
  - vcpu hotplug
  - bidirectional console support (console is write-only)
 * Direct-boot kernels and pvgrub (both pvgrub1 and pvgrub2) are
   supported by the conversion program.  'pygrub' is not supported.
 * xl and xm domain configs can be converted; libvirt domain
   configuration arrangements are not supported.
 * Guest userspace can read all of guest memory, within each guest,
   and a guest migitation for this is not possible.

You might consider this approach if:
- You want to deploy a fix immediately
- You can tolerate the loss of within-guest security
- You can't, or would like to avoid, updating to Xen 4.8 or newer
- You'd like to avoid patching and rebooting your host
- You are able to:
 - Run a script to modify each domain config
 - Afford an extra 80MiB per guest
 - Tolerate having an extra QEMU around
- You don't need migration, memory ballooning, vcpu hotplug,
  or a bi-directional console

To use this solution, see README.vixen.

Bi-directional console is available as an extra patch, but hasn't been
widely tested:

marc.info/?i=<1515604552-9205-1-git-send-email-srn@prgmr.com>

Comet
-----

Comet has the following properties:
 * Runs the shim in a PVH guest.
 * PVH mode is available in Xen 4.10, and will be backported to Xen
   4.9 and 4.8 but no farther
 * Requires host hypervisor and toolstack patches (and host reboot),
   even for Xen 4.10
 * Requires minimal guest config changes, and no "sidecar"
 * Bootloading is identical to native PV guests; direct-boot, pvgrub,
   and pygrub all work equally well
 * Because the result is a PVH guest, this approach involves no PC emulator.
 * The following features not available in Vixen are supported:
  - Memory ballooning
  - Guest migration
  - vcpu hotplug
  - bidirectional console support
 * Guest userspace can read all of guest memory, within each guest,
   and a guest migitation for this is not possible.

You might consider this approach if:
- You're on 4.8 or later already
- You can tolerate the loss of within-guest security
- You can patch and reboot your host
- You don't want an extra QEMU around
- You need migration, memory ballooning, or vcpu hotplug, or a
  bidirectional console
- You need pygrub
- You need to use libvirt

At the moment, Comet is available for 4.10.   We expect to have
backports to 4.8 and 4.8 available within a few working days.

[-- Attachment #6: xsa254/pvshim-converter.pl --]
[-- Type: application/octet-stream, Size: 6762 bytes --]

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --qemu PATH-TO-QEMU        filename of qemu-system-i386
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIM                overrides domain config file
#   --debug                    verbose, and leaves sidecar prep dir around
#
# What we do
#
#  read existing config file using python
#  determine kernel, ramdisk and cmdline
#  use them to produce sidecar and save it under domain name
#  mess with the things that need to be messed with
#  spit out new config file

use strict;

use Getopt::Long;
use JSON;
use IO::Handle;
use POSIX;
use Fcntl qw(:flock);

our $debug;

sub runcmd {
    print STDERR "+ @_\n" if $debug;
    $!=0; $?=0; system @_ and die "$_[0]: $! $?";
}

our $qemu;
our $shim;
our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';

GetOptions('qemu=s' => \$qemu,
           'sidecars-directory=s' => \$sidecars_dir,
           'shim=s' => \$shim,
           'debug' => \$debug)
    or die "pvshim-converter: bad options\n";

@ARGV==2 or die "pvshim-converter: need old and new config filenames";

our ($in,$out) = @ARGV;

our $indata;

if ($in ne '-') {
    open I, '<', "$in" or die "open input config file: $!\n";
} else {
    open I, '<&STDIN' or die $!;
}
{
    local $/;
    $indata = <I>;
}
I->error and die $!;
close I;

open P, "-|", qw(python2 -c), <<END, $indata or die $!;
import sys
import json
l = {}
exec sys.argv[1] in l
for k in l.keys():
	if k.startswith("_"):
		del l[k]
print json.dumps(l)
END

our $c;

{
    local $/;
    $_ = <P>;
    $!=0; $?=0; close P or die "$! $?";
    $c = decode_json $_;
}

die "no domain name ?" unless exists $c->{name};
die "bootloader not yet supported" if $c->{bootloader};
die "no kernel" unless $c->{kernel};

our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";

$shim ||= $c->{pvshim_path};
$shim ||= '/usr/local/lib/xen/boot/xen-shim';

our $shim_cmdline = $c->{pvshim_cmdline} || 'console=com1 com1=115200n1';
$shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};

our $kernel_cmdline = $c->{cmdline} || '';
$kernel_cmdline .= ' root='.$c->{root} if $c->{root};
$kernel_cmdline .= ' '.$c->{extra} if $c->{extra};

print "pvshim-converter: creating sidecar in $sidecar\n";

runcmd qw(mkdir -m700 -p --), $sidecars_dir;

open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
flock L, LOCK_EX or die "$sidecar.lock: lock: $!";

my $sd = "$sidecar.dir";

system qw(rm -rf --), $sd;
mkdir $sd, 0700;

runcmd qw(cp --), $shim, "$sd/shim";
runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};

my $grubcfg = <<END;
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

set timeout=0

menuentry 'Xen shim' {
	insmod gzio
	insmod xzio
        multiboot (cd)/shim placeholder $shim_cmdline
        module (cd)/kernel placeholder $kernel_cmdline
        module (cd)/ramdisk
}
END

runcmd qw(mkdir -p --), "$sd/boot/grub";
open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
print G $grubcfg or die $!;
close G or die $!;

unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
if (!stat "$sidecar.new") {
    $!==ENOENT or die "$sidecar.new: stat: $!";

    print STDERR <<END;
pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
NB that grub-mkrescue has a tendency to lie in its error messages.
END
    my $missing;
    foreach my $check (qw(xorriso mformat)) {
        $missing |= system qw(sh -c), "type $check";
    }

    if ($missing) {
        print STDERR <<END;
You seem to have some program(s) missing which grub-mkrescue depends on,
see above.  ("mformat" is normally in the package "mtools".)
Installing those programs will probably help.
END
    } else {
        print STDERR <<END;
And older grub-mkrescue has a tendency not to notice certain problems.
Maybe strace will tell you what is wrong.  :-/
END
    }
    die "pvshim-converter: grub-mkrescue did not make iso\n";
}

runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;

open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
print Q <<'END_DMWRAP' or die $!;
#!/bin/bash

set -x
: "$@"
set +x

newargs=()

newarg () {
    newargs+=("$1")
}

while [ $# -gt 1 ]; do
    case "$1" in
	-no-shutdown|-nodefaults|-no-user-config)
	    newarg "$1"; shift
	    ;;
	-xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
        -name)
            newarg "$1"; shift
            name="$1"; shift
            newarg "$name"
            ;;
	-netdev|-cdrom)
	    : fixme
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
	-drive|-kernel|-initrd|-append|-vnc)
	    shift; shift
	    ;;
	-device)
	    shift
	    case "$1" in
		XXXrtl8139*)
		    newarg "-device"
		    newarg "$1"; shift
		    ;;
		*)
		    shift
		    ;;
	    esac
	    ;;
	*)
	    echo >&2 "warning: unexpected argument $1 being passed through"
	    newarg "$1"; shift
	    ;;
    esac
done

#if [ "x$name" != x ]; then
#    logdir=/var/log/xen
#    logfile="$logdir/shim-$name.log"
#    savelog "$logfile" ||:
#    newarg -serial
#    newarg "file:$logfile"
#fi
END_DMWRAP

if ($qemu) {
    printf Q <<'END_DMWRAP', $qemu or die $!;
    exec '%s' "${newargs[@]}"
END_DMWRAP
} else {
    print Q <<'END_DMWRAP' or die $!;
set -x
for path in /usr/local/lib/xen/bin /usr/lib/xen/bin /usr/local/bin /usr/bin; do
    if test -e $path/qemu-system-i386; then
        exec $path/qemu-system-i386 "${newargs[@]}"
    fi
done
echo >&2 'could not exec qemu'
exit 127
END_DMWRAP
}

chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";

close Q or die $!;

rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";

print STDERR <<END;
pvshim-converter: wrote qemu wrapper to $dmwrap
pvshim-converter: wrote sidecar to $sidecar
END

my $append = <<END;
builder='hvm'
type='hvm'
device_model_version='qemu-xen'
device_model_override='$dmwrap'
device_model_args_hvm=['-cdrom','$sidecar']
boot='c'
serial='pty'
END

if ($out ne '-') {
    open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
} else {
    open O, ">&STDOUT" or die $!;
}

print O $indata, "\n", $append or die "write output: $!";
close O or die "close output: $!";

if ($out ne '-') {
    rename "$out.tmp", $out or die "install output: $!";
    print STDERR "pvshim-converter: wrote new guest config to $out\n";
} else {
    print STDERR "pvshim-converter: wrote new guest config to stdout\n";
}

[-- Attachment #7: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel