netdev - Re: [PATCH net] net: filter: initialize A and X registers

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:	Wed, 23 Apr 2014 09:13:55 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Daniel Borkmann <dborkman@...hat.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: filter: initialize A and X registers

On Wed, Apr 23, 2014 at 12:53 AM, Daniel Borkmann <dborkman@...hat.com> wrote:
> On 04/23/2014 05:18 AM, Alexei Starovoitov wrote:
>>
>> exisiting BPF verifier allows uninitialized access to registers,
>> 'ret A' is considered to be a valid filter.
>> So initialize A and X to zero to prevent leaking kernel memory
>> In the future BPF verifier will be rejecting such filters
>>
>> Signed-off-by: Alexei Starovoitov <ast@...mgrid.com>
>> Cc: Daniel Borkmann <dborkman@...hat.com>
>
>
> I gave it some more thought, it's actually more than just 'ret A'
> from your description, user programs could be used to generate code
> like 'add X' or 'add #42' instead of a txa or load instruction [where
> A is previously uninitialized], as it was always initialized to 0
> before. We prevent to do a 'ret X', but X could be uninitialized and
> then transferred over to taint A etc. So yeah, this patch is the most
> simple way to prevent that w/o huge complexity. Therefore, it's
> better this way:
>
> Acked-by: Daniel Borkmann <dborkman@...hat.com>

Thanks.

the uninitialized checking is indeed not as simple as rejecting 'ret A'.
verifier needs to consider data flow between registers based
on control graph. Just linear scan won't be correct.
Also for ebpf there are 10+1 registers to consider, so ebpf verifier
will take care of both (classic and extended) at once.
classic verifier can stay as-is and eventually removed.
For example after 'bpf_call' insn the registers r1-r5 are scratched,
so they cannot be read, r10 is frame pointer and is read only, etc.
will prepare ebpf verifier patch asap.
the steps will be:
- classic verifier (as-is today)
- bpf->ebpf converter (as-is today)
- ebpf verifier
after insane amount of testing we will be able to remove classic verifier,
since ebpf verifier will be doing it more thorough.
--
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