summary refs log tree commit diff
path: root/seccomp/x86_64/balloon_device.policy
Commit message (Collapse)AuthorAge
* seccomp: remove redundant unconditional rulesMatt Delco2020-01-22
| | | | | | | | | | | | | | | | | | | 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>
* seccomp: refactor policy into common_device.policyZach Reizner2019-02-07
| | | | | | | | | | | | | CQ-DEPEND=CL:1449895 BUG=None TEST=vmc start termina Change-Id: Ia3edaafc1d2958bd40e6b1adc89dd5e29b679b06 Reviewed-on: https://chromium-review.googlesource.com/1448292 Commit-Ready: Zach Reizner <zachr@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Tested-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
* balloon: Implement device policyChirantan Ekbote2018-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devices: use PollContext for all virtio deivcesZach Reizner2018-04-05
| | | | | | | | | | | BUG=chromium:816692 TEST=run any VM Change-Id: I4219050fdb7947ca513f599f1ac57cde6052d397 Reviewed-on: https://chromium-review.googlesource.com/996917 Commit-Ready: Zach Reizner <zachr@chromium.org> Tested-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org>
* sys_util: use MADV_DONTDUMP for new mmapsZach Reizner2018-03-30
| | | | | | | | | | | | | | | | The mmaps made through the sys_util API are usually for guest memory or other large shared memory chunks that will pollute the file system with huge dumps on crash. By using MADV_DONTDUMP, we save the file system from storing these useless data segments when crosvm crashes. TEST=./build_test BUG=None Change-Id: I2041523648cd7c150bbdbfceef589f42d3f9c2b9 Reviewed-on: https://chromium-review.googlesource.com/890279 Commit-Ready: Zach Reizner <zachr@chromium.org> Tested-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org>
* sys_util: add ppoll to seccomp policiesZach Reizner2018-01-27
| | | | | | | | | | | | | | This really should have been added along with the poll timeout support, which changed the syscalls used in every jailed device. TEST=run crosvm with sandboxing enabled BUG=None Change-Id: I6129fa589640bb2b85fb4274775192bdd49db672 Reviewed-on: https://chromium-review.googlesource.com/890379 Commit-Ready: Zach Reizner <zachr@chromium.org> Tested-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org>
* devices: Add balloonDylan Reid2017-12-18
The balloon device is used to take regions of unused memory from the guest and allow other host processes to use that memory. Change-Id: I06c821365a58672d605fc7555beaec599cae1b15 Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/759306 Reviewed-by: Stephen Barber <smbarber@chromium.org>