netdev - Re: [PATCH RFC 0/3] intermediate representation for jit and cls

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:	Fri, 26 Feb 2016 12:26:57 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	pablo@...filter.org
Cc:	john.fastabend@...il.com, netdev@...r.kernel.org, jiri@...nulli.us,
	horms@...ge.net.au
Subject: Re: [PATCH RFC 0/3] intermediate representation for jit and
 cls_u32 conversion

From: Pablo Neira Ayuso <pablo@...filter.org>
Date: Fri, 26 Feb 2016 12:47:14 +0100

> The frontend parser should be generic to everyone, it should be
> placed in the core, so everyone will take care of improving it.

Generic unfortunately means information loss and lots of wasted work.

And this is one of John's points I think.

If we have an existing abstraction that fits directly into what the
hardware can do, such as the u32 classifiers, translating this back
and forth into an intermediate representation is going to be at best
wasted work and sometimes missing cases that can be loaded into hardware.

I really see zero value in "generic" intermediate languages for this
kind of stuff.

I don't want to have to translate a set of u32 rules into some other
format if u32 is what lots of hardware can do directly already.

Pablo, you're coming at the from another angle, you're starting from
the perspective of nftables which has this nice abstraction and IR.
But no hardware directly offloads nftables IR.  So as an offload
strategy nftables needs this IR to hardware translation layer.

But u32 and others absolutely will not, and we should not force them
to.