eBPF store APIs read and write separate keys from user and kernel mode about ebpf-for-windows

[shankarseal]

This looks like related to #2382. @saxena-anurag , is this by design?

[saxena-anurag]

Yes this is by design and is same as #2382. Ideally we need to populate the eBPF store only for offline verification, i.e. for the cases where the extension is not expected to be running. So ideally extensions can skip populating the store if a UM tool is also doing the same and is part of the installation script / MSI.

[mtfriesen]

How can this be by design? If I understand correctly, the kernel mode store APIs are provided as a static lib (i.e, unserviceable) and the registry keys being written are a black hole. Wouldn't it be equivalent to not provide the kernel APIs at all?

[mtfriesen]

Note the documentation describes this API as having an effect on the "eBPF store" when in fact there are two disjoint eBPF stores.

[saxena-anurag]

The only consumer of ebpf store is UM and it tries to get information from the other path if the first is not available. So the store should still be transparent to components writing to it.

Just to give a bit more detail on why 2 stores -- currently ebpf store needs to be populated as part of eBPF build, and updating HKLM requires admin privileges. That will mean a dev needs to run build step as admin, which is not desired.

[dthaler]

This is related to #1231

[dahavey]

Duplicate of #1231