Update store APIs to also update HKLM

[saxena-anurag]

Description

Issue:
When using libbpf APIs for attaching eBPF programs, the app / service needs to provide bpf_attach_type enum. ebpfapi.dll uses eBPF store to convert this enum to ebpf attach type guid. We recently took a change where we stopped populating eBPF store entries in HKLM, and they are now only updated in HKCU. That caused a regression and breaks any app / service that is running as LOCAL_SYSTEM.

Fix:
To mitigate the regressions, only in 0.17 release, update the store APIs to also attempt to update / delete / read from HKLM. If the update or delete operation fails due to ACCESS_DENIED, that error is absorbed, as the app may not be running as admin.

Testing

Existing tests.

Documentation

No.

Installation

Is there any installer impact for this change?

[mtfriesen]

Documentation
No.

I realize this PR is only for release/0.17, but as an extension developer it is not clear which extension components are supposed to call the store APIs, when they are supposed to be called, and what the expected effects are. Please update the documentation to clearly define:

1. When extension drivers should call the API, if at all, and what the expected effects are. Similarly, the effects of drivers registering their program and hook attributes through NMR, and which scenarios that unblocks.
2. When extensions should register with the user mode store API, and what the effects are. For example, should extension installers typically register with the store API, or if the store affects only HKCU, who is responsible for registering and deregistering with the APIs?

See microsoft/xdp-for-windows#519, for example, where the expected behavior and effects are ambiguous.

[saxena-anurag]

Documentation
No.

I realize this PR is only for release/0.17, but as an extension developer it is not clear which extension components are supposed to call the store APIs, when they are supposed to be called, and what the expected effects are. Please update the documentation to clearly define:

1. When extension drivers should call the API, if at all, and what the expected effects are. Similarly, the effects of drivers registering their program and hook attributes through NMR, and which scenarios that unblocks.
2. When extensions should register with the user mode store API, and what the effects are. For example, should extension installers typically register with the store API, or if the store affects only HKCU, who is responsible for registering and deregistering with the APIs?

See microsoft/xdp-for-windows#519, for example, where the expected behavior and effects are ambiguous.

There is no change in contract for the extension developers, only the internal implementation of the store APIs has been updated to also populate HKLM registry store.

1. The extension drivers do not need to call the store APIs.
2. Extension developers continue to publish a bpf_export EXE to call UM store APIs for updating and cleanup.

[saxena-anurag]

Documentation
No.

I realize this PR is only for release/0.17, but as an extension developer it is not clear which extension components are supposed to call the store APIs, when they are supposed to be called, and what the expected effects are. Please update the documentation to clearly define:

1. When extension drivers should call the API, if at all, and what the expected effects are. Similarly, the effects of drivers registering their program and hook attributes through NMR, and which scenarios that unblocks.
2. When extensions should register with the user mode store API, and what the effects are. For example, should extension installers typically register with the store API, or if the store affects only HKCU, who is responsible for registering and deregistering with the APIs?

See microsoft/xdp-for-windows#519, for example, where the expected behavior and effects are ambiguous.

There is no change in contract for the extension developers, only the internal implementation of the store APIs has been updated to also populate HKLM registry store.

1. The extension drivers do not need to call the store APIs.
2. Extension developers continue to publish a bpf_export EXE to call UM store APIs for updating and cleanup.

Regarding updating documentation, agree that some parts need to be updated. That is currently tracked by #3021

[mtfriesen]

Extension developers continue to publish a bpf_export EXE to call UM store APIs for updating and cleanup.

When are extensions supposed to invoke their exe? Are they simply supposed to be provided, and any application or user that intends to use the extension directly invokes the extension exe?

[saxena-anurag]

Extension developers continue to publish a bpf_export EXE to call UM store APIs for updating and cleanup.

When are extensions supposed to invoke their exe? Are they simply supposed to be provided, and any application or user that intends to use the extension directly invokes the extension exe?

I see what you mean. The "installation" step of the extension should invoke the exe to populate the store. Similarly, uninstallation should again invoke the exe to clear the store.

[mtfriesen]

The "installation" step of the extension should invoke the exe to populate the store. Similarly, uninstallation should again invoke the exe to clear the store.

Installation of an extension is a system-global operation: the driver can only load once, and even if it were started in parallel, only one instance of the driver can be chosen by eBPF through NMR.

The effect of registering with the ebpf store APIs on versions > 0.17, as I understand it, is limited to HKCU, i.e., the user who happens to install the extension.

Is this not a contradiction? An ideal software installer should have either global or user scope; having partially global and partially user scope will be confusing for users of the software.

[saxena-anurag]

The "installation" step of the extension should invoke the exe to populate the store. Similarly, uninstallation should again invoke the exe to clear the store.

Installation of an extension is a system-global operation: the driver can only load once, and even if it were started in parallel, only one instance of the driver can be chosen by eBPF through NMR.

The effect of registering with the ebpf store APIs on versions > 0.17, as I understand it, is limited to HKCU, i.e., the user who happens to install the extension.

Is this not a contradiction? An ideal software installer should have either global or user scope; having partially global and partially user scope will be confusing for users of the software.

So this PR is patching 0.17 to also write to HKLM which should fix the issue for 0.17.x releases. For releases 0.18 onwards, we will need to either fix #3046 or port this PR to main.

The base branch was changed.

[saxena-anurag]

Moving to draft to investigate failures.

[matthewige]

nit: 'It Is possible' (or it's possible)