make open_fd patch optional. if sandboxed-libusb feature is not selected,
open_fd is not required.
In this case, the code must have access to /dev/bus/usb, and not
external fd is needed.
BUG=chromium:831850
TEST=cargo test
Change-Id: I21fa87dd15d08a03c2fe2b190559abbe6f63dcd5
Reviewed-on: https://chromium-review.googlesource.com/1375019
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This wrapper will be part of usb emulation backend.
BUG=chromium:831850
TEST=local build
Change-Id: I084b15201941e4c16c4e3ff9b967e55db09db567
Reviewed-on: https://chromium-review.googlesource.com/1124870
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
The qcow_utils crate is not a dependency of crosvm and should not be
built in the same phase as crosvm. Doing so was harmless before the
recent rustc/cargo changes, which seem to be triggering some kind of
race condition. This change works around the bug.
CQ-DEPEND=CL:1336738
TEST=cargo test --release
BUG=chromium:900366
Change-Id: I01048128b20cf06580e809f6701688ab72e7756d
Reviewed-on: https://chromium-review.googlesource.com/1336737
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This will harden crosvm against potential integer overflow leading to
unsafe behavior in unsafe blocks.
TEST=cargo test --release
BUG=None
Change-Id: Ie750906d04c6ef8cb9400b976827c2abeab2ab56
Reviewed-on: https://chromium-review.googlesource.com/1282064
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
MsgSock wraps UnixDatagram and provides simple macro to define Messages
that could be send through sock easily.
TEST=cargo test
BUG=None
Change-Id: I296fabc41893ad6a3ec42ef82dd29c3b752be8b8
Reviewed-on: https://chromium-review.googlesource.com/1255548
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add the 9s crate, which provides an executable that can serve the 9p
file system protocol. It initially only supports connections over vsock
but can easily be extended to support network and unix domain socket
based connections.
BUG=chromium:703939
TEST=Run the server, have maitred connect to it over vsock, mount the
9p file system in the guest kernel, share it with the penguin
container, and run `bonnie++ -r 256 -s 512`
CQ-DEPEND=CL:1121550, CL:1166446
Change-Id: Ia0c72bcf29188bba4c07b6c0a2dd5a83d02339b5
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1112870
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Support macro derive(BitField) to make life easier.
BUG=None.
TEST=local build and run test.
Change-Id: I582620de250017fb7c0b601f9ad4fbcbbc2fe02a
Reviewed-on: https://chromium-review.googlesource.com/1069331
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Implement a policy for the balloon device so that it starts taking
memory away from the VM when the system is under low memory conditions.
There are a few pieces here:
* Change the madvise call in MemoryMapping::dont_need_range to use
MADV_REMOVE instead of MADV_DONTNEED. The latter does nothing when
the memory mapping is shared across multiple processes while the
former immediately gives the pages in the specified range back to the
kernel. Subsequent accesses to memory in that range returns zero
pages.
* Change the protocol between the balloon device process and the main
crosvm process. Previously, the device process expected the main
process to send it increments in the amount of memory consumed by the
balloon device. Now, it instead just expects the absolute value of
the memory that should be consumed. To properly implement the policy
the main process needs to keep track of the total memory consumed by
the balloon device so this makes it easier to handle all the policy in
one place.
* Add a policy for dealing with low memory situations. When the VM
starts up, we determine the maximum amount of memory that the balloon
device should consume:
* If the VM has more than 1.5GB of memory, the balloon device max is
the size of the VM memory minus 1GB.
* Otherwise, if the VM has at least 500MB, the balloon device max is
50% of the size of the VM memory.
* Otherwise, the max is 0.
The increment used to change the size of the balloon is defined as
1/16 of the max memory that the balloon device will consume. When the
crosvm main process detects that the system is low on memory, it
immediately increases the balloon size by the increment (unless it has
already reached the max). It then starts 2 timers: one to check for
low memory conditions again in 1 seconds (+ jitter) and another to
check if the system is no longer low on memory in 1 minute (+ jitter)
with a subsequent interval of 30 seconds (+ jitter).
Under persistent low memory conditions the balloon device will consume
the maximum memory after 16 seconds. Once there is enough available
memory the balloon size will shrink back down to 0 after at most 9
minutes.
BUG=chromium:866193
TEST=manual
Start 2 VMs and write out a large file (size > system RAM) in each.
Observe /sys/kernel/mm/chromeos-low_mem/available and see that the
available memory steadily decreases until it goes under the low memory
margin at which point the available memory bounces back up as crosvm
frees up pages.
CQ-DEPEND=CL:1152214
Change-Id: I2046729683aa081c9d7ed039d902ad11737c1d52
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1149155
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Basic 2D and 3D support is there. The drm_cursor_test and
null_platform_test in drm-tests should run to completion.
The extra device is hidden behind both a build time feature called 'gpu'
and the device is only added to a VM if the '--gpu' flag is given.
TEST=build with --features=gpu;
drm_cursor_test && null_platform_test
BUG=chromium:837073
Change-Id: Ic91acaaebbee395599d7e1ba41c24c9ed2d84169
Reviewed-on: https://chromium-review.googlesource.com/1036862
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These bindings are needed for virtio-gpu 3D capabilities.
All the rust files under gpu_renderer/src/generated are generated via
the gpu_renderer/src/generated/generate script.
The gpu_renderer/src/lib.rs file contains the Renderer and Context
structs, which are the main interfaces to virglrenderer. They
encapsulate the global state of virglrenderer (Renderer) and each
context ID (Context).
The command_buffer module is included only for basic testing and is not
intended for production use.
The pipe_format_fourcc module is provided for the conversion of
virglrenderer specifc formats to standard fourcc formats.
BUG=chromium:837073
TEST=cargo build -p gpu_renderer
CQ-DEPEND=CL:1144406
Change-Id: Iad153390f618309bf493e92e76432c0b1c4a8a93
Reviewed-on: https://chromium-review.googlesource.com/1043447
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Combine GPU buffer allocation with the system resource allocator making
life easier as only one allocator needs to get passed to the execute
function.
Change-Id: I199eb0fd6b99b629aaec1ae3295e8a1942da5309
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099856
This provides virtual display style output, useful for debugging
virtio-gpu. Although using virtio-gpu for display purposes clashes with
the more integreated virtio-wayland support, it is nonetheless helpful
for debugging virtio-gpu, and is technically required to fully implement
that device.
TEST=cargo build -p gpu_display
BUG=chromium:837073
CQ-DEPEND=CL:1096300
Change-Id: I59f895e951ef593d4119e7558168dd34223519ee
Reviewed-on: https://chromium-review.googlesource.com/1043446
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Allow IRQs to be assigned before creating device manager.
For PCI, we need to add devices with interrupts before MMIO setup. Add
the ability to tell the architecture device manager about IRQs that we
have stolen.
There was only one function in device_manager and all of its state is
now delegated to the resource allocator, remove it.
Change-Id: I9afa0e3081a20cb024551ef18ae34fe76a1ef39d
Reviewed-on: https://chromium-review.googlesource.com/1089720
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Add the AddressAllocator module that will be used by both architectures
to manage distributing address ranges to devices. This will make the
addition of PCI devices easier as now both MMIO and PCI will need to
share address space. Add this to a new resources crate.
Change-Id: I6a971dd795f2118bd6cfec7dc34a65b0d4a32f9b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072570
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
The p9 crate needs the libc::DT_UNKNOWN constant, which isn't available
in version 0.2.34 but is available in version 0.2.40.
BUG=chromium:703939
TEST=none
CQ-DEPEND=CL:1065064
Change-Id: If1451d5bcc2737abc2a14d2b81005c6318165e1f
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1013202
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Implement encoding and decoding various primitives using the p9
protocol. In addition, add a procedural macro to derive the encoding
and decoding implementation for structs built out of the primitives.
BUG=chromium:703939
TEST=unit tests
CQ-DEPEND=CL:1065063
Change-Id: I7256633fb7002da9ce8af03be2f24410b90ccf3f
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/969965
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This implements DMABuf allocation type in the virtio wayland
device.
We attempt to locate a supported DRM device prior to engaging
the device jail. If found, the DRM device is passed to the
wayland device code and used to serve DMABuf allocations.
DMABuf support can be disabled by not providing crosvm with
access to any DRM device nodes.
The guest is expected to handle the case when DMABuf allocation
fails and fall-back to standard shared memory.
This initial change uses DRM directly but is structured in a
way that would allow the allocator to be replaced by minigbm
with minimal effort.
BUG=chromium:837209
TEST=crosvm finds drm device and returns valid dmabufs to guest
Change-Id: Ic1fd776dfdfefae2d7b321d449273ef269e9cc62
Reviewed-on: https://chromium-review.googlesource.com/1034088
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: David Reveman <reveman@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add a build-time feature that allows having plugin and other parts of
crosvm to run outside of jailed environment. This is strictly a
development time feature and is not expected to be activated with
shipping code.
Sandbox can still be activated by passing -u (--multiprocess) option.
BUG=None
TEST=cargo test --feature=default-no-sandbox
Change-Id: If9ef1ce8ed0b5d23cef3ad193679baca94413360
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1054194
Reviewed-by: Zach Reizner <zachr@chromium.org>
These bindings are needed to allocate dmabufs that will be used for
accelerated rendering and zero-copy virtio-wayland support.
TEST=cargo test -p gpu_buffer
BUG=chromium:837073
Change-Id: I96d7bcdeaa1eda616a25fdcfedcbb734cd585ae7
Reviewed-on: https://chromium-review.googlesource.com/1029410
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
- removes old ARMv7a (32-bit) bindings as we're only supporting aarch64
guests right now
- switches both ARMv7 and aarch64 builds to use aarch64 kvm bindings
- adds support for ARMv8 Linux guest with dynamic flattened-device-tree
CQ-DEPEND=990894
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
TEST=crosvm runs on kevin built with USE="kvm_host"
Change-Id: I7fc4fc4017ed87fd23a1bc50e3ebb05377040006
Reviewed-on: https://chromium-review.googlesource.com/969987
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This creates a trait that different architectures can implement to
support running Linux VMs.
In the implementation on X86 we remove some error and return errors
from lower-level modules as appropriate. These modules now implement
the Error trait so we can get meaningful descriptions without an extra
error from the calling function. This still keeps all the ifdefs in
linux.rs for now until we have another implementation to use for ARM.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: If24bcc83e25f9127d6aea68f9272e639296aad8b
Reviewed-on: https://chromium-review.googlesource.com/952368
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
I will be refactoring this code to mostly live in the architecture
code, but for now it's simpler to move it out into it's own crate.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I85c12696fcd5cbef6a72a6dcbc484a443e0b0784
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/933084
The debug registers are useful to access for the plugin process in some
cases.
TEST=cargo test --features plugin; cargo test -p kvm; ./build_test
BUG=chromium:800626
Change-Id: I8f3f6c31c6989061a43cef948cf5b4e64bd52d30
Reviewed-on: https://chromium-review.googlesource.com/896945
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The plugin process is good for running a VM that depends substantially
on devices that aren't implemented inside of crosvm.
TEST=cargo build --features plugin; ./build_test
BUG=chromium:800626
Change-Id: I7b4f656563742cd0bedc837205dd1240d497941d
Reviewed-on: https://chromium-review.googlesource.com/869357
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is the shared library used by the plugin process to speak to a
crosvm main process that spawned it.
TEST=cargo build --features plugin
BUG=chromium:800626
Change-Id: I100e7ddfc1099fbdf1462c171785a861e075d5d7
Reviewed-on: https://chromium-review.googlesource.com/869356
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We'll want architecture code to be able to supply and manipulate Linux
kernel command lines, so let's move this out to it's own crate and
export the interfaces.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I94904055ac02582a4f4d8bbb54d0f41ed14b955d
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/898351
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This slightly advances the use of fakes to test higher level
application logic. The fakes are rudimentary at this point, but I
wanted to get feedback on the addition of generics in order to
facilitate swaping concrete implementations out with fakes in higher
level code.
BUG=none
TEST=./build_test and
cargo test -p crosvm -p data_model -p syscall_defines -p kernel_loader
-p net_util -p x86_64 -p virtio_sys -p kvm_sys -p vhost -p io_jail -p
net_sys -p sys_util -p kvm
Change-Id: Ib64581014391f49cff30ada10677bbbcd0088f20
Reviewed-on: https://chromium-review.googlesource.com/689740
Commit-Ready: Jason Clinton <jclinton@chromium.org>
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This C library will be use by the VM launcher to create the qcow2 files
used for persistent VM data.
CQ-DEPEND=CL:884263
BUG=none
TEST=cargo test --all -- --test-threads=1
Change-Id: Ibd7f71d2e3f1f72f781978f014865d2161f033f5
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/875116
QCOW2 files will be used to store the VM's data on ChromeOS. Add
support for basic reading and writing of qcow files.
CQ-DEPEND=CL:872451
BUG=none
TEST=qcow unit tests and use "qemu-image check" to verify generated qcow
files.
Change-Id: I4b9e77e58edca69f894ede19e79ebd2cd7b2623e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/862628
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Getting and settings seals is useful to ensure the size of files
underlying memory mappings doesn't shrink, which can trigger a SIGBUS on
access to the truncated pages.
This also bumps the libc version to get MFD_ALLOW_SEALING.
TEST=cargo test
BUG=None
CQ-DEPEND=CL:850535
Change-Id: Ifbe1ec2c47d3d5c51b63472f545acc10d3c8eed2
Reviewed-on: https://chromium-review.googlesource.com/849488
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Making the project a workspace allows running all local libs unit tests
from the main build.
Change-Id: Ib531dd10c21f324c7d25af69ad12b95c7bc8f3bc
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759597
Reviewed-by: Zach Reizner <zachr@chromium.org>
Moving the devices to their own module makes it easier to add tests that
use them.
Change-Id: I61bfef4037d16b20145b5fddce604835cdc4f67b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706559
Reviewed-by: Zach Reizner <zachr@chromium.org>
Break out vm_control to a crate that will be able to used by more
modules. Having vm_control usable from outside crosvm makes it possible
to move the devices out of crosvm in a later commit.
Change-Id: I1f060700ed49b5d77519d55efa2430490d521256
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706558
Reviewed-by: Zach Reizner <zachr@chromium.org>
To ensure dependencies don't accidentally get updated, their versions are
fixed using the equals constraint. The Cargo.lock file is also checked in
so that the registry won't need to be downloaded by cargo.
These changes are needed so that the crosvm ebuild will not need to
download anything outside of its list of source packages.
TEST=./build_test
BUG=None
Change-Id: Iae8472de77e3589a453685717b26fb1ceb44e257
Reviewed-on: https://chromium-review.googlesource.com/674092
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is so future changes can use getresuid/setresuid and similar
syscalls.
BUG=chromium:738638
TEST=./build_test
Change-Id: I47765fa1f45c549d8e148d02655dd61993a10f58
Reviewed-on: https://chromium-review.googlesource.com/655143
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This removes the clap dependency by replacing that functionality with a
custom written parser. Binary size is reduced by about 60% in optimized
and stripped mode.
TEST=cargo run -- run -h
BUG=None
Change-Id: I2eaf6fcff121ab16613c444693d95fdf3ad04da3
Reviewed-on: https://chromium-review.googlesource.com/636011
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This CL adds VM request capabilities to the control socket. These
requests include the basic exit as well as the essential ioeventfd and
irqfd requests. For virtio wayland, the register/unregister device
memory request was added.
TEST=cargo test
BUG=chromium:738638
Change-Id: I0cbf62d85a299cf454bcf6924a4e1d52d5b7183f
Reviewed-on: https://chromium-review.googlesource.com/602593
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
vhost_net is an in-kernel implementation of a virtio_net device. This device
implementation is responsible only for negotiating features and setting up
vhost_net to point to the virtqueues in the guest.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
BUG=chromium:738639
TEST=boot with networking enabled and ping host
Change-Id: I9192765b9348528a8a7a7f273e9522c2373d22fb
Reviewed-on: https://chromium-review.googlesource.com/538106
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The `clone_process` function was created to safely encapsulate
fork/clone usage for the proxy device. This patch changes proxy device
to do utilize that.
TEST=cargo run -- -u <other crosvm args>...
BUG=None
Change-Id: I2d9f1794be61be31f3aae21037c7df14b7691172
Reviewed-on: https://chromium-review.googlesource.com/518935
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Run with the new seccomp filter and drop all capabilities. In addition enter a
new user, mount, network, and ipc namespace. Leave the mount namespace empty
after pivot-rooting to an empty directory.
Change-Id: Iee583cf260ede8ca13f005836684eb80c2c3ac3e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/515603
This program is used to boot a 64-bit kernel elf. It has support for
basic devices that are exposed to the kernel, including a block device.
TEST=cargo test;
cargo run -- -m 512 -c 4 -d rootfs.squashfs -u -p "init=/bin/bash" vmlinux
BUG=chromium:712319
Change-Id: I25a8349a4624d8643fefe2ad70e517fe03b16b8c
Reviewed-on: https://chromium-review.googlesource.com/514417
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>