Re: BPF memstore and bpf_validate_ext()

[Justin Cormack <justin%specialbusservice.com@localhost>]

On Fri, Dec 20, 2013 at 1:13 PM, Alexander Nasonov <alnsn%yandex.ru@localhost> 
wrote:
> Sorry for top-posting. I'm replying from my phone.
>
> I've not looked at linux bpf before. I remember taking a quick look at 
> bpf_jit_compile function but I didn't like emitting binary machine code with 
> macro commands.
>
> I spent few minutes today looking at linux code and I noticed few interesting 
> things:
>
> - They use negative offsets to access auxiliary data. So, there is a clear 
> distinction between local memory store and external data. I don't think it's 
> a new addition, though.
> - They have a big enum of commands. Many of them translate to bpf commands 
> but there are also special commands like load protocol number into A. There 
> is a decoder from bpf but I have no clue how it works.
> - Those commands are adapted to work with skbuf data.

I have used some of the "non traditional" uses of bpf in Linux, in
particularly the syscall filtering code, which is designed to be a bit
like the packet filtering code. But I don't think it is a great model,
and I think the jit compiler is rather different, as it compiles to
asm. And the current route they are going seems to be validation
rather than in kernel jitting, see https://lwn.net/Articles/575531/

Justin


> Alex
>
>
> 20.12.13, 04:16, "David Laight" <david%l8s.co.uk@localhost>":
>>
>> On Fri, Dec 20, 2013 at 01:28:12AM +0200, Mindaugas Rasiukevicius wrote:
>> > Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
>> > >
>> > > Well, if it wasn't needed for many year in bpf, why do we need it now? 
>> > > ;-)
>> > >
>> >
>> > Because it was decided to use BPF byte-code for more applications and that
>> > meant there is a need for improvements.  It is called evolution. :)
>>
>> Has anyone here looked closely at the changes linux is making to bpf?
>>
>>       David
>>
>> --
>> David Laight: david%l8s.co.uk@localhost
>
>
> --
> Alex