linux-kernel - Re: [RFC PATCH v4 17/29] bpf tools: Relocate eBPF programs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <556BFD61.6090306@huawei.com>
Date:	Mon, 1 Jun 2015 14:36:17 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Namhyung Kim <namhyung@...nel.org>
CC:	<paulus@...ba.org>, <a.p.zijlstra@...llo.nl>, <mingo@...hat.com>,
	<acme@...nel.org>, <jolsa@...nel.org>, <dsahern@...il.com>,
	<daniel@...earbox.net>, <brendan.d.gregg@...il.com>,
	<masami.hiramatsu.pt@...achi.com>, <lizefan@...wei.com>,
	<linux-kernel@...r.kernel.org>, <pi3orama@....com>
Subject: Re: [RFC PATCH v4 17/29] bpf tools: Relocate eBPF programs

On 2015/6/1 13:32, Namhyung Kim wrote:
> On Wed, May 27, 2015 at 05:19:52AM +0000, Wang Nan wrote:
>> If an eBPF program access a map, LLVM generates a relocated load
>> instruction. To enable the usage of that map, relocation must be done
>> by replacing original instructions by map loading instructions.
>>
>> Based on relocation description collected during 'opening' phase, this
>> patch replaces the instructions with map loading with correct map fd.
> I think this message is a bit confusing.. How about this?
>
> If an eBPF program accesses a map, LLVM generates a load instruction
> with pseudo map fd.  Since actual map fd can only be known after it

LLVM doesn't generate mapfd. It creates an instruction read a global
structure. something link this:

   ld_64   r1, <MCOperand Expr:(mymap)>
   ...
   call    2

where ld_64 is a (BPF_LD | BPF_IMM | BPF_DW) instruction, src_reg is not
used at all.

What this relocation done is to utilize src_reg, set it to BPF_PSEUDO_MAP_FD
then set the imm field to the fd of the map.

I will update the commit message as follow:

If an eBPF program accesses a map, LLVM generates a load instruction
which loads an absolute address into a register, like this:

   ld_64   r1, <MCOperand Expr:(mymap)>
   ...
   call    2

That ld_64 instruction will be recorded in relocation section.
To enable the usage of that map, relocation must be done by replacing
the immediate value by real map file descriptor so it can be found by
eBPF map functions.

This patch to the relocation work based on information collected by
patch 'bpf tools: Collect relocation sections from SHT_REL sections'.
For each instruction which needs relocation, it inject corresponding
file descriptor to imm field. As a part of protocol, src_reg is set to
BPF_PSEUDO_MAP_FD to notify kernel this is a map loading instruction.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/