[PATCH RFC v2 1/3] Introduce seccomp-assisted syscall filtering

[Paul Chaignon]

On Tue, Aug 13, 2019 at 01:00:47PM +0200, Eugene Syromiatnikov wrote:
> On Tue, Aug 13, 2019 at 10:26:33AM +0200, Paul Chaignon wrote:
> > On Mon, Aug 12, 2019 at 5:18 PM Paul Chaignon <paul.chaignon at gmail.com> wrote:
> > > On Mon, Aug 12, 2019 at 02:28:00PM +0200, Eugene Syromiatnikov wrote:
> > > > On Wed, Aug 07, 2019 at 06:03:38PM +0200, Paul Chaignon wrote:
> > > > > On Mon, Aug 05, 2019 at 07:59:25PM +0200, Eugene Syromiatnikov wrote:
> > > > > > On Wed, Jul 31, 2019 at 05:35:56PM +0200, Paul Chaignon wrote:
> > 
> > [...]
> > 
> > > > > > There's already some code which does nearly the same job,
> > > > > > bpf_filter.c:print_bpf_filter_block(), I wonder if it can be re-used.
> > > > >
> > > > > We could even reuse print_bpf_fprog() I think.  I'm not sure how to do
> > > > > that though as we'll need to output to stderr instead of current_tcp.  We
> > > > > could create a fake current_tcp, but that sounds very hacky...  Any other
> > > > > idea?
> > > >
> > > > The common approach is print to string in the intermal functions and
> > > > just have different top-level wrappers.
> > >
> > > I thought that would be too heavy a change.  I'll do that.
> > 
> > Wait, that *is* too heavy a change.  The print_bpf_filter_xxx functions
> > call tprints, tprintf, and printxval.  I can replace tprints and tprintf
> > with print to string functions, but printxval is a bit more involved.  I'd
> > have to make a number of changes in defs.h plus rewrite printxvals_ex in
> > xlat.c.
> > 
> > Then, to print to a string, I'd have to either allocate a buffer once and
> > for all and correctly guess the maximum required size, which seems error
> > prone, or reallocate the buffer as I'm printing into it...
> > 
> > Would all these changes be okay?  Are they worth it?  Is there a simpler
> > way I missed?
> 
> I don't think it is _needed_ at this stage, more like "a good to have";
> it's a debug output, which we already have duplicating elsewhere anyway
> (like ptrace-related debug printing).  And I have to check, but in some
> cases sprintxval_ex is enough (and multiple-xlat cases can be worked around
> to some extent).

Ok, I'll leave that to a later patch.  I'd really like to merge the first
patchset before end of summer.

Paul