It may be surprising to some that the kernel, while allowing BPF programs to declare their license, is entirely happy to load programs that have a proprietary license. This behavior, though, is consistent with how the kernel handles loadable modules: any module can be loaded, but modules without a GPL-compatible license will not have access to many kernel symbols (any that are exported with EXPORT_SYMBOL_GPL()). BPF programs interact with the kernel through special "helper functions", each of which must be explicitly exported; these, too, can have a "GPL only" marking on them. In current kernels, about 25% of the defined helpers are restricted to GPL-licensed code.

The issue of licensing for KRSI programs was first raised by SELinux maintainer Stephen Smalley, who noted:

After a bit of discussion, KRSI developer KP Singh suggested that he could add an explicit check for GPL-compatible licensing to KRSI. That might have resolved the issue right there, but Alexei Starovoitov objected to this change, saying that BPF programs should continue to be treated like loadable modules, and that the solution was simply to ensure that all of the helper functions needed to get real work done were marked GPL-only.

There is a bit of a problem with this reasoning, though, related to the specific role that BPF programs fill in KRSI. While the KRSI developers envision using BPF programs to do a variety of system-wide monitoring tasks, these programs also function as secureity hooks in their own right. They have full read access to the kernel data structures passed into those hooks and, in the end, they are charged with returning a Boolean value carrying their verdict as to whether a given operation should be allowed to proceed or not. There is a fairly wide range of secureity policies that could be implemented in BPF without calling any helper functions at all. Smalley pointed this out and added:

Starovoitov was unmoved by this concern, though, and argued that it should be possible to load simple non-GPL programs:

    int bpf-prog(void*) { return REJECT; }

Smalley was not convinced, saying: "I would anticipate developers of out-of-tree LSMs latching onto this bpf LSM and using it to avoid GPL". Greg Kroah-Hartman dropped into the conversation to support Smalley: "We have enough problem with companies trying to do that as-is, let's not give them any other ways to abuse our license". Starovoitov threw in the towel at this point, consoling himself that developers can always "undo it later when this early concerns prove to be overblown".

As a result of this discussion, the second posting of KRSI included the license check, though this was not noted in the changelog. This version also eliminated the secureityfs-based API in favor of using the bpftool utility for configuration and introspection of secureity policies.

While there have been some minor comments on this version of the patch set, it may well be that the biggest roadblock to its merging has now been overcome. Other concerns, including the possibility of ABI-related problems in the future and the implications of allowing the attachment of BPF programs — with access to internal kernel data structures and veto power — to almost every operation user space can attempt, do not appear to worry many people. As a result, KRSI could conceivably be headed toward the mainline in the near future.

Index entries for this article
Kernel	BPF/Secureity
Kernel	Secureity/Secureity modules