Builders of crosvm, such as the crosvm ebuild, should determine if they
want LTO enabled. By having lto removed from the release profile,
builders using `--release` will not be forced to use LTO.
BUG=None
TEST=cargo build --release should be heckin' fast
Change-Id: I4e231b6dac7670ab146d36c1c1660ab67935285a
Reviewed-on: https://chromium-review.googlesource.com/1497734
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This changes the default Linux kernel command line from panic=1 (reboot
one second after panic) to panic=-1 (reboot immediately on panic). The
kernel should not normally panic; this is just to improve quality of
life for developer workflows, such as running bash as init and exiting
the shell to shut down the VM.
BUG=None
TEST=crosvm run -r vm_rootfs.img -p init=/bin/bash vm_kernel; exit shell
Change-Id: I7c9084ccf1786cd4455fd748512078e02fdb17fa
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1500872
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
For the commands that verify the length of arguments, returning
Ok on an invalid length will confuse any external programs that
launch crosvm because they still get exit code of success from
crosvm even when the command failed.
Also add a missed return of 'create_qcow2' sub-command.
BUG=None
TEST=some basic tests:
() cargo check
() verify the return value from changed sub-commands is not 0 with
an invalid argument length.
() launch a VM with concierge_client from a root shell
Change-Id: I8278107a4d2fcf3cb6fafb65f30f431f97f7deb1
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1501552
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Check that the device can be created. This test would have caught the
bug with adding pci bars.
Change-Id: Ib0cc2edf0d8d1b2d95d9c3588ac325b5da886603
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1497738
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
On arm, if the device is not coherent, guest kernel will allocate dma memory as
no-cacheable. Crosvm on the host user space thinks the memory is
cacheable. Thus when guest kernel write to dma memory, it will bypass
the cache, crosvm won't see the change.
BUG=None
TEST=local build and test
Change-Id: If6cf2d28afec61d5beb136628116ff9e7e0483f4
Reviewed-on: https://chromium-review.googlesource.com/1497739
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The description method is deprecated and its signature forces less
helpful error messages than what Display can provide.
BUG=none
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I27fc99d59d0ef457c5273dc53e4c563ef439c2c0
Reviewed-on: https://chromium-review.googlesource.com/1497735
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
When switching to PciBarConfiguration, the set_* functions were changed
to return self. The self for register index 1 was not being used.
TEST=boot a VM and check that there isn't a pci bus creation error.
Change-Id: I8d5162c70fcec1159a6283e26e744d0c3c76b804
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1497737
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Due to repeated syscall rules in gpu_device and common_device policies,
minijail fails to compile the gpu_device.policy. This change unrefactors
that policy so that it may compile properly.
BUG=chromium:936633,chromium:837073
TEST=vmc start --enable-gpu termina
Change-Id: I09ab9296247279c3a9ba6e3a6852e2a7ae2612ed
Reviewed-on: https://chromium-review.googlesource.com/1493424
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
When running in multiprocess mode, such as on a device, TPM state gets
placed in /run/vm/tpm.{pid} (e.g. /run/vm/tpm.22726) where pid is the
pid of the original crosvm process. The TPM simulator will write a
single file called NVChip of size 16384 bytes into this directory. The
directory and NVChip file will have uid and pid set to crosvm.
When running without multiprocess mode / without minijail / probably in
cros_sdk, TPM state is placed in /tmp/tpm-simulator as before. The
/run/vm directory is not present under cros_sdk.
Will follow up with a separate CL to remove the TPM state directory at
crosvm exit.
Tested by running the following on a grunt board (Barla) in dev mode:
sudo crosvm run \
--root rootfs.ext4 \
--socket crosvm.sock \
--seccomp-policy-dir seccomp \
--software-tpm \
-p init=/bin/bash \
-p panic=-1 \
vmlinux.bin
and confirming that /dev/tpm0 and /dev/tpmrm0 are present in the VM.
BUG=chromium:921841
TEST=manual testing on grunt
Change-Id: I1868896b9eb6f510d8b97022ba950b3604d9d40b
Reviewed-on: https://chromium-review.googlesource.com/1496910
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The same logic will be needed for the TPM device in a later CL.
BUG=none
TEST=cargo check
TEST=cargo check --features gpu
Change-Id: I1497a5eab51752db80b4b457834e45d669af69b7
Reviewed-on: https://chromium-review.googlesource.com/1497731
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested by running the following on a grunt board (Barla) in dev mode
together with CL:1496910:
sudo crosvm run \
--root rootfs.ext4 \
--socket crosvm.sock \
--seccomp-policy-dir seccomp \
--software-tpm \
-p init=/bin/bash \
-p panic=-1 \
vmlinux.bin
and confirming that /dev/tpm0 and /dev/tpmrm0 are present in the VM.
I needed to override the common device policy's `open` and `openat` and
was not able to get that working with the existing @include.
Note: untested on arm.
BUG=chromium:921841
TEST=manual testing on grunt
Change-Id: Ied7f18a631ce8c0ae280f8b6c01511ca20c3d1c8
Reviewed-on: https://chromium-review.googlesource.com/1496909
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Rename functions and parameters that had 'virtio' in their names
because we also create non-virtio devices like audio.
BUG=none
TEST=emerge-eve crosvm and deploy it to the device, verify some of
devices are still created at /sys/bus/virtio/devices/
Change-Id: I3ea75159a865e5f00ecef349725b3c12f94afaca
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1480739
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Plugin needs to access to various services such as cras, cups, and so
on, and therefore we need to make sure their respective groups are
mapped in the plugin jail.
BUG=b:117989168
TEST=Start plugin via concierge_client and verify that additional
groups besides crosvm are visible in the jail.
Change-Id: Ic1151fcfca0ca75c9ae6a22828853bbe6c9fe16c
Reviewed-on: https://chromium-review.googlesource.com/1495723
Commit-Ready: Dmitry Torokhov <dtor@chromium.org>
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Not sure if adding the device addresses to the mmio bus
is the desired behavior, but it seems to work.
BUG=chromium:924405
TEST=boot VM
Change-Id: I7f6057b3e7d041a52b251af1203353ba7a0d3c22
Reviewed-on: https://chromium-review.googlesource.com/1480743
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The idea is that virtio devices can specify additional memory
regions.
BUG=chromium:924405
TEST=run VM
Change-Id: I2a9f233ca8e2bc4fd9b05ee83101b11deb6e7b04
Reviewed-on: https://chromium-review.googlesource.com/1480742
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This removes add_memory_region and add_io_region, and replaces
it with the add_pci_bar function.
BUG=chromium:924405
TEST=boot VM
Change-Id: Ifc637d174d3f8b1255cf13725a1a224b4cdf0a30
Reviewed-on: https://chromium-review.googlesource.com/1480741
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We want to support 64-bit BARs and some additional functionality
is required.
BUG=chromium:924405
TEST=compile
Change-Id: I06aba41b6dfb9649437a417a32cb450d19d0d937
Reviewed-on: https://chromium-review.googlesource.com/1480740
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Use a function to reduce the repetition.
BUG=None
TEST=some basic build and runtime tests on an eve device:
() run 'cargo check' and 'emerge-eve crosvm'
() launch default termina VM from GUI, install and open
eclipse app to test network, input and graphic features
() launch a test VM instance from shell and vsh into it,
verify virtio devices are created at
/sys/bus/virtio/devices/
Change-Id: If66defdd584cf9afa6f38531e41b85d327362dfa
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1480738
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that the connection oriented seqpacket sockets are used for vm
control messages, a response can be received by the requested. This
change prints out that response.
TEST=crosvm suspend|resume|balloon|stop <socket>
BUG=chromium:848187
Change-Id: I18ac23c26127332e2be498113cc0c3310fd09a7d
Reviewed-on: https://chromium-review.googlesource.com/1482370
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The advantage of seqpacket is that they are connection oriented. A
listener can be created that accepts new connections, useful for the
path based VM control sockets. Previously, the only bidirectional
sockets in crosvm were either stream based or made using socketpair.
This change also whitelists sendmsg and recvmsg for the common device
policy.
TEST=cargo test
BUG=chromium:848187
Change-Id: I83fd46f54bce105a7730632cd013b5e7047db22b
Reviewed-on: https://chromium-review.googlesource.com/1470917
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change adds the ability to make seqpacket pairs, and set the
timeouts of the sockets. This also adds a TcpListener style api for
accepting UnixSeqpacket sockets.
TEST=cargo test -p sys_util
BUG=chromium:848187
Change-Id: I9f9bb5224cdfaf257d8e4a1bdaac8128be874951
Reviewed-on: https://chromium-review.googlesource.com/1482371
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
These panic!()s might be user-triggerable, and in any event are not fatal errors.
BUG=chromium:908689
TEST=Unit tests in file.
Change-Id: I774bb633dc627247bd807727542589400b59ed07
Reviewed-on: https://chromium-review.googlesource.com/1487674
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This allows the default pivot root used by crosvm to be defined at
build time. If it is not set, /var/empty is used.
BUG=chromium:934513,chromium:933582
TEST=PreCQ passes
Change-Id: I2b461170e6b75324740d4ff709fd599085cefe18
Reviewed-on: https://chromium-review.googlesource.com/1483330
Commit-Ready: Allen Webb <allenwebb@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add a script to run `cargo fmt` on all Rust code contained in crosvm.
This is different from `cargo fmt --all` which formats multiple crates
but a single workspace only. Crosvm consists of multiple workspaces.
Usage:
$ bin/fmt
To print a diff and exit 1 if code is not formatted, but without
changing any files, use:
$ bin/fmt --check
TEST=those commands
TEST=local kokoro
Change-Id: I4194509ad3a1bbc829c4b1069d54d940b927113b
Reviewed-on: https://chromium-review.googlesource.com/1477498
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These are each their own workspace so I guess `cargo fmt` at the top
level of the repo does not hit them.
I checked that none of the other workspace roots currently need to be
reformatted.
TEST=cargo check
Change-Id: I734cbc0f909fd3c2138513d9539b917bce80c0a8
Reviewed-on: https://chromium-review.googlesource.com/1477496
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Gate the current software tpm device behind a crosvm flag called
`--software-tpm`. When we get to leveraging the physical tpm, we will
likely want that behind a separate `--hardware-tpm` flag that is
automatically detected when the vm being launched is gLinux.
Based on feedback from apronin:
> Hm, long-term it may actually make sense to have software-tpm and
> real-tpm-for-glinux as two separate run-time options and only enable
> real-tpm-for-glinux for glinux.
>
> we want to protect guests from exploits, but we also want to limit
> access to tpm for random guests. So, enterprises may set this to "no
> TPM" for Linux images their employees run on their devices, so that
> they don't get creative with trying to break TPM from inside those
> images.
BUG=chromium:911799
TEST=run TPM playground program inside crosvm with flag set
TEST=confirm TPM playground does not run with flag unset
Change-Id: I1bccf62be63d40203463623f43b1a6ee2d51f6c0
Reviewed-on: https://chromium-review.googlesource.com/1478377
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
During review of CL:1387655 we observed that it shouldn't be necessary
for both vtpm_op_send and vtpm_op_recv to perform virtqueue kicks. It
should be sufficient for vtpm_op_send to place both an output buffer and
an input buffer on the virtio queue as a single descriptor chain, and
perform a single kick that executes both operations.
This requires a larger virtio queue because a single virtio buffer
cannot be both read and written.
BUG=chromium:911799
TEST=run TPM playground program inside crosvm
Change-Id: I6822efc3318a3952f91f64904e0434d916beae97
Reviewed-on: https://chromium-review.googlesource.com/1465642
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Cleanup only -- no functional change intended.
A lot of the current TPM virtio device is closely based on previously
existing virtio devices. This CL cleans up the TPM device in preparation
for a change that will let it handle send+recv as a single descriptor
chain.
- Pass all EventFds together inside of the Worker object.
- Introduce an Error enum to enable use of `?` error handling.
- Introduce NeedsInterrupt enum to clarify meaning of return value of
Worker::process_queue.
- Simplify code for instantiating Worker and spawning thread.
TEST=run TPM playground inside crosvm
Change-Id: I4a9a4b379a28d2336a1d9f2dce46f013e647ea16
Reviewed-on: https://chromium-review.googlesource.com/1478381
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Use of this value was removed in CL:1446932.
TEST=cargo check gpu_renderer
Change-Id: I8473cbddd074bb553187532926b7c6a870a24a51
Reviewed-on: https://chromium-review.googlesource.com/1477499
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Riley <davidriley@chromium.org>
I have been running into Debug-printed error messages too often and
needing to look up in the source code each level of nested errors to
find out from the comment on the error variant what the short name of
the variant means in human terms. Worse, many errors (like the one shown
below) already had error strings written but were being printed from the
calling code in the less helpful Debug representation anyway.
Before:
[ERROR:src/main.rs:705] The architecture failed to build the vm: NoVarEmpty
After:
[ERROR:src/main.rs:705] The architecture failed to build the vm: /var/empty doesn't exist, can't jail devices.
TEST=cargo check --all-features
TEST=FEATURES=test emerge-amd64-generic crosvm
Change-Id: I77122c7d6861b2d610de2fff718896918ab21e10
Reviewed-on: https://chromium-review.googlesource.com/1469225
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The Chrome OS Rust toolchain has been updated to Rust 1.32.0[1]; update
the version in Kokoro and the rust-toolchain file to match.
It looks like there is also one minor formatting change (again).
BUG=None
TEST=Build kokoro image and run tests
[1]: https://chromium-review.googlesource.com/1432733
Change-Id: I5669d99463618e19cb5e957171560dbea33bd5b8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470913
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Update the default Rust toolchain to the version specified in the
rust-toolchain file (which is part of the crosvm source directory, not
baked into the Docker image) during each kokoro run.
This will let us seamlessly update rust-toolchain without breaking the
builds using the existing kokoro Docker image once this change is in
place.
BUG=None
TEST=Build image with 1.31.0, then run test with rust-toolchain 1.32.0
Change-Id: If4f6dffc20af33011d2a96a0cf6b3db3582a2fd0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470914
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
PluginVm uses /dev/urandom, so we need to mount it, along with
/dev/zero, /dev/null, and /dev/full.
Note that we are not using minijail's mount_dev() API because it will
try to create tmpfs without using MS_NODEV flag and, since crovm may not
have CAP_SYS_ADMIN capability, Chrome OS LSM will stop it. So we rely on
the parent process to have minimal set of devices present and bind-mount
those into the jail.
BUG=b:117989168
TEST=cargo test --features=plugin
Change-Id: I6d8ab122c56614a8f7dbfe3d0eb8ed33532dc6a7
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1447551
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
I was skimming the gpu flag code (tpm will need something similar) and
found the way resource_bridge_wl_socket is used misleading. The same
variable is declared in two different places depending on whether
building with gpu. This CL combines them into one `let` statement.
Also moved the generic param onto None which comes out more readable
after rustfmt while still providing helpful context for the reader.
TEST=cargo check && cargo check --features gpu
Change-Id: I57a1ae214947475efa7bf01ab123a71a58411244
Reviewed-on: https://chromium-review.googlesource.com/1470915
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Allow --tap-fd to be given mutliple times, a different virtual network
card will be added each time the flag is given.
Additionally, --tap-fd is no longer mutually exclusive with --host-ip,
etc.
Bug=chromium:931470
Test=booted cuttlefish device with multiple network cards
Change-Id: I4108f97c7f4b19db12fcb3c533088a04a58e56db
Reviewed-on: https://chromium-review.googlesource.com/1469222
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This exports a new C API to resize a disk image. The new function is
intended to only expand (increase in size) to avoid accidentally
truncating user data due to bugs elsewhere.
BUG=chromium:858815
TEST=build_test.py
Change-Id: I6f834209aba693618e0f51d920e7b73d4f2a9dfc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1464384
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The glibc realloc() implementation may call the mremap syscall in some
cases; we currently allow mremap in x86_64/common_device.policy but not
the arm equivalent, but this path appears to be reachable on any Linux
platform[1]. Add mremap to the arm policy as well for consistency.
mremap is no more powerful than the existing mmap and munmap syscalls,
so I believe this is safe to allow for all device processes.
Also reorder the mmap2 line in the arm policy so it is in alphabetical
order and can be more easily compared to the x86_64 policy.
BUG=chromium:927919
TEST=Boot crosvm on kevin
[1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l2854
Change-Id: Ie51a21baf30d3e37ce3adacf8e255f981613543d
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1459020
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Remove a bunch of TODOs that mention things that the C++ test does that
we don't need to do, and replace a TODO with a detailed explanation of
why the code behaves as it does.
BUG=chromium:908689
TEST=None; comment-only change
Change-Id: I6791fbe329e8cdd1cac0d55b7770927d60c051c4
Reviewed-on: https://chromium-review.googlesource.com/1454141
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some of the variants of the CommandCounter enum are not currently used;
add a directive to ignore dead code warnings for these variants, since
they are defined by the hardware/spec and may be used in the future.
BUG=None
TEST='cargo build' executes without warnings
Change-Id: I72b6cd24722de801ebfe63bb7419c4e972463082
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1454139
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Miriam Zimmerman <mutexlox@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The default panic hook prints panic information and a backtrace to
stderr, where it gets dropped into /dev/null in the typical crostini
context.
This change adds a panic hook that will call the default panic hook
with stderr redirected to a pipe, which will then get forwarded to
syslog.
The new hook also forces an abort at the end to ensure the crash
reporter sees the panicked crosvm process, which will generate a
minidump for later debugging.
TEST=manually add panic!() observe /var/log/messages
BUG=None
Change-Id: I4e76afe811943e55cec91761447e03b949a674a4
Reviewed-on: https://chromium-review.googlesource.com/1440881
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Based on Linux boot protocol references:
- x86: Documentation/x86/boot.txt
- arm: Documentation/devicetree/bindings/chosen.txt
BUG=None
TEST=Boot Alpine Linux netboot initrd on x86_64 and aarch64
Change-Id: If4730765638f0a0b8bb8f63203c98e4765a354ee
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1407221
Tested-by: kokoro <noreply+kokoro@google.com>
