Export functions necessary for ebpf-go port #4116
Conversation
lmb
force-pushed
the
export-funcs
branch
2 times, most recently
from
e455b71 to
16742ad
Compare
Export functions used to manipulate fd_t. This makes the use of the UCRT _get_osfhandle an implementation detail which is abstracted away from users of ebpfapi.dll. This also makes it easier to use the API via run-time dynamic linking.
lmb
force-pushed
the
export-funcs
branch
4 times, most recently
from
3dd21e0 to
1b2b5f1
Compare
| @@ -316,7 +316,7 @@ get_ebpf_program_type(bpf_prog_type_t bpf_program_type) | |||
| } | |||
|
|
|||
| _Ret_maybenull_ const ebpf_attach_type_t* | |||
| get_ebpf_attach_type(bpf_attach_type_t bpf_attach_type) noexcept | |||
| ebpf_get_ebpf_attach_type(bpf_attach_type_t bpf_attach_type) noexcept | |||
There was a problem hiding this comment.
I think this function is subject to a use after free: the returned ebpf_attach_type* is directly returned from _windows_section_definitions. That vector does get cleared when the DLL unloads. So something like:
- Load DLL
- Lookup an attach type
- Unload DLL
- Use attach type
would cause the use after free. Should I change this function to take an ebpf_attach_type_t* as an argument and copy into that?
There was a problem hiding this comment.
@saxena-anurag what do you think?
lmb
force-pushed
the
export-funcs
branch
2 times, most recently
from
de8e85e to
0463b70
Compare
include/ebpf_api.h
Outdated
| * @see ebpf_program_attach_by_fd | ||
| */ | ||
| _Must_inspect_result_ ebpf_result_t | ||
| ebpf_program_attach_as_fd( |
There was a problem hiding this comment.
Not a great name, ebpf_program_attach_as_fd which already exists would make more sense imo. Open to bikeshedding.
There was a problem hiding this comment.
maybe ebpf_program_attach_by_fd_and_get_fd?
It's wordy but the "by fd" in 413 refers to the first input, which still applies in this prototype
There was a problem hiding this comment.
ebpf_program_attach_fds? I have a suspicion that there might be more cases like this in the future.
There was a problem hiding this comment.
Actually, I'm currently working on ebpf_object_load_native_fds.
There was a problem hiding this comment.
To me, "attach fds" and "load ... fds" sound like they attach or load multiple fds, which is not the case.
There was a problem hiding this comment.
Can we break API and rename _by_fd to _from_fd or so?
There was a problem hiding this comment.
Or ebpf_program_attach_by_fds?
Add a function which returns the link as an fd when attaching a program. The existing functions are re-jigged to reduce code duplication.
Allow users to resolve libbpf style enums to Windows GUIDs and vice versa.
lmb
requested review from
dthaler,
poornagmsft,
Alan-Jowett,
saxena-anurag,
shankarseal,
dv-msft,
gtrevi,
shpalani,
matthewige,
mtfriesen and
rectified95
as code owners
include/ebpf_api.h
Outdated
| * @see ebpf_program_attach_by_fd | ||
| */ | ||
| _Must_inspect_result_ ebpf_result_t | ||
| ebpf_program_attach_as_fd( |
There was a problem hiding this comment.
maybe ebpf_program_attach_by_fd_and_get_fd?
It's wordy but the "by fd" in 413 refers to the first input, which still applies in this prototype
Co-authored-by: Dave Thaler <[email protected]>
Co-authored-by: Dave Thaler <[email protected]>
This PR exports various functions required to make the ebpf-go port work. They fall into the following categories:
Commit messages below
Export ebpf_close_fd and ebpf_dup_fd
Allow attaching a link as an fd
Export functions to translate between GUID and enums