By default, KSM is disabled by the kernel. This is harmless if KSM
is disabled, and only causes merging if the user manually enabled
the feature on their kernel. If enabled, significant memory saving
can occur, at the cost of CPU cycles and a reduction in privacy.
Bug: 1346340
Change-Id: I838cdda97ea8d335b1953dd6775311958069898c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3780870
Reviewed-by: David Manouchehri <david@davidmanouchehri.com>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Initializing gralloc may spawn threads, so it needs to be done after
sandboxing the wl device. Initializing gralloc requires expanding the
wl device's sandbox. Rather than trying to maintain a new dedicated
minijail configuration for wl, reuse the gpu's configuration. This
should be sufficient, since virglrenderer has to open minigbm within the
sandboxed gpu process.
BUG=None
TEST=ARCVM and crostini GUI on volteer, zorc-arc-r, grunt-arc-r
Change-Id: I291fb59c665a8ba65058a6f55dee959c839bb43c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3787936
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Tested-by: David Stevens <stevensd@chromium.org>
Switch virtio-wl to the new shared memory APIs.
Using the shared memory APIs requires establishing mappings based on
shm offset rather than raw pfn. This means virtio-wl needs to manage its
shmem address space itself, rather than relying on
VmMemoryDestination::NewAllocation. To maintain compatibility with older
drivers, a feature bit is used to determine whether drivers expect
mappings to be specified by shm offset or by pfn.
BUG=b:201745804
TEST=launch crostini gui app
TEST=crosvm device wl --wayland-sock $XDG_RUNTIME_DIR/wayland-1 --socket /tmp/vhost.sock
TEST=crosvm ... --vhost-user-wl /tmp/vhost.sock ...
Change-Id: Ia559de7107130440c8f81a30aab1f6b061d15118
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765014
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
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 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>
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>
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>
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>
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>
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>
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>
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>
newfstatat has been added to a few policies for the
two 64bit architectures, but some more require it to
avoid crashes, so add it to all which contain fstat
or statx.
BUG=b:187795909
TEST=CQ
Change-Id: I3cd0f5379b87102caa256503a888c5a1aa4103b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3198571
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Enable with `--cras-snd`.
Verified:
Basic playback and capture
Missing features:
* Getting chmap/jack/stream info from CRAS. They are hardcoded for now.
* Jack connect/disconnect notifications from CRAS
* Reporting latency bytes to the driver. It is currently hardcoded to 0.
BUG=b:179757101
TEST=`aplay` and `arecord` inside a debian img with a 5.10 kernel built
with virtio snd support. Launched with crosvm on rammus/kukui/hatch
Change-Id: I240000a92418b75b3eb8dcd241ff320214b68739
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2777991
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Starting with glibc 2.33 the faccessat2 syscall is used and
only if it doesn't exist (eg kernel older than 5.8) glibc will
default to the older faccessat syscall, so we need to allow it.
Previously this syscall has been enabled on a per-component
basis after testing, but this one does a bulk enable when
faccessat is used on all architectures.
See glibc commit 3d3ab573a5 ("Linux: Use faccessat2 to implement
faccessat (bug 18683")
BUG=b:187795855
TEST=Local builds; CQ.
Change-Id: I1f17e82e8c416b0fa2c43342731e9ea8394c47fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3097212
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Since CL:2999451, libcras is using timerfd features from `cros_async`,
we need to add timerfd operations to the accepted list of
`cras_audio_device`'s seccomp policy files.
BUG=b:179757101
BUG=b:194452080
TEST=tast run ${DUT_IP} arc.Notification.vm
Change-Id: I74b33fa1e304fccc95b7326e04bedc32feff85f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3047951
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
Without the call, crosvm will not start when running
crostini/android tests.
BUG=chromium:1182687
TEST=CQ of https://crrev.com/c/2910526
Change-Id: I10abb8866474c2fe0398a17a80069cf2b0629493
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3011355
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
Kernels before 5.10 had known bugs in the io_uring implementation.
Don't use io_uring when we detect this. Also skip all the io_uring
tests in this case.
BUG=none
TEST=cargo test
Change-Id: I5fd6203ad25a6fb85ff28f1a6ddb0181f836ad89
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3006309
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Woody Chow <woodychow@google.com>
The libminijail version in AOSP complains when there are multiple entries for
the same system call, which was the case for virtio-fs's policy.
BUG=b/185811304
Change-Id: I389c07c86e7d79f16e4f47a893abad598033352a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2837307
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Fds created via dup don't share file descriptor flags with the original
fd, which means that they don't have the FD_CLOEXEC flag set. Use
fcntl(F_DUPFD_CLOEXEC) so that this flag gets set for the duplicated fds
as well.
BUG=none
TEST=unit tests
Change-Id: Ib471cf40acac1eacf72969ba45247f50b349ed58
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2809687
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
