netdev - remaining sparc bpf hacks...

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:   Tue, 02 May 2017 12:04:23 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ast@...com
CC:     daniel@...earbox.net, netdev@...r.kernel.org
Subject: remaining sparc bpf hacks...

So I just have two issues remaining for test_progs to run properly
on sparc.  We've discussed them before.

The first is the clang Makefile hack:

diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index d8d94b9..2ed63b6 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -35,5 +35,5 @@ CLANG ?= clang

 %.o: %.c
 	$(CLANG) -I../../../include/uapi -I../../../../samples/bpf/ \
-		-D__x86_64__ -Wno-compare-distinct-pointer-types \
+		-D__sparc__ -Wno-compare-distinct-pointer-types \
 		-O2 -target bpf -c $< -o $@

which should be reasonably easy to deal with.

The second is more difficult:

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index c2ff608..bb99677 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -801,8 +801,12 @@ static int check_ptr_alignment(const struct bpf_reg_state *reg,
 {
 	switch (reg->type) {
 	case PTR_TO_PACKET:
+#if 1
+		return 0;
+#else
 		return IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) ? 0 :
 		       check_pkt_ptr_alignment(reg, off, size);
+#endif
 	case PTR_TO_MAP_VALUE_ADJ:
 		return IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) ? 0 :
 		       check_val_ptr_alignment(reg, size);

Studying over the verifier yesterday I figure we can add an
"alignment" attribute to registers, and track this.

The packet pointer entering a function starts with a weird "modulo
NET_IP_ALIGN" relative alignment, so we have to take that into
consideration.

Then for operations like shift left and multiply by constants, we can
record a known minimum alignment.  The most common case is, of course,
"iph->ihl << 2"

And later when registers with known alignment are added to a packet
pointer, we can constrain the alignment of the destination register.