[CRIU] Checkpoint/Restore of BPF Map Data

[Abhishek Vijeev]

Hi,

I've been working with the CRIU project to enable CRIU to checkpoint and
restore BPF map files.

A key component of the solution involves dumping the data contained in BPF
maps. However, I have
been unable to do this due to the following reason - as far as I'm aware,
Linux does not provide an
interface to directly retrieve the key-value pairs stored in a BPF map
without prior knowledge about
the nature of data stored in it. To explain what I mean by 'without prior
information about the data
stored', let's take the example of a BPF map that stores key-value pairs in
the form of a hash table
(BPF_MAP_TYPE_HASH). The only way to iterate through all the key-value
pairs in this map is to use
BPF_MAP_GET_NEXT_KEY. However, if I start with a lookup key that exists in
the map, I will only be
able to iterate through the key-value pairs that occur after this key.
Therefore, I must start with
a lookup key that does not already exist in the map, so that
BPF_MAP_GET_NEXT_KEY returns the
map's first key. However, information about the nature of data stored in
the map is only available to
the application programmer, and it will hence be difficult for CRIU to
guess a key that does not exist
in the map.

I would therefore like to discuss the possibility of extending Linux's BPF
API to provide easier
access to the data contained in BPF maps, in a manner that works for all
types of maps and is
potentially future-proof for other kinds of maps that may be added.

As I currently understand, this problem stems from the fact that reading
and writing to a BPF map's
kernel buffer is only possible using the BPF system call. Therefore,
functionality that allows
reading from and writing to the map in a manner that is agnostic to the
nature of data stored in it
(similar to tee and splice for pipes) would enable checkpointing and
restoring BPF map data.

Do let me know if anything I have written is factually incorrect and also
if there is something I
can explain more clearly.

I look forward to hearing the kernel community's thoughts on this.

Thank you,
Abhishek Vijeev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20200622/794e7f1a/attachment.html>