Age | Commit message (Collapse) | Author |
|
|
|
This change validates incoming NDP Router Advertisements as per RFC 4861 section
6.1.2. It also includes the skeleton to handle Router Advertiements that arrive
on some NIC.
Tests: Unittest to make sure only valid NDP Router Advertisements are received/
not dropped.
PiperOrigin-RevId: 278891972
|
|
|
|
PiperOrigin-RevId: 278739427
|
|
|
|
This fixes a number of issues with the repository build process:
* Fix the overall structure of the repository.
* Fix the debian package description.
* Fix the broken version number for packages.
* Update the digest algorithm used for signing the release.
I've validated that installation works from a separate staging bucket.
Updates #852
PiperOrigin-RevId: 278716914
|
|
|
|
We don't know how stable they are, so let's start with warning.
PiperOrigin-RevId: 278484186
|
|
|
|
PiperOrigin-RevId: 278424814
|
|
|
|
It was possible to panic the sentry by opening a cache revalidating folder with
O_TRUNC|O_CREAT.
PiperOrigin-RevId: 278417533
|
|
|
|
NETLINK_KOBJECT_UEVENT sockets send udev-style messages for device events.
gVisor doesn't have any device events, so our sockets don't need to do anything
once created.
systemd's device manager needs to be able to create one of these sockets. It
also wants to install a BPF filter on the socket. Since we'll never send any
messages, the filter would never be invoked, thus we just fake it out.
Fixes #1117
Updates #1119
PiperOrigin-RevId: 278405893
|
|
|
|
Updates #267
PiperOrigin-RevId: 278402684
|
|
|
|
PiperOrigin-RevId: 278032567
|
|
|
|
Since we only supporting sending messages from the kernel, the peer is always
the kernel, simplifying handling.
There are currently no known users of SO_PASSCRED that would actually receive
messages from gVisor, but adding full support is barely more work than stubbing
out fake support.
Updates #1117
Fixes #1119
PiperOrigin-RevId: 277981465
|
|
|
|
PiperOrigin-RevId: 277971910
|
|
|
|
The watchdog currently can find stuck tasks, but has no way to tell if the
sandbox is stuck before the application starts executing.
This CL adds a startup timeout and action to the watchdog. If Start() is not
called before the given timeout (if non-zero), then the watchdog will take the
action.
PiperOrigin-RevId: 277970577
|
|
|
|
This gets quite spammy, especially in tests.
PiperOrigin-RevId: 277970468
|
|
|
|
PiperOrigin-RevId: 277965624
|
|
|
|
PiperOrigin-RevId: 277840416
|
|
|
|
Adds a systemd-cgroup flag option that prints an error letting the user know
that systemd cgroups are not supported and points them to the relevant issue.
Issue #193
PiperOrigin-RevId: 277837162
|
|
|
|
Also, construct the README directly so that edits can be made.
PiperOrigin-RevId: 277782095
|
|
|
|
sigtimedwait is used to check pending signals and
it should not block.
PiperOrigin-RevId: 277777269
|
|
|
|
Turns out we use $RUNTIME in scripts/common.sh to give a name to the runsc
runtime used by the tests.
PiperOrigin-RevId: 277764383
|
|
PiperOrigin-RevId: 277623766
|
|
|
|
When VectorisedViews were passed up the stack from packet_dispatchers, we were
passing a sub-slice of the dispatcher's views fields. The dispatchers then
immediately set those views to nil.
This wasn't caught before because every implementer copied the data in these
views before returning.
PiperOrigin-RevId: 277615351
|
|
|
|
PiperOrigin-RevId: 277607217
|
|
|
|
On Arm platform, "setMemoryRegion" has extra permission checks.
In virt/kvm/arm/mmu.c: kvm_arch_prepare_memory_region()
....
if (writable && !(vma->vm_flags & VM_WRITE)) {
ret = -EPERM;
break;
}
....
So, for Arm platform, the "flags" for kvm_memory_region is required.
And on x86 platform, the "flags" can be always set as '0'.
Signed-off-by: Bin Lu <bin.lu@arm.com>
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/810 from lubinszARM:pr_setregion 8c99b19cfb0c859c6630a1cfff951db65fcf87ac
PiperOrigin-RevId: 277602603
|
|
|
|
Sandbox root dir was not being saved with the Container state,
so it would point to the wrong directory location when attempting
to lock the sandbox. This led to race conditions saving and
loading container state. Fixing it, led to multiple deadlocks.
I've moved the saving and locking logic to a separate struct and
moved the lock file inside the RootDir (instead of container
root dir), which allows the lock to be taken inside Destroy,
and removes the need to lock the sandbox.
PiperOrigin-RevId: 277599612
|
|
|
|
It is required to guarantee the same order of endpoints after save/restore.
PiperOrigin-RevId: 277598665
|
|
|