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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 7 Apr 2019 20:35:08 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
        joe@...d.net.nz, yhs@...com, andrii.nakryiko@...il.com,
        kafai@...com
Subject: Re: [PATCH bpf-next v4 01/16] bpf: implement lookup-free direct value
 access for maps

On 04/07/2019 04:57 AM, Alexei Starovoitov wrote:
[...]
> I don't get this shadow vs normal .data idea.
> The more we talk the more I'm convinced that this is not a good api.
> Say in the future we indeed have these shadow + normal .data
> then just use the same insn->imm field to refer to shadow part.
> Even if there are N such regions. The value_size is known.
> So use 0<=imm<value_size to refer to 'index' 0 and
> value_size<=imm<value_size*2 to refer to 'index' 1.
> There is absolutely no need for offset and index to be separate.
> Address of a byte inside bpf array can be expressed with single integer.

Hmm, fair enough, I guess it also always boils down to the same, that
is, discussing such facility once the need comes up and given neither
of us would have a need right now, I'll just respin on Monday morning
with the index bit removed as I had it originally. Lets extend it only
upon need, probably good we discussed it through. :-)

Thanks,
Daniel

Powered by blists - more mailing lists