Directly allocate dma-bufs within the virtio-wl process and remove the
VmMemoryRequest::AllocateAndRegisterGpuMemory type. This is preparation
for migrating to the SharedMemoryMapper interface.
BUG=b:201745804
TEST=Launch arcvm, launch gedit w/crostini, launch gedit w/vhost-user-wl
Change-Id: I232f1fd3dfdb8d7ed068c6b3c2ea23f35d0ddabc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765012
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This was missed in the original rseq change.
BUG=b:235172163
BUG=b:235960683
TEST=emerge-hatch crosvm
Fixes: 17c782f1c1 ("seccomp: add rseq to all policy files")
Change-Id: Id78f0e0cd5c22142230abdc0cea6a7f91d492569
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765348
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
This duplicates rseq in all of the policy files and causes the minijail
compiler to fail due to duplicate definitions.
rseq was already added in commit 17c782f1c1 ("seccomp: add rseq to all
policy files").
This reverts commit 1a7a822858.
BUG=b:235960683
TEST=emerge-trogdor crosvm
Change-Id: I9d45897e6815b6cdd5ef376a27563ebc4af06bdd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765347
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Starting with v4.18, the Linux kernel provides the rseq
syscall which is a mechanism for fast userspace task
synchronization.
Starting with v2.35 glibc uses the new syscall, if it
exists, to gain some performance improvements, so we
need to update the policy files to allow it.
Even on older kernels where rseq is not supported,
glibc will still probe for its existence by expecting
an -ENOSYS response.
BUG=b:235960683
TEST=Local builds against glibc 2.35
Change-Id: I704f2fbf2b058c3a4c3269c7441c3a7324012f8a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3763901
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Owners-Override: Dominick Ng <dominickn@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Allow the restartable sequences system call used by glibc 2.35+.
This is an extension of commit 637402a827 ("Add rseq to the seccomp
policy file on aarch64."), which was originally reverted because the
ChromeOS kernel headers did not have the necessary declarations yet.
This depends on the rseq declarations patch to linux-headers:
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3749266/
BUG=b:235172163
BUG=b:235960683
TEST=Start crosvm on x86-64 Arch Linux with glibc 2.35
TEST=emerge-hatch crosvm # ensure seccomp policies compile
Reported-By: Peter Collingbourne <pcc@google.com>
Change-Id: I14e3dfd150a7c06bdafc68a88ef3f755eb7bf90c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3763776
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
This CL will add "vtpm_proxy" option into the crosvm.
BUG=b:227283268
TEST=Build OK.
TEST=vmc start --vtpm-proxy termina # With crrev.com/c/3697690
Change-Id: I44c81abc1e2f41a80276f4de70e269c07eff901f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3696293
Commit-Queue: Leo Lai <cylai@google.com>
Commit-Queue: Yi Chou <yich@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
We are going to use separate policy files per device for the following scenarios:
1) Regular in-VMM virtio device,
2) Virtio device over vhost-user,
3) Virtio device over Vvu.
Each of these scenarios require slightly different policies as a jailed
device process needs to allow not only the system calls necessary for
the device to function, but also those required by the virtio transport
in use.
This CL adds a README.md file to the seccomp directory that details the
naming and policy inclusion rules, and updates the serial, xhci and
coiommu policies to follow the naming scheme.
Vhost-user and VVU policy files will be added along with support for
jailing devices when they are in use.
BUG=b:217480043
TEST=serial device works with `crosvm run`.
Change-Id: I6d454aa6e05d00691fe3346e822ed1fc7b24aed8
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3706490
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Add Goldfish battery to aarch64 crosvm. The guest kernel will
see the goldfish battery node on the FDT.
This copies the seccomp policy for the battery from x86-64.
BUG=b:214124318
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
TEST=android-sh -c 'dumpsys battery'
TEST=tast run ${DUT} arc.PerfBoot.vm
Change-Id: I8212e760db5ffbc5d01442cfa7930baa5962ef6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3686713
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Masami Hiramatsu <mhiramat@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Masami Hiramatsu <mhiramat@google.com>
Some newer versions of glibc use this syscall.
Change-Id: I553db954b019fa5fc738074b28dbba78392c3ede
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3690467
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Peter Collingbourne <pcc@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This commit will fix crosvm crashes when playing audio
with ac97 device and null backend
BUG=b:233960497
TEST=run aplay -Dhw:0,0 -d 3 -f dat /dev/urandom inside a VM
Change-Id: Ic24853f308d92b2e5831d112f432f72f6fedd73c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3670934
Commit-Queue: Norman Bintang <normanbt@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
glibc 2.33 uses the fstatat64 syscall to implement statx(), which is
called by the USB emulation code when a device is added. Allow it along
with fstat64 to fix a crash on USB device insertion.
aarch64 and x86_64 use the newfstatat syscall instead, so they do not
need to be adjusted.
BUG=chromium:1328120
TEST=Attach yubikey to Crostini on kevin
Change-Id: I6a592e25126a5baebdbc8839ba11b971950f4575
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3671085
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The ioctl allow list for the emulated xhci USB controller device was
copied from the 32-bit ARM version, but the structure sizes are
incorrect for 64-bit aarch64. Update the constants for ioctls that take
a structure with a different size:
- USBDEVFS_REAPURBNDELAY: struct usbdevfs_urb
- USBDEVFS_SUBMITURB: struct usbdevfs_urb
- USBDEVFS_CONTROL: struct usbdevfs_ctrltransfer
BUG=chromium:1328120
TEST=Share USB device with Crostini on trogdor64
Change-Id: I45d69021257af55cfeaf72dd33a500a358adc5ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3670055
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On Unix, instead of getting random data from `/dev/urandom`, it will get
it from the `rand` platform agnostic crate instead.
OsRng.fill_bytes on unix will make a syscall to getrandom(2) if
available, otherwise it will read from `dev/urandom` after a succesful
poll to `dev/random`. Regardless of which way a random data is
retrieved, if the entropy pool is not intialized, `fill_bytes` will
block until it is intialized. This shouldn't be a problem because it is
a one time cost.
This CL will also upstream the Windows implementation of the rng device.
BUG=b:213149162
TEST=built and presubmits
Change-Id: Ic017f11795f8006e0bf2a04eb0478b3a3d336507
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3657812
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Richard Zhang <rizhang@google.com>
The top part of gpu_common.policy is supposed to match
common_device.policy. In https://crrev.com/c/1993163 we added
io_uring_setup and io_uring_enter to common_device.policy. Even though
there's nothing known to be broken, add these to the gpu_common.policy
to keep things matching.
BUG=None
TEST=kokoro
Change-Id: Ifd4c53c50ec12eb7e1e14f7eb80d2c9b8f0fbe46
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3631411
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
The top part of gpu_common.policy is supposed to match
common_device.policy, but "prctl" is in this top part and isn't in
common_device.policy. A bit of history:
* prctl used to be in the common_device.policy but was removed in
<https://crrev.com/c/2837307>.
* Even when prctl was in common_device.policy, it had different
arguments than what we allow in gpu_common.policy.
This is a no-op cleanup change.
BUG=None
TEST=None
Change-Id: Ic71c9da3ef9eb24665711d2000416ff9c87d49a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3631410
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
We already allow the system call in arm32.
Testing revealed that the call is actually in use.
BUG=b:231660764, b:230609113
TEST=cheets_CTS_R.internal.arm.CtsSkQP
Change-Id: Ia04089d1454312ac637e5c76d0aceafd2ab55134
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3632320
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
With testing, we're seeing secomp violations on aarch64. We need to
give access to "memfd_create" just like we did for arm32. Copy the
snippet from there.
BUG=b:223410173, b:230609113
TEST=Start arcvm; start android-sh; run tast arc.VMConfig
Change-Id: I4922e6decd67c3bc23fb090987b0318c384e0d68
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3626017
Auto-Submit: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
In <https://crrev.com/c/1952565> we moved gettid to the common
policy. Let's move the definition in the gpu common policy to the
same place to match.
This change was requested for arm64 in the code review of
<https://crrev.com/c/3543889>. This makes the call be in the same
place for arm32 and arm64.
BUG=None
TEST=CQ
Change-Id: I40628d344ca36267302e621709bb632406595b59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3615332
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
With these changes arcvm starts when running with 64-bit userspace and
this grep turns up blank:
grep SECCOMP /var/log/audit/audit.log
Generated by:
* Hacking minijail0 to always log <https://r.android.com/2072091> and
making sure it was compiled in debug mode.
* Hacking "crosvm run" to be "crosvm run --seccomp-log-failures". I
don't truly know if this is needed but it didn't hurt.
* Diffing arm vs. arm64
From comparing arm vs. arm64 there could still be some things missing,
or it's possible that arm has simply accumulated some cruft. More can
be added later if we find it's needed.
BUG=b:223410173, b:230609113
TEST=Start arcvm; start android-sh; run tast arc.VMConfig
Change-Id: Ib5407ddecc3d19f43e14e5b036ac64baee9335bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3543889
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Douglas Anderson <dianders@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
The TPM device was changed to manually include an edited subset of
common_device.policy in commit 25a86d99cc ("tpm: Update tpm device
policy to support libtpm2") because common_device.policy included rules
for open and openat at the time, and the TPM device needed to override
those rules. Now that common_device.policy no longer defines rules for
open and openat, it is safe to include the common policy instead of
duplicating it.
BUG=None
TEST=build with features=tpm and run with --software-tpm
Change-Id: Ia79d63fcf2cd2c5303384f4d0607b3b543406098
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482029
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This was already allowed in common_device.policy for arm platforms, and
it can be called via future/async code that is used by many devices. Add
it to x86_64 and aarch64 common policies as well.
BUG=b:220908060
TEST=Start Crostini with virtio-snd on hatch and trogdo
Change-Id: I9bf8f56ebed0cfe6d5e17e45226cac73db3d6d37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482026
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Recent builds (starting R100.14501.0.0) crash when attaching a USB
device to the Linux VM due to calling the statx syscall, which was
missing from the seccomp policy. stat was already allowed, so add statx
as well to prevent the crash.
The change is likely due to the upgrade of the Rust toolchain in the
Chrome OS SDK (https://crrev.com/c/3439725), which landed in this build.
This was already allowed on arm/aarch64, so no other changes are
required.
BUG=b:218565401
TEST=Attach USB device to crosvm on hatch
Change-Id: Ia3a383429a839c68b44040f4b99c990a1f1f8e9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3448188
Reviewed-by: Long Cheng <lgcheng@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
LRU unpin policy is an internal unpin policy which is triggered by
a timer. This policy can be used when there is no external balloon
unpin request.
BUG=b:188481989
TEST=Boot a VM with coiommu enabled + pass through devices.
Change-Id: Icb6e19073cb668fa954aec97e02be77f1b8f6a04
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292937
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Coiommu can be enabled through the command line. E.g.
To enable coiommu for a VFIO pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=coiommu
BUG=b:188481989
TEST=Boot a VM with a VFIO pass through device w/ coiommu
TEST=Boot a VM with a VFIO pass through device w/o coiommu
Change-Id: Ica6145d7bc6a4c398f0fc10899f8ee24138615c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292934
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds a command line parameter for instantiating a VVU proxy
device.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I5ff56e6f1ebca5a7078eca3d951ddbfd411d14fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3290381
Reviewed-by: Chirantan Ekbote
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
The video device needs to redefine the filters for mmap and mprotect,
which the minijail compiler rejects:
compile_file: /usr/share/policy/crosvm/video_device.policy(35): syscall mmap redefined here
compile_file: /usr/share/policy/crosvm/common_device.policy(26): previous definition here
compile_file: /usr/share/policy/crosvm/video_device.policy(36): syscall mprotect redefined here
compile_file: /usr/share/policy/crosvm/common_device.policy(27): previous definition here
compile_filter: compile_file() failed
failed to compile seccomp filter BPF program in '/usr/share/policy/crosvm/video_device.policy'
Prevent this error from happening by inlining the common_device
declarations in video_device and removing the declarations for mmap and
mprotect.
BUG=b:210601086
TEST=Video device can be created when making crosvm use the .policy
files instead of compiled .bpfs.
Change-Id: Ifa7aa84772ae59123cc04e8c9ea845ba6ed7b559
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3341131
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
When "--gpu-render-server path=<path>" is specified, start the render
server shipped with virglrenderer and initialize virglrenderer with
VIRGLRENDERER_MULTI_PROCESS flag.
The flag makes virgl_renderer_context_create_with_flags create proxy
contexts instead of venus contexts. Each proxy context requests the
render server to fork a subprocess and executes GPU commands in the
subprocess.
BUG=b:177267762
TEST=run vk and gl apps on volteer
Change-Id: If5e2dc3353572cadb60b0c25a3e0ad14f633db91
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3283508
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Missed a couple that do not inherit from common_device.policy.
BUG=b:209021536
TEST=Cq
Change-Id: I672af4e7746bbf971193a10031f0ac27302ef3b0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314284
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
aarch64 only has the readlinkat syscall.
BUG=b:209021536
TEST=Cq
Change-Id: I0a6a76bbc388f598f639a97832269256f6e9a61e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314710
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The panic handler uses getcwd and readlink to print out the executable
name in the backtrace. Allow these for all devices so that panics
actually work instead of crashing the process.
BUG=None
TEST=intentionally panic crosvm on kevin and check /var/log/messages
Change-Id: If64a752a6f0b1f2f6bdd6663ce77078305f38171
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309201
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The syscall is used for the file backed memory region used
by the audio device since https://crrev.com/c/3159883
BUG=b:208264646
TEST=CQ
Change-Id: I02c24da6389d60847996a62ee0eab658f9c4f7cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3307240
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
With the new glibc 2.33 roll, we're seeing crashes live relating to
statx (syscall 397). The process that's crashing is pcivirtio-video,
so we suspect video_device.policy is the breaking policy.
Crash report: http://shortn/_4EWpF4q77O
This was very recently fixed in arm (where the original crash occured),
however, it's still missing in the amd64/x86_64 policy file. It's
very feasible we'll see a similar case in the future with this arch.
BUG=b:187795909
TEST=CQ
Change-Id: I7b02ccf02d214590aadc37dc53e00ad34e178a4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3291890
Auto-Submit: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
I guess this was caused by libc uprev so the actual used
system call changed.
BUG=b:206348631
TEST=manual - Run arc.Boot.vm on kukui-arc-r with updated policy
Change-Id: Ibb8702d9ec6844624c9779088aefcdad34322d80
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3290581
Auto-Submit: Lepton Wu <lepton@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Fixes https://crrev.com/c/3199298, which only added the new ioctl
argument to the seccomp syscall filters on x86.
BUG=b:169908659
TEST=tast.crostini.SecureCopyPaste.* on scarlet
Change-Id: Ifd44c7b403f862d5528d8cc3655f0cd2c71c6e13
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3276675
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Add support for guest fences backed by host sync_files. Rather than
adding a new fence type, fences are implemented as vfds that only
support hup. The host simply waits on the sync_file and sends the guest
a hup when the fence is signaled.
BUG=b:169908659
TEST=Revert ag/15543199, resize ArcCameraFpsTest
Change-Id: I8c79ec9f418b1d71150b5a19f500c5ac7a6c9b02
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3199298
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The sched_yield system call is somehow called by the code the rust
compiler generates and not directly by the author's implementation. That
along with the fact that it won't get called on every run makes it very
easy to miss when adding a new device (that happened with virtio-snd).
Since that call is quite harmless (it could be argued minijail shouldn't
even block it in the first place) it makes sense to allow it for all
devices.
BUG=b/201306350
Change-Id: I9895da6c8060ae83053474ed9e4472ea2cd8d3e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248126
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
