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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Feb 2016 07:35:51 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <daniel@...earbox.net>, davem@...emloft.net
Cc:	netdev@...r.kernel.org, xiyou.wangcong@...il.com,
	alexei.starovoitov@...il.com
Subject: Re: [net-next PATCH 0/5] net_sched: Add support for IFE action

On 16-02-24 12:58 PM, Daniel Borkmann wrote:
> On 02/24/2016 01:49 PM, Jamal Hadi Salim wrote:

>> Yes, a bit of that ++.
>> I am between two worlds: There are people who do user space packet
>> processing that claim they do so because they can quickly prototype
>> without compiling the kernel. My goal is to make it easy for people
>> adding new metadata without having to deal with kernel recompile.
>
> Seems like a case for cls_bpf? ;)
>

Yes, and ebpf is a good answer in a few such discussions these days.

>
> Ok, sure, given the assumption that this is only to be used in your own
> fully _controlled_ environment anyway.

It is - typically in the same rack; but could be across to another
room.


> But in that case, you don't even
> need to define any fixed IDs. Currently it seems like you could have
> different kernel versions with different IFE_META_MAX from the kernel
> headers and external modules define part of the ID space differently?
>

That is part of the problem.
Dynamic registration is not going to work well without some
human supervision. We are talking about large number of endpoints.
One machine cannot guarantee to be interested in the same metadata
as others and as you say they could be different kernels etc.
Even within same organization across different groups would require
some  coordination.

I will take that module param out and maybe describe a set of IDs that
are for "private use" and let whoever is deploying worry about
coordination. For the rest i will just have some LANANA or IANA
or kernel maintainance issues them. I should declare all the obvious
kernel ones.

cheers,
jamal

Powered by blists - more mailing lists