Need a bit clarity for creating eBPF and code replace filters

[anilkyadav]

Hi, Thanks for the work you guys have been doing.
It looks to be a useful tool to prevent the sitting duck devices from attacks until the secure patch is applied after a long time.
This tool looks very useful and I have few queries to clear out before using your work.

1. Who will write the eBPF patches ?
   e.g. If I am going to use this tool in our ecosystem.
   i. For a hypothetical scenario suppose a CVE is detected and its fix was provided by the open source community. Now its eBPF patch should be implemented by open source people or the OEM team who is using the open-source ?
   ii. If open-source community has to write the eBPF patch then its an additional task for them and I am not sure if they will do it.
   iii. If OEM developer team has to implement the eBPF patch then they would required the skillsets to implement it which is not as simple. First, they have to understand the background of the issue, understanding of the library/source code, understanding of eBPF framework and of RapidPatch. Its not a small task. Please correct me if I have mentioned which is not correct in my understanding.
   iv. Is the eBPF and Code replace filters are generic in nature to handle that kind of defects appearing in future in some other libraries ?
   v. Do you suggest any way to automate the generation of eBPF and Code replace filters ?

[fripSide]

We are currently developing a Linux version of RapidPatch. It will provide a more convenient toolchain for automatically generating eBPF patches from C source patch diffs. This version will be released later this year.

For this version,

1. Who will write the eBPF patches?

Currently, the device maintainer who deploys the patch needs to write eBPF patches.
Ideally, if major open source library maintainers (e.g., mbedTLS) also adopt this system, they can release a common patch for a specific CVE(bug), and the eBPF runtime can make their patch adaptive for heterogonous devices that use their library.

i. For a hypothetical scenario suppose a CVE is detected and its fix was provided by the open-source community
ii. Will the open-source community write the Patch?

Yes, in our design we hope the open-source community can release the eBPF patches immediately after they fix any CVE.
Currently, the OEM company can use this mechanism in its own branches to prepare patches for all its product lines.
We plan to provide tools for users to convert the C source code patch to eBPF patch. This may make it easier to use this framework.

iii. The challenges of understanding of eBPF framework and RapidPatch for users.

Yes, it is challenging for OME teams to implement eBPF patches now as the toolchain is not ready. People still have to manually write everything.
Since one large vendor in China has adopted the RapidPatch solution, we are working on improving this system to make it more convenient to use. However, we need to adjust the detailed implementation based on target devices using RTOS or Linux.
Users still need to understand the differences between eBPF's C code and standard C.

iv. Is the eBPF and Code replace filters generic to the bugs in library?

RapidPatch supports two kinds of patches, the filter patch can only make the vulnerable function return earlier on error or violating input. The other type is code-replace patch which can replace any C function. We plan to implement a general FFI for eBPF to call any C function before Sep 2023. We also have to port the BTF to adapt the patch with the struct and function types of the target library. It is promising to fix any C bugs use eBPF code-replace patch when FFI and BTF are available.

v. Automate the generation of eBPF and Code replace filters.

Yes, we plan to do this using static analysis to generate eBPF patches from C code before 2024.
update 2023-8-20:
In our new version, we no longer need to write a dedicated eBPF patch, but can directly use the C source code instead.