This USB ioctl is used in usb_util::Device::clear_halt(), but it was not
allowed in the seccomp policy.
BUG=chromium:1167286
TEST=Attach Keyspan USA-19H USB serial adapter to Crostini
Change-Id: I625cde121a0a248046e476eecd732a98530811dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2633824
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Matthew Blecker <matthewb@chromium.org>
Commit-Queue: Matthew Blecker <matthewb@chromium.org>
New syscalls and /run/perfetto bind mount are required.
BUG=b:174162684
TEST=Run crosvm with perfetto instrumentation and confirm that
events can be traced through traced. Tested on both hatch
and ARM kukui device.
Cq-Depend: chromium:2570487
Change-Id: I809400ec393c2971ba9a1134ddbef7f48d818786
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571659
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: John Bates <jbates@chromium.org>
Commit-Queue: John Bates <jbates@chromium.org>
Needed by arcvm. Also fix some style issues with the previous ioctl
definitions.
BUG=b:136127632
TEST=Call this ioctl from inside a VM and see that it is passed through
to the host.
Change-Id: Icdeff9e2c5b15237ed49e6814b8147258a50ccab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560286
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
These don't work without a kernel change that we never merged. Arcvm
doesn't need these anymore so just drop them.
BUG=b:136127632
TEST=vm.Virtiofs
Change-Id: I427dee41720b0db1d14f4d03c95ff678ec3fd347
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2573709
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This CL wires up the powerd D-Bus PowerMonitor implementation to GoldfishBattery.
BUG=b:137890633
TEST=observe updated power data in ARCVM's /sys/class/power_supply after crrev.com/c/2550102
Change-Id: I38c613f13d3f7601435532213c7733558cb5f83f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560276
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The goldfish battery irq will be used to notify the guest driver that
battery/ac status changed. And the status changing will be done through
external crosvm commands. So the irq injection needs to be done in a
seperate thread which can receive these commands.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
and boot linux guest with goldfish_battery driver enabled. The sysfs
created by the goldfish_battery driver have no issue observed.
TEST=goldfish_battery driver is loaded on ARCVM and interrupts are enabled
Change-Id: Icc902dd8c00bdcf6cb271b20d928a4081533dde6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119573
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The p9 crate API changed so that the new() function now returns a
result. Update the caller to match.
Additionally, the implementation also changed to use different syscalls
so update the seccomp filters to match.
BUG=b:162388795
TEST=Start a vm with a 9p mount and test the changed operations to make
sure they still work.
Cq-Depend: chromium:2494169
Change-Id: I7c4e1fd2fb192206402e895b09e519c3e769ae3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2494328
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
There are no *at variants for the xattr syscalls so we were using the
path-based variants by reading the /proc/self/fd symlink. While this
symlink can track renames it cannot track if the user hard links the
file to some other location and then unlinks the original location. In
this case the symlink simply shows that the path was deleted even though
the fd is still valid.
To deal with this, stop using the path-based method. For regular files
and directories, we can simply open them and then make the appropriate
f{get,set,list,remove}xattr syscall. For non-regular files and
directories we can emulate an *at syscall by changing the CWD to /proc
and then making the path-based syscall via the self/fd path. Even
though the symlink is no longer valid, manipulating the fd via this path
still works.
BUG=b:168689429
TEST=Create a file, set an xattr, hard link it to a new location,
unlink the original, and then verify that {get,set}fattr still
works on the new link
Change-Id: Ic291f432b96f18e3e7ccbcf27737d5f8fd240a65
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2437684
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
When requested with the --gpu=cache-path=/path arg, crosvm
will pass it to Mesa via env var MESA_GLSL_CACHE_DIR. In
addition, the cache-size will also be passed along if
provided.
BUG=b:168540438
TEST=run with --gpu=cache-path=/tmp,cache-size=50M and
confirm that files are created in /tmp/mesa_shader_cache.
Change-Id: I2525597749d654a65373a723cefeab6cf2be62d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2415509
Tested-by: John Bates <jbates@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Riley <davidriley@chromium.org>
The git submodule needs to be updated to work with newer chroot libssl.
In addition, the new OpenSSL version uses the getrandom syscall, so it
needs to be added to the seccomp policies.
TEST=build_test works again, vm's boot with a --software-tpm
Change-Id: Ie3242e9fa4dba42bf6266e674f987d8c9dbc1dbe
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2316380
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
BUG=chromium:1053847
TEST=Listen to the socket from VmLogForwarder, observer messages
forwarded into separate output file.
Change-Id: Ia472e34b78db599e91f63e72a13bf8539d0d6312
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2287077
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Nicholas Verne <nverne@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Nicholas Verne <nverne@chromium.org>
Auto-Submit: Nicholas Verne <nverne@chromium.org>
Posix acls are a truly incredible example of API design. The presence
of a default posix acl in a directory completely changes the meaning of
the `mode` parameter for all system call that create inodes. However,
this new behavior only applies when the inode is first created and not
for any subsequent operations that use the mode, like fchmod.
When a directory has a default posix acl, all inodes created in that
directory get the permissions specified in the default acl. The mode
parameter is treated like a umask where any permissions allowed by the
default acl that are not allowed by the mode parameter are blocked. The
actual umask is ignored in this case.
So to handle this properly we need to set FUSE_DONT_MASK to prevent the
kernel driver from preemptively applying the umask. Then we have to
check if the parent directory has a default posix acl and only apply the
umask to the mode if it does not. This also means that we cannot use
`mkdtemp` because that always creates directories with a mode of 0o700
and since the default posix acl calculation only applies on creation and
not on later operations, we need to apply the proper mode in the very
beginning.
BUG=b:159285544,b:152806644
TEST=vm.Virtiofs. Use a test program to create files/directories in
directories that have a default acl and ones that don't, and verify
that the mode is correctly set after creation
Change-Id: Ieca8ac9db391feebe5719630c5f3b57b04b71533
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2260253
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Needed by arcvm.
BUG=b:159297591
TEST=run a test program that calls the ioctl
Change-Id: I1f8c17fa2b2457f5a9e73045c3dbee3440eb943d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2265932
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
MALI GPU driver calls this for printing debug information. Just
enable it since it could help debug.
BUG=None
TEST=manual - Run ARCVM on kukui with debug build of mali driver
Change-Id: If65121520071a1df9b8ba932272428cbac844984
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2262176
Tested-by: Lepton Wu <lepton@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Lepton Wu <lepton@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Lepton Wu <lepton@chromium.org>
Arcvm needs this ioctl for looking up the project id of an inode.
BUG=b:157189438
TEST=Call the ioctl inside a vm and verify that it succeeds
Change-Id: Ib178cf32b09056f9b1e9acedb49de068d5525a66
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2214964
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Matthias Springer <springerm@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
When creating a file or directory the virtio-fs server changes its
effective uid and gid to the uid and gid of the process that made the
call. This ensures that the file or directory has the correct owner and
group when it is created and also serves as an access check to ensure
that the process that made the call has permission to modify the parent
directory.
However, this causes an EACCES error when the following conditions are
met:
* The parent directory has g+rw permissions with gid A
* The process has gid B but has A in its list of supplementary groups
In this case the fuse context only contains gid B, which doesn't have
permission to modify the parent directory.
Unfortunately there's no way for us to detect this on the server side so
instead we just have to rely on the permission checks carried out by the
kernel driver. If the server receives a create call, then assume that
the kernel has verified that the process is allowed to create that
file/directory and just create it without changing the server thread's
uid and gid.
Additionally, in order to ensure that a newly created file appears
atomically in the parent directory with the proper owner and group,
change the create implementation to use `O_TMPFILE` and `linkat` as
described in the open(2) manpage. There is no `O_TMPFILE` equivalent
for directories so create a "hidden" directory with a randomly generated
name, modify the uid/gid and mode, and then rename it into place.
BUG=b:156696212
TEST=tast run $DUT vm.Virtiofs
TEST=Create a test directory with group wayland and permissions g+rw.
Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and
`su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`.
Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
This CL adds a fundamental part of the virtio video device, which will
be shared between the encoder and the decoder.
Both devices uses the virtio-video protocol proposed as RFC v3 [1,2].
The corresponding driver code is at CL:2060327 and its children CLs.
The actual decoding and encoding logic will be implemented in different
CLs.
[1]: mail: https://markmail.org/thread/wxdne5re7aaugbjg
[2]: PDF: https://drive.google.com/file/d/1jOsS2WdVhL4PpcWLO8Zukq5J0fXDiWn-/view
BUG=b:147465619, b:140082257
TEST=cargo check --features=video-decoder,video-encoder
TEST=ARCVM started with --video-decoder --video-encoder
Cq-Depend: chromium:2203997
Change-Id: I01999eea218ba0f3aaed1558ca2311a57d0c6819
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1973973
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
A mesa change to the amdgpu driver "winsys/amdgpu: Re-use
amdgpu_screen_winsys when possible" causes kcmp to be called with the
following simplified stacktrace.
SYS_kcmp
os_same_file_description
amdgpu_winsys_create
radeonsi_screen_create
<snip>
eglInitialize
virgl_egl_init
virgl_renderer_init
The use of this syscall caused the gpu device process to be killed with
SIGSYS. This change fixes that by allowing kcmp in that process, which
should be secure given the sandboxing in place and the level of
permissions required by kernel to succesfully use the kcmp syscall.
BUG=chromium:1070805
TEST=crostini.GPUEnabled.artifact_gpu_unstable
Change-Id: Ica0e5c6ebc01cbc33ac62fea001949798ca4446e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2151145
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Drew Davenport <ddavenport@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Using the `open_inode` method on an fd for a symlink results in the
kernel returning -ELOOP. Since there are no `*at` methods for extended
attributes, manually read the path for the file and then use the
l{get,set,list,remove}xattr method on the returned path.
BUG=b:136128512
TEST=boot arcvm with virtio-fs and selinux enabled
Change-Id: I2fde57db8a075838a3a877309f6cf89059f19258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2120763
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Add a frequency file that teaches the seccomp compiler to weight the
comparison tree in favor of the most frequenctly called syscalls.
This frequency file was created by running strace against vm_conciege's
pid (e.g., "strace -p PID -ff -e raw=all -o /tmp/strace") when
performing a start and stop of a VM, deleting the trace files that
weren't for a crosvm process, passing the files to minijail's
tools/generate_seccomp_policy.py (using the -frequency option), and
combining the results of the frequency file. I rounded the #s to the
nearest multiple of 5 and only retained the syscalls that had at least
10 calls.
BUG=None
TEST=Local build and deploy. Verified that crostini VM still boots and
shuts down properly. Used scmp_bpf_disasm to disassemble a few bpf
files before and after this change to confirm that with the frequency
file the first comparision is "jge 2" (to quickly whitelist syscalls
0 and 1 ['read' and 'write']) instead of a comparison around the middle
of the range of syscall numbers that are used.
Change-Id: Icace2b5cdbcae6e51cfd67a3034a1a17fdb6d59e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2005793
Commit-Queue: Matt Delco <delco@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Matt Delco <delco@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The build-time seccomp compiler for aarch64 complains that it doesn't
recognize open, epoll_wait, recv, mmap2, dup2, poll, mkdir, or stat.
I tried to propose a change to upstream minijail to make it aware of
these syscalls, but the calls are in various forms of deprecation
so upstream is doubting the sanity of the policy files.
I applied the following mapping: open->openat, epoll_wait->epoll_pwait,
recv->recvfrom, mmap2->mmap, dup2->dup3, poll->ppoll, mkdir->mkdirat,
and stat->statx. In many cases the new syscall was already present so I
just deleted the old one.
BUG=None
TEST=Ran compile_seccomp_policy.py with an unmodified minijail until
it stopped complaining. I don't have an arm device for runtime testing.
Wrote an app to emulate the execution of the first 400 syscall #s though
the bpf filter and verified that the list that matches the filter is the
same as the policy file.
Change-Id: I599aa549a1712b898eb6b73492872a9676e7215d
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2036218
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Minijail's policy compiler complains when there's multiple
unconditional rules for a syscall. In most cases the rules
are redundant to common_device.policy.
BUG=None
TEST=Ran compile_seccomp_policy.py until it stopped
complaining.
Change-Id: Ic43d1fd13f9c012641d71e526942229eb8b08ed4
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034024
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Minijail's policy compiler complains when there's multiple
unconditional rules for a syscall. In most cases the rules
are redundant to common_device.policy. I don't know what
to do about the intentionally contradictory rules for open
and openat, other than to remove then from the common device
policy and add it to all the others.
BUG=None
TEST=Ran compile_seccomp_policy.py until it stopped
complaining.
Change-Id: I6813dd1e0b39e975415662bd7de74c25a1be9eb3
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1918607
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is used in Rust 1.40.0's libstd in place of stat/fstat; update the
whitelists to allow the new syscall as well.
BUG=chromium:1042461
TEST=`crosvm disk resize` does not trigger seccomp failure
Change-Id: Ia3f0e49ee009547295c7af7412dfb5eb3ac1efcb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2003685
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This allows us to use export a directory to a VM with the
'--shared-dir tag:/dir' crosvm command line flag without relying
on seneschal. The fs device's policy already does the same.
BUG=b:123309049
TEST=Start tot ARCVM, run 'mkdir /var/run/arc/arcvm && mount -t 9p
-o "trans=virtio,version=9p2000.L,cache=none,access=any"
host_generated /var/run/arc/arcvm && ls /var/run/arc/arcvm',
verify ls prints files.
Change-Id: I8f8b265fc8a7de159508afbee5114b6a3f084d01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1995319
Tested-by: Yusuke Sato <yusukes@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Yusuke Sato <yusukes@chromium.org>
Add a control queue for virtio_net, and implement the command to set
available networking offloads.
Set offloads initially when acking features from the guest. We previously set
offloads on unconditionally.
Add TUNSETOFFLOAD to the allowed ioctls for virtio_net.
BUG=chromium:1031413
TEST=boot 5.4 guest, check vmtap offloads enabled with ethtool
TEST=enable ip_forward in guest, check vmtap offloads disabled with ethtool
Change-Id: I4129aa03419798906bd95cf65a6a4ab63069f50b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1968200
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Add support for FS_IOC_{GET,SET}_ENCRYPTION_POLICY. Unfortunately,
since the I/O direction is encoded backwards in the ioctl definitions,
these will only work with on a kernel that's compiled with a patch to
mark them as unrestricted FUSE ioctls.
BUG=b:136127632
TEST=Compile and run the vfs_crypto.c program on a virtio-fs mount
inside a VM
Change-Id: I124c5a943111b453dd44921a079a2baa1036dfd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1952570
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Instant::Now() is called from buffer_completed in ac97_bus_master.rs
sometimes, so we need this. It seems we've already added this to
arm. I guess that code path is only triggered on "slow" devices, that's
why we missed it here in the first place.
BUG=b:139318078
TEST=manual - Run betty-arcvm-pi board under qemu.
Change-Id: I45395eea4d69942c4e9577a39c8074888b4f637c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1954222
Tested-by: Lepton Wu <lepton@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Lepton Wu <lepton@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Lepton Wu <lepton@chromium.org>
The gettid syscall is used in some corners of glibc and it is a fairly
harmless syscall (we already give getpid), so this change moves it to
the common policy.
TEST=None
BUG=chromium:996938
Change-Id: I129644273f2f02fe917255c7157c48b99c329045
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1952565
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Add a variant of WriteZeroes that allows the caller to specify the
offset explicitly instead of using the file's cursor. This gets rid of
one of the last bits of shared state between disk file users, which will
help in implementing multi-queue support.
Additionally, modify the WriteZeroes trait to use a generic
implementation based on WriteZeroesAt + Seek when possible.
BUG=chromium:858815
TEST=Boot Termina in crosvm
Change-Id: If710159771aeeb55f4f7746dd4354b6c042144e8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1913519
The setres{u,g}id and the gete{u,g}id system calls on arm use 16 bit
values for uid_t and gid_t. This causes the kernel to interpret a
uid/gid of 65535 as -1, which means do nothing.
Use the 32-bit variants of these system calls instead so that we can use
32-bit values. Normally, libc would take care of hiding these kinds of
implementation details but since we can't use the libc wrappers for
these system calls, we have to do it ourselves.
BUG=b:136128319
TEST=`tast run vm.Virtiofs` on kevin
Change-Id: I6c0fda42c131e059139000828b3a53d4a73f340c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1923569
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Add x86_64 and arm seccomp policy files for the virtio-fs device.
BUG=b:136128319
TEST=Run a vm with a sandboxed virtio-fs device
Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Use the "at" variants of the read/write functions in the block device.
This reduces the number of syscalls on the host per I/O to one
(pread64/pwrite64) rather than two (lseek + read/write).
The CompositeDiskFile implementation is also updated in this commit,
since it's both a producer and consumer of DiskFile, and it isn't
trivial to update it in a separate commit without breaking compilation.
BUG=None
TEST=Start Crostini on kevin, banon, and nami
Change-Id: I031e7e87cd6c99504db8c56b1725ea51c1e27a53
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1845948
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This change plumbs the jail throughout the arch specific device creation
process. It also adds a custom callback support for the ProxyDevice so
that the main process can interrupt the child serial process when it has
incoming bytes.
TEST=crosvm run
BUG=None
Change-Id: I6af7d2cb0acbba9bf42eaeeb294cee2bce4a1f36
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1752589
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Create VFIO device and VFIO PCI device in create_devices() function, and
intergrate it into PciRootBridge, so guest could see this vfio device.
Add a vfio config parameter, this config point to passthrough or mdev
device sysfs path.
For passthrough case, first user unbind host device from its driver,
then bind host device to vfio-pci. Like:
echo 0000:00:02.0 > /sys/bus/pci/devices/0000:00:02.0/driver/unbind
ech0 8086 1912 > /sys/bus/pci/drivers/vfio-pci/new_id
Finally pass the sysfs to crosvm through
--vfio=/sys/bus/pci/devices/0000:00:02.0
For mdev case, user create a mdev device through
echo $UUID > mdev_type/create, then pass this mdev device to crosvm like
--vfio=/sys/bus/pci/devices/0000:00:02.0/$UUID
BUG=chromium:992270
TEST=none
Change-Id: I0f59d6e93f62f9ab0727ad3a867d204f4ff6ad2d
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1581140
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Two compounded issues broke GPU support on ARM:
1) A mistake when applying code review comments to the initial checkin
of this file and not correctly copying the updated policy when testing
to the DUT.
2) Iteration of the /dev/dri directory from libvirglrender.so uses
getdents instead of getdents64, likely due to some differences in the C
vs Rust runtime.
BUG=chromium:1002667
TEST=glxgears with virtio-gpu on kevin
Change-Id: I225b85998a6a611ebe2a25a75cd88aab9939feb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1799287
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
