[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b6d7326-fc74-288b-fa52-b79752222123@netronome.com>
Date: Wed, 21 Aug 2019 13:58:26 +0100
From: Quentin Monnet <quentin.monnet@...ronome.com>
To: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
oss-drivers@...ronome.com
Subject: Re: [PATCH bpf-next 2/2] tools: bpftool: add "bpftool map freeze"
subcommand
2019-08-21 13:40 UTC+0200 ~ Daniel Borkmann <daniel@...earbox.net>
> On 8/21/19 10:52 AM, Quentin Monnet wrote:
>> Add a new subcommand to freeze maps from user space.
>>
>> Signed-off-by: Quentin Monnet <quentin.monnet@...ronome.com>
>> Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
>> ---
>> .../bpf/bpftool/Documentation/bpftool-map.rst | 9 +++++
>> tools/bpf/bpftool/bash-completion/bpftool | 4 +--
>> tools/bpf/bpftool/map.c | 34 ++++++++++++++++++-
>> 3 files changed, 44 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst
>> b/tools/bpf/bpftool/Documentation/bpftool-map.rst
>> index 61d1d270eb5e..1c0f7146aab0 100644
>> --- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
>> +++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
>> @@ -36,6 +36,7 @@ MAP COMMANDS
>> | **bpftool** **map pop** *MAP*
>> | **bpftool** **map enqueue** *MAP* **value** *VALUE*
>> | **bpftool** **map dequeue** *MAP*
>> +| **bpftool** **map freeze** *MAP*
>> | **bpftool** **map help**
>> |
>> | *MAP* := { **id** *MAP_ID* | **pinned** *FILE* }
>> @@ -127,6 +128,14 @@ DESCRIPTION
>> **bpftool map dequeue** *MAP*
>> Dequeue and print **value** from the queue.
>> + **bpftool map freeze** *MAP*
>> + Freeze the map as read-only from user space. Entries from a
>> + frozen map can not longer be updated or deleted with the
>> + **bpf\ ()** system call. This operation is not reversible,
>> + and the map remains immutable from user space until its
>> + destruction. However, read and write permissions for BPF
>> + programs to the map remain unchanged.
>
> That is not correct, programs that are loaded into the system /after/
> the map
> has been frozen cannot modify values either, thus read-only from both
> sides.
>
> Thanks,
> Daniel
Hi Daniel,
Are you entirely sure about it? I could not find the relevant
restriction in the code, the checks seem to be on map flags
(BPF_F_RDONLY) which do not seem to be modified by the "frozen" status
in map_freeze()? And tests I ran on my side seem to indicate the map can
still be updated by new programs. Did I miss something?
Tested on 5.3.0-rc1:
1. Create hash map
2. Load BPF program foo, using map
3. Test-run program foo - map is updated
4. Freeze map - update effectively becomes impossible from user space
5. Load BPF program bar, using same map
6. Test-run program bar - map is still updated
Best regards,
Quentin
Powered by blists - more mailing lists