[CRIU] Checkpoint/Restore of BPF Map Data

[Abhishek Vijeev]

+ CRIU Mailing List


On Mon, Jun 22, 2020 at 10:29 PM Abhishek Vijeev
<abhishek.vijeev at gmail.com> wrote:
>
> Hi,
>
> I've been working with the CRIU project to enable CRIU to checkpoint
> and restore BPF map files.
> (https://github.com/checkpoint-restore/criu/issues/777).
>
> 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.