netdev - Re: [RFC bpf-next 1/7] bpf: interpreter support BPF_ALU

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:   Tue, 4 Dec 2018 11:29:55 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     jiong.wang@...ronome.com, daniel@...earbox.net, ast@...nel.org,
        netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [RFC bpf-next 1/7] bpf: interpreter support BPF_ALU | BPF_ARSH

On Tue, Dec 04, 2018 at 08:43:11AM -0800, David Miller wrote:
> From: Jiong Wang <jiong.wang@...ronome.com>
> Date: Tue,  4 Dec 2018 04:56:29 -0500
> 
> > This patch implements interpreting BPF_ALU | BPF_ARSH. Do arithmetic right
> > shift on low 32-bit sub-register, and zero the high 32 bits.
> > 
> > Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> > Signed-off-by: Jiong Wang <jiong.wang@...ronome.com>
> 
> I just want to say that this behavior is interesting because on most
> cpus that have a 32-bit and 64-bit variant, the 32-bit arithmetic
> right shift typically sign extends to 64-bit rather than zero extends
> which is what is being defined here.
> 
> Well, definitely, sparc64 behaves this way.

interesting. I think on x64 and arm64 any arithemtic operation on 32-bit
subregister zero extends upper 32-bits. I wonder why sparc went with
sign-extend. I guess sparc doesn't really have 32 subregisters.
All registers are considered 64-bit. It has 32-bit alu ops on 64-bit
registers instead.

Regarding the set... It looks good to me. Pls resubmit without RFC tag
and probably include mips patch as patch 1, so we can apply the whole
thing to bpf-next. git will take care of same patch being in two trees.