On Mon, Dec 12, 2022 at 8:11 AM Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2022-11-07 at 13:11 +0100, Roberto Sassu wrote: > > [...] > > > > > > P.S. We can extend this to BPF-side BPF_F_RDONLY_PROG | > > > > > BPF_F_WRONLY_PROG as well, it's just that we'll need to define how > > > > > user will control that. E.g., FS read-only permission, does it > > > > > restrict both user-space and BPF-view, or just user-space view? We can > > > > > certainly extend file_flags to allow users to get BPF-side read-only > > > > > and user-space-side read-write BPF map FD, for example. Obviously, BPF > > > > > verifier would need to know about struct bpf_map_view when accepting > > > > > BPF map FD in ldimm64 and such. > > > > > > > > I guess, this patch could be used: > > > > > > > > https://lore.kernel.org/bpf/20220926154430.1552800-3-roberto.sassu@xxxxxxxxxxxxxxx/ > > > > > > > > When passing a fd to an eBPF program, the permissions of the user space > > > > side cannot exceed those defined from eBPF program side. > > > > > > Don't know, maybe. But I can see how BPF-side can be declared r/w for > > > BPF programs, while user-space should be restricted to read-only. I'm > > > a bit hesitant to artificially couple both together. > > > > Ok. At least what I would do is to forbid write, if you provide a read- > > only fd. > > Ok, we didn't do too much progress for a while. I would like to resume > the discussion. > > Can we start from the first point Lorenz mentioned? Given a read-only > map fd, it is not possible to write to the map. Can we make sure that > this properly work? > > In my opinion, to achieve this particular goal, the map view > abstraction Andrii suggested, should not be necessary. What do you 'not necessary' ? afair the map view abstraction is only one that actually addresses all the issues.
