netdev - Re: [PATCH net-next] net: filter: constify detection of pkt_type

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]

Message-ID: <5412D113.6000700@redhat.com>
Date:	Fri, 12 Sep 2014 12:55:15 +0200
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
	Markos Chandras <markos.chandras@...tec.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Denis Kirjanov <kda@...ux-powerpc.org>
Subject: Re: [PATCH net-next] net: filter: constify detection of pkt_type_offset

On 09/12/2014 12:22 PM, Hannes Frederic Sowa wrote:
> Currently we have 2 pkt_type_offset functions doing the same thing and
> spread across the architecture files. Remove those and replace them
> with a PKT_TYPE_OFFSET macro helper which gets the constant value from a
> zero sized sk_buff member right in front of the bitfield with offsetof.
> This new offset marker does not change size of struct sk_buff.
>
> Cc: Eric Dumazet <eric.dumazet@...il.com>
> Cc: Markos Chandras <markos.chandras@...tec.com>
> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>
> Cc: Daniel Borkmann <dborkman@...hat.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>
> Signed-off-by: Denis Kirjanov <kda@...ux-powerpc.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

Thanks for doing this, Hannes!
...
>   static u64 __skb_get_pay_offset(u64 ctx, u64 a, u64 x, u64 r4, u64 r5)
>   {
>   	return skb_get_poff((struct sk_buff *)(unsigned long) ctx);
> @@ -191,7 +167,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
>
>   	case SKF_AD_OFF + SKF_AD_PKTTYPE:
>   		*insn = BPF_LDX_MEM(BPF_B, BPF_REG_A, BPF_REG_CTX,
> -				    pkt_type_offset());
> +				    PKT_TYPE_OFFSET());
>   		if (insn->off < 0)
>   			return false;
>   		insn++;

I think this can now be rewritten as ...

	case SKF_AD_OFF + SKF_AD_PKTTYPE:
		*insn++ = BPF_LDX_MEM(BPF_B, BPF_REG_A, BPF_REG_CTX,
				      PKT_TYPE_OFFSET());
		*insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX);

... since we are guaranteed to have always >0 insn->off and despite the
__s16 type in off we might be able to safely assume that sk_buff will
never get extended so far w/o fist fights first, where this could wrap
around. ;) Alternatively, perhaps a BUILD_BUG_ON() for really being
paranoid?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html