netdev - [PATCH RFC bpf-next 0/3] bpf: Improve verifier coverage on sparc64 et al.

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>] [day] [month] [year] [list]

Date:   Wed, 28 Nov 2018 23:41:06 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     daniel@...earbox.net
CC:     ast@...nel.org, netdev@...r.kernel.org
Subject: [PATCH RFC bpf-next 0/3] bpf: Improve verifier coverage on sparc64
 et al.

On sparc64 a ton of test cases in test_verifier.c fail because
the memory accesses in the test case are unaligned (or cannot
be proven to be aligned by the verifier).

Perhaps we can eventually try to (carefully) modify each one
with this problem to not use unaligned accesses but:

1) That is delicate work.

2) The changes might not fully respect the original
   intention of the testcase.

3) In some cases, such a transformation might not even
   be feasible at all.

So add an "any alignment" flags to tell the verifier to forcefully
disable it's alignment checks completely.

test_verifier.c is then annotated to use this flag when necessary.

The presence of the flag in each test case is good documentation
to anyone who wants to actually tackling the job of eliminating
the unaligned memory accesses in the test cases.

I've also seen several weird things in test cases, like trying to
access __skb->mark in a packet buffer.

A couple of unresolves issues, in my opinion:

1) Maybe make this privileged, or at least prevent executing programs
   that have had the 'any alignment' flag passed to the verifier when
   we are on an inefficient unaligned access cpu.

2) Since we don't actually execute the "ACCEPT" cases (only enforced
   in the test_verifier.c code, see #1) maybe we should report them
   in some special way so that this is clear in the output.

This gets rid of 104 test_verifier.c failures on sparc64.

Signed-off-by: David S. Miller <davem@...emloft.net>