linux-kernel - Re: ktap and ebpf integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Apr 2014 09:48:00 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jovi Zhangwei <jovi.zhangwei@...il.com>
Cc:	Alexei Starovoitov <ast@...mgrid.com>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: ktap and ebpf integration


* Jovi Zhangwei <jovi.zhangwei@...il.com> wrote:

> On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov <ast@...mgrid.com> wrote:
> > On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei <jovi.zhangwei@...il.com> wrote:
> >> Hi Alexei,
> >>
> >> We talked a lot on ktap and ebpf integration in these days,
> >> Now I think we can put into deeply to thinking out some
> >> technical issues in there.
> >>
> >> Firstly, I want to make sure you are support this ktap and
> >> ebpf integration direction, I aware you have ongoing 'bpf filter'
> >> patch set work, which actually overlapping with ktap integration
> >> efforts (IMO the interface should be unified and simple for user,
> >>  so I think filter debugfs file is not a good interface), so please let
> >> me know your answer about this.
> >
> > I think the more choices users have the better.
> > I'll continue with C based filters and you can continue with ktap
> > syntax. That's ok. We can share all kernel pieces.
> 
> Now I understand that there is no way to integrate ktap and ibpf in 
> technical point of view, the kernel side and interface is completely 
> different, and obviously you don't want to change current per-event 
> filter file based interface and kernel part, that make impossible to 
> let ktap could integrate or share with ibpf.

In my reading that's not what Alexei wrote: he just suggested that as 
long as the kernel bits are largely shared, the user-space bits 
(syntax, etc.) can stay completely orthogonal and independent.

It also does not mean that ktap is forced to use the per event filter 
file based interface to pass BPF scripts to the kernel. BPF is already 
used by various facilities in the kernel, with different user-space 
APIs to interface with it.

So the main technical question is: why should ktap have its own 
separate in-kernel code execution engine, if we already have the BPF 
virtual machine (which is well-maintained, has excellent performance 
through JIT, etc.), which could be reused and/or enhanced?

Is there any aspect of ktap's virtual machine that BPF does not have?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/