On Thu, Jan 30, 2025 at 11:22:24AM -0800, Blaise Boscaccy wrote:
> Cong Wang <xiyou.wangcong@xxxxxxxxx> writes:
>
> > Hello Blaise,
> >
>
> Hi!
>
> > On Thu, Jan 09, 2025 at 01:43:42PM -0800, Blaise Boscaccy wrote:
> >>
> >> This is a proof-of-concept, based off of bpf-next-6.13. The
> >> implementation will need additional work. The goal of this prototype was
> >> to be able load raw elf object files directly into the kernel and have
> >> the kernel perform all the necessary instruction rewriting and
> >> relocation calculations. Having a file descriptor tied to a bpf program
> >> allowed us to have tighter integration with the existing LSM
> >> infrastructure. Additionally, it opens the door for signature and provenance
> >> checking, along with loading programs without a functioning userspace.
> >>
> >> The main goal of this RFC is to get some feedback on the overall
> >> approach and feasibility of this design.
> >>
> >> A new subcommand BPF_LOAD_FD is introduced. This subcommand takes a file
> >> descriptor to an elf object file, along with an array of map fds, and a
> >> sysfs entry to associate programs and metadata with. The kernel then
> >> performs all the relocation calculations and instruction rewriting
> >> inside the kernel. Later BPF_PROG_LOAD can reference this sysfs entry
> >> and load/attach previously loaded programs by name. Userspace is
> >> responsible for generating and populating maps.
> >>
> >> CO-RE relocation support already existed in the kernel. Support for
> >> everything else, maps, externs, etc., was added. In the same vein as
> >> 29db4bea1d10 ("bpf: Prepare relo_core.c for kernel duty.")
> >> this prototype directly uses code from libbpf.
> >>
> >> One of the challenges encountered was having different elf and btf
> >> abstractions utilized in the kernel vs libpf. Missing btf functionality
> >> was ported over to the kernel while trying to minimize the number of
> >> changes required to the libpf code. As a result, there is some code
> >> duplication and obvious refactoring opportunities. Additionally, being
> >> able to directly share code between userspace and kernelspace in a
> >> similar fashion to relo_core.c would be a TODO.
> >
> > I recently became aware of this patchset through Alexei's reference
> > in another thread, and I apologize for my delayed involvement.
> >
> > Upon reviewing your proposed changes, I have concerns about the scope
> > of the kernel modifications. This implementation appears to introduce
> > substantial code changes to the kernel (estimated at approximately
> > 1,000+ lines, though a git diff stat wasn't provided).
> >
>
> Yes, it ended up way bigger than I anticipated. The ultimate goal of
> that was to be able to conditionally compile parts of libbpf directly
> into the kernel and unify the btf and elf libraries. That refactoring
> work was way out of scope for a PoC.
>
> > If the primary objective is eBPF program signing, I would like to
> > propose an alternative approach: a two-phase signing mechanism that
> > eliminates the need for kernel modifications. My solution leverages
> > the existing eBPF infrastructure, particularly the BPF LSM framework.
> > So the fundamental architectural difference between these two approaches
> > is pretty much kernel-based versus userspace implementation, which has
> > been extensively discussed and debated within the kernel community.
> >
>
> Code signing, secure system design and supply-chain attack mitigations
> are some active research areas that we are exploring. BPF programs have
> some interesting ramifications on those topics. Attacks that were
> previously demonstrated in CVE-2021-3444 are an area of interest as
> well.
Thanks for sharing all the information.
>
> > I have also developed a proof-of-concept implementation, which is
> > available for review at: https://github.com/congwang/ebpf-2-phase-signing
> >
>
> Sweet, I'll take a look. It sounds super interesting! At a quick
> glance, it looks like your approach would probably benefit from John's
> suggestions for early-boot un-unloadable bpf programs.
Oh, mine is unloadable, I just used another eBPF program to do the actual
signature verification. If we unload it (like other regular eBPF
programs), the whole signing enforcement is gone.
>
> What are your use cases for signature verification if you don't mind me
> asking?
>
Sure. To be honest, our use case is actually simpler than 2-phase
signing. What we wanted is merely a centralized way to manage all the
_internal_ eBPF programs within our data center, therefore, signing the
original eBPF binary is probably sufficient because we trust our own
eBPF programs and we just want to use signing as an approval. It should
not be hard to modify my 2-phase signing to just 1-phase (by skipping
the 2nd one).
The reason why I proposed 2-phase signing is that I found that in the
past there were multiple attempts in the community trying to solve this
signing problem, so I looked into it a bit deeper and wanted to see if
I could find a solution to benefit the whole community (and ourselves
too).
Thanks!
