The helper function is deprecated. The package gvisor.dev/gvisor/pkg/rand
depends on crypto/rand which performs worse thatn math/rand, the changes
are fine since they are not at any gVisor's hot path.
The ultimate goal is to migrate math/rand to math/rand/v2.
When enabled with `AllowUDS`, unix domain sockets can be created in the sandbox
and bound on the host filesystem. The application can listen() and accept() on
these sockets as usual. Accept'ed sockets will be donated to the sandbox,
similar to how connect'ed sockets work.
In order to make notifications like poll work, the gofer donates the host-bound
socket FD to the sandbox, but the seccomp filters will (correctly) prevent the
sandbox from calling listen and accept directly on that FD. Instead, listen and
accept calls must go through the gofer. The donated host FD can should only be
used to poll for new incoming connectins.
Note that I changed the order of some of the Lisa RPCs in order to group Bind
with the existing similar Connect method. This changes the RPC numbers in a
backwards-incompatible way, but since nobody is using Lisa yet we are OK. It's
better to make these cleanup changes now before we have users and are locked
in.
PiperOrigin-RevId: 447236441
Since refsvfs2 are used in netstack, we should use atomicbitops to avoid
breaking 32-bit builds.
On 64-bit builds there is no performance difference.
PiperOrigin-RevId: 439687980
This is very similar to p9 in design and helps address all the discussed
security concerns around the old lisafs design.
In p9, the path tree grows unbounded. Once a path is walked, those path nodes
exist for the lifetime of the server. That hurts memory performance and usage.
Additionally, nodes are allocated separately from FidRefs which are allocated
separately from Files. Each path node also has 3 hashmaps tracking various
things. This leads to a LOT of allocations.
In lisafs, we cut down almost all the additional allocations. Nodes have a
bounded lifetime. Once all refs on node are dropped, the node is removed from
the filesystem tree. In the overwhelming common case, where the client is not
compromised and is behaving correctly (gofer client in sentry), the lifecycle
of the ControlFD and Node are equivalent. So lisafs allocates them together.
lisafs also only uses 1 hashmap in each node to track children. This too has
been optimized. Experimentation showed that majority of directories have at
most 3 children to track. So we only allocate the hashmap once we hit 4
children. Before that, we statically track 3 children using hardcoded pointers.
Tested: All 221 syscall tests pass with lisafs.
PiperOrigin-RevId: 424933787
Introduces RPC methods in lisafs. Makes that gofer client use lisafs RPCs
instead of p9 when lisafs is enabled.
Implements the handlers for those methods in fsgofer.
Fixes#5465
PiperOrigin-RevId: 398080310
This change mainly aims to define the semantics of communication for the LISAFS
(LInux SAndbox Filesystem) protocol. This protocol aims to replace 9P and
intends to bring some performance benefits with it.
Some of the notable differences from the p9 package are:
- Now the server implementations own the handlers.
- As a result, there is no verbose interface like `p9.File` that all servers
need to implement. Different implementations can extend their File
implementations to varying degrees without imposing those extensions to other
server implementations that might not have anything to do with those features.
- If a server implementation adds a new RPC message, other implementations are
not compelled to support it.
I wrote a benchmark `BenchmarkSendRecv` in connection_test.go which competes
with p9's `BenchmarkSendRecvChannel`. Running these on an AMD Milan machine
shows that lisafs is **45%** faster.
**With 9P**
goos: linux
goarch: amd64
pkg: gvisor/pkg/p9/p9
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecvLegacy-256 82830 14053 ns/op 633 B/op 23 allocs/op
BenchmarkSendRecvChannel-256 776971 1551 ns/op 184 B/op 6 allocs/op
**With lisafs**
goos: linux
goarch: amd64
pkg: pkg/lisafs/connection_test
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecv-256 1399610 853.5 ns/op 48 B/op 2 allocs/op
Fixes#5464
PiperOrigin-RevId: 397803163
Jing Chen
Adin ScannellandgVisor bot
Ayush RanjanandgVisor bot
Nicolas LacasseandgVisor bot
Kevin KrakauerandgVisor bot