On Mon, May 18, 2020 at 02:45:00PM +0200, Christian Brauner wrote: > On Mon, May 18, 2020 at 08:32:25AM +0000, Sargun Dhillon wrote: > > On Sun, May 17, 2020 at 02:30:57PM -0700, Kees Cook wrote: > > > On Sun, May 17, 2020 at 09:02:15AM -0600, Tycho Andersen wrote: > > > > > > I'm going read this thread more carefully tomorrow, but I just wanted to > > > mention that I'd *like* to extend seccomp_data for doing deep argument > > > inspection of the new syscalls. I think it's the least bad of many > > > designs, and I'll write that up in more detail. (I would *really* like > > > to avoid extending seccomp's BPF language, and instead allow probing > > > into the struct copied from userspace, etc.) > > > > > > Anyway, it's very related to this, so, yeah, probably we need a v2 of the > > > notif API, but I'll try to get all the ideas here collected in one place. > > I scratched together a proposal of what I think would make a not-terrible > > V2 API. I'm sure there's bugs in this code, but I think it's workable -- > > or at least a place to start. The biggest thing I think we should consider > > is unrolling seccomp_data if we don't intend to add new BPF-accessible > > fields. > > > > If also uses read(2), so we get to take advantage of read(2)'s ability > > to pass a size along with the read, as opposed to doing ioctl tricks. > > It also makes programming from against it slightly simpler. I can imagine > > that the send API could be similar, in that it could support write, and > > thus making it 100% usable from Go (and the like) without requiring > > a separate OS-thread be spun up to interact with the listener. > > I don't have strong feelings about using read() and write() here but I > think that Jann had reservations and that's why we didn't do it in the > first version. But his reservations were specifically tied to fd passing > which we never implemented: > http://lkml.iu.edu/hypermail/linux/kernel/1806.2/05995.html > > But still, worth considering. There was a thread about this same time for some other API (I can't find it now, but I can dig if you want) that suggests that "read() is for data" and we shouldn't use it for control in APIs. Tycho
