Re: [PATCH bpf-next 2/2] tools: bpftool: add "bpftool map freeze" subcommand

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/21/19 2:58 PM, Quentin Monnet wrote:
2019-08-21 13:40 UTC+0200 ~ Daniel Borkmann <daniel@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Reviewed-by: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
---
   .../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.

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

Looks like I need some more coffee. ;-) Indeed, the program side was via
BPF_F_RDONLY_PROG flag.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux