From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v3 4/5] kcmp: add KCMP_FILE_PRIVATE_DATA Date: Wed, 30 Sep 2015 11:56:25 -0700 Message-ID: References: <1443636820-17083-1-git-send-email-tycho.andersen@canonical.com> <1443636820-17083-5-git-send-email-tycho.andersen@canonical.com> <20150930184129.GB23065@smitten> <20150930185504.GC23065@smitten> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20150930185504.GC23065@smitten> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tycho Andersen Cc: Kees Cook , Alexei Starovoitov , Will Drewry , Oleg Nesterov , Pavel Emelyanov , "Serge E. Hallyn" , Daniel Borkmann , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Network Development , Linux API List-Id: linux-api@vger.kernel.org On Wed, Sep 30, 2015 at 11:55 AM, Tycho Andersen wrote: > On Wed, Sep 30, 2015 at 11:47:05AM -0700, Andy Lutomirski wrote: >> On Wed, Sep 30, 2015 at 11:41 AM, Tycho Andersen >> wrote: >> > On Wed, Sep 30, 2015 at 11:25:41AM -0700, Andy Lutomirski wrote: >> >> On Wed, Sep 30, 2015 at 11:13 AM, Tycho Andersen >> >> wrote: >> >> > This command allows comparing the underling private data of two fds. This >> >> > is useful e.g. to find out if a seccomp filter is inherited, since struct >> >> > seccomp_filter are unique across tasks and are the private_data seccomp >> >> > fds. >> >> >> >> This is very implementation-specific and may have nasty ABI >> >> consequences far outside seccomp. Let's do something specific to >> >> seccomp and/or eBPF. >> > >> > We could change the name to a less generic KCMP_SECCOMP_FD or >> > something, but without some sort of GUID on each struct >> > seccomp_filter, the implementation would be effectively the same as it >> > is today. Is that enough, or do we need a GUID? >> > >> >> I don't care about the GUID. I think we should name it >> KCMP_SECCOMP_FD and make it only work on seccomp fds. > > Ok, I can do that. > >> Alternatively, we could figure out why KCMP_FILE doesn't do the trick >> and consider fixing it. IMO it's really too bad that struct file is >> so heavyweight that we can't really just embed one in all kinds of >> structures. > > The problem is that KCMP_FILE compares the file objects themselves, > instead of the underlying data. If I ask for a seccomp fd for filter 0 > twice, I'll have two different file objects and they won't be equal. I > suppose we could add some special logic inside KCMP_FILE to compare > the underlying data in special cases (seccomp, ebpf, others?), but it > seems cleaner to have a separate command as you described above. > What I meant was that maybe we could get the two requests to actually produce the same struct file. But that could get very messy memory-wise. --Andy