Skip to content

Latest commit

 

History

History
3192 lines (2615 loc) · 155 KB

minutes.md

File metadata and controls

3192 lines (2615 loc) · 155 KB
Raw

Meetings & Meeting Notes

Important: All BSC members are expected to regularly check the summarized meeting notes from the BSC chair (the chair will notify the BSC mailing list once notes are cleaned up), and members either propose changes to the notes or add comments on some of the sections if something was not correctly represented from the meeting. The BSC chair will then finalize and notify the GB chair about it. Silent deadline is one week after the BSC meeting took place.

Meeting #50 - 2024-05-02

  • Duration: 20 min
  • Chair: Andrii Nakryiko
  • Participants:
    • Joe Stringer
    • Brendan Gregg
    • Alan Jowett
    • Dan Brown
    • Andrii Nakryiko
  • Notes:
    • Joe to give BSC presentation at LSFMMBPF2024

Meeting #49 - 2024-03-06

  • Duration: 24m
  • Chair: KP Singh
  • Participants:
    • Joe Stringer
    • Brendan Gregg
    • KP Singh
    • Alan Jowett
  • Notes:
    • No quorum
    • Discussion on using temporary files as part of bpftrace/BCC
    • Dan: FYI the charter amendment vote has passed.
      • Next session with quorum we can do a vote for new members
    • Dan: Sponsorships
      • LSFMM signed: Two passes available.
      • Plumbers signed: 5 in-person / 15 virtual passes available.
      • Contact Dan for more info on passes.
      • Kernel Recipes: Pending.
      • Kubecon NA co-location: Awaiting event organizers

Meeting #48 - 2023-02-21

  • Duration: 48m
  • Chair: Joe
  • Participants:
    • Dan Brown
    • Alan Jowett
    • Joe Stringer
    • Alexei Starovoitov
    • Brendan Gregg
  • Notes:
    • No quorum
    • Charter Amendment
    • Events to focus on - marketing committee expected to approve the list provided by BSC.
    • Considering security whitepaper, Brendan / KP for subject matter expertise and whether to find professional writers to work towards this.
      • Brendan feedback on State of eBPF report: Grammar can come at the expense of technical accuracy.
      • Brendan: Question about format. Would a 1-pager be useful enough to outline key messages, advice from experts.
      • eBPF is your security friend, not your enemy :)
      • Action Item (Brendan, KP) to work on draft text.
      • Drafting high level topics to cover in the whitepaper. Brendan has a list now.

Meeting #47 - 2024-01-24

  • Duration:
  • Chair: Brendan Gregg
  • Participants:
    • Joe Stringer
    • Sridhar Rao
    • Alexei Starovoitov
    • Brendan Gregg
    • KP Singh
    • Alan Jowett
    • Andrii Nakryiko
    • Daniel Borkmann
  • Notes:
    • 2023 year in review
    • 2024 goals
      • Technical success in SOWs
      • Better prepare/develop foundation tasks (BSC & GB) before encouraging more members to join the foundation, so when they do join it is a better and more valuable experience
        • Finish BSC task list (in these meeting notes way below)
        • GB task list?
      • Fruitful collaboration between BSC / GB
      • Outreach. Engage with companies using BPF to understand how they are using it and pain points.
        • Small blocker: Intel legal draft (almost done)
      • "Humble goals"
    • Alan: What is the difference between the BSC vs. IETF BPF working group?
      • IETF around standardization
      • BSC: What are pain points in the community, how can we help fund marketing and technical achievements in those areas.
      • BSC: Provide a stable basis that can be used in order to innovate on top.
    • Update: Brendan has draft legal disclaimer for meetings, almost done he hopes.
    • Proposal/SOW drafts for external contractor work (e.g. collabora, Linaro, et al) to recommend funding to the GB [Daniel]:
      • SR: prioritize SOWs
        • P1 High priority, P2 medium, P3 low.
      • BPF kernel CI improvements [P1]: https://docs.google.com/document/d/1HYkbDTBDMhuOuSeMaFT4RqrMTIUKWp04XvJTLyck6v4/edit
        • Daniel: Happy to help
      • BPF CI local vmtest.sh runner [P2]: https://docs.google.com/document/d/1U_NJ8axXtD_4kLrUiBF9mqauLO8IM7pZI30ItJyIgeI/edit
        • KP: Happy to help
        • Discussion about just using CI for testing rather than local.
        • Andrii: Maybe rescope this to setting up a full development environment.
        • Alexei: This could actually help with subsequent contracting.
        • AI(Daniel): Rewrite [done]
      • LLVM BPF backend improvements [P1/P2]: https://docs.google.com/document/d/1SY-hlMvqQeA-kH35YFqTgPwtAdz2qdOpF6DZdZHLWf0/edit
        • Alexei: Happy to help
        • Alan: Also interested, to better support PREVAIL.
        • Discussed on the doc and added feedback comments.
      • BPF on arm64 improvements [P1]: https://docs.google.com/document/d/1GI0rVbdryz6z8GA0E2PGV6KlmHXvIoMev36RmaHTCJ8/edit
        • KP: Florent can help
        • Impact: Issues with BPF on ARM in clouds, Android.
        • Difficult to prioritize between each task, they are all very similar priority
      • BPF on riscv improvements [P3]: https://docs.google.com/document/d/17hLWYBM2AmpcKbgcvWirGQtIJiL8ELB195IfQd8lMQQ/edit
        • Daniel: Bjorn Topel could help
        • Not yet drafted [done]
        • Step 1: Enable in CI, form denylist
      • Alexei: The above are targeted towards contractors. For this to be successful, we will need to provide some guidance.
        • Practical steps: Who will find contractors?
      • KP: We are happy to put SOWs in any format that the board is looking for.
      • Sridhar: Start with what we have so far. Any contractors/vendors we work with may have further questions and we can clarify at that point.
      • Alexei: It's important to use Foundation funding in responsible ways, SOWs should be well time bounded and they appear to be formatted that way.
      • KP: Starting somewhere with one project would help to start and understand the process, commitments, etc.
      • Brendan: How do we ensure minimum expectations/requirements for contractors
        • Coding in C
        • Linux upstream experience
      • LF can begin finding vendors/contractors (see above requirements).
      • SR: Context around 2024 budget.
      • AI(SR): Start estimating the cost for contractors, prepare for GB Feb 13 meeting.

Meeting #46 - 2024-01-10

  • Duration:
  • Chair: Andrii Nakryiko
  • Participants:
    • Dan Brown
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
    • KP Singh
    • Alexei Starovoitov
    • Andrii Nakryiko
  • Notes:
    • Update from GB meeting: No quorum. KP was late, but it was already finished.
    • KP: Discussing with April about a potential GB+BSC summit.
      • Blocker: Legal notice for meeting. Brendan to follow up afresh now.
      • Draft by Brendan from memory (do not use):
        • "This is a public meeting to discuss open source technologies only. Please do not share anything confidential (for example, your company's roadmap or future plans).
        • Be aware that your competitors may be present in the meeting.
        • Be aware that anything you share may be adopted and sold by others."
    • Daniel to ask Sridhar to get all members of BSC onto invite for GB meetings
    • BSC Year in Review doc review/discussion
      • Emphasize travel sponsorship more
      • Where to publish? eBPF foundation site, probably.
      • Retrospective discussion
      • Everyone to review and comment within a week, then publish
    • Conferences
      • FOSDEM Feb 3-4, who will go?
        • Joe
      • IETF March 15-22
        • Alexei considering to attend
      • Kubecon EU, March 19-22
        • eBPF Security talk waitlisted for Cilium & eBPF day
      • LSFMMBPF, Salt Lake City, May
      • LPC ~Sept, Vienna, Austria
        • Overlaps with kernel recipes, GCC
        • Expected around Open Source Summit EU, Sept 16-18

Meeting #45 - 2023-12-13

  • Duration: 52m
  • Chair: Alexei
  • **Participants: **
    • Dan Brown
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
    • Alan Jowett
    • KP Singh
    • Alexei Starovoitov
    • Mike Dolan
    • Andrii Nakryiko
  • Notes:
    • Reviewing latest charter proposal from GB
    • Project lifecycle:
      • How to manage expectations around the level of endorsement from BPF foundation membership - sandbox vs. core etc.
      • Mike Dolan: The website doesn't have this project progression policy currently. Need to resolve the differences.
    • Status of outstanding proposals for projects to join:
      • BTFHub, libbpf-go proposals are blocked on legal notice
      • Brendan to follow up with where we got to most recently on legal notice and forward to Mike to unblock next steps.
    • How can BSC better communicate with GB?
      • Per 2023-10-18 discussion, KP volunteered to be primary contact currently.
      • How does BSC understand when GB meetings are occurring?
        • Dan volunteered to follow up with Sridhar to ensure BSC gets visibility into meeting times.
      • How many BSC members can attend GB meetings?
        • Intention is at least one member joins, per charter.
        • Mike: For the charter discussions, it may help to have additional members.
      • What is the intended way for BSC to understand the discussions during GB meetings?
        • BSC representative to attend GB meeting and relay summary to BSC during following BSC meeting.
    • Directed funding requests
      • Daniel: Interested in a proposal for funding specific LLVM work.
        • Related: Discussions with academia during LPC, interested in exploring options to help push that forward.
      • Dan: We can set up a shared list with GB + BSC to facilitate these discussions.
    • Security talk @ kubecon EU: submitted, awaiting CFP response
    • LSFMM dates confirmed for May 13-15, 2024: https://events.linuxfoundation.org/lsfmmbpf/
      • Budget submission proposed to LF for sponsorship.

Meeting #44 - 2023-11-29

  • Duration:
  • Chair: Joe Stringer
  • **Participants: **
    • Dan Brown
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
    • Alan Jowett
  • Notes:
    • No quorum
    • Brainstorming eBPF security messaging
      • CFP for Kubecon co-located Cilium + eBPF day as a forcing function to start developing threat modeling / security messaging for eBPF community
      • We should write the slides anyway, we'll want the content for other conferences or for preparing marketing messaging / text.
      • Dan mentioned there is a budget line item submission for 2024 funding to help prepare material for security messaging. BSC can help draft the core content and we could look to have additional help to finalize format / text.
      • Brainstorm link
    • eBPF on Windows status
      • Signing
      • JIT vs HVCI
      • Porting tools to Windows

Meeting #43 - 2023-10-18

  • Duration:
  • Chair: KP Singh
  • **Participants: **
    • Dan Brown
    • Joe Stringer
    • KP Singh
    • Alexei Starovoitov
    • Brendan Gregg
    • Daniel Borkmann
    • Dave Thaler
    • (regrets from Andrii)
  • Notes:
    • Status on proposal to board
      • BSC previously reviewed Mike's proposal.
      • Understand that there was no quorum from GB during 2023-10-17 session.
    • Any result of board vote on election?
      • No, there was no quorum
    • IETF
      • Dave would like to propose an additional editor for RFCs for someone with rights in the Linux kernel, to share the responsibilities.
      • Call for a working group to adopt a draft: Feedback date has passed. Awaiting bpf working group chair confirmations in IETF tooling.
      • Call for agenda open since Oct 9
      • Topic (Alexei): Memory model - send to WG chairs
      • BPF working session 09:30 - 11:30 Prague time Monday 6th
    • Dave plans to step down from BSC at the end of the LPC week November 17th and has nominated Alan Jowett. Alexei seconds. KP thirds. All present agree provided the new process is ratified by the board. This shows the BSCs commitment to continuity and faith in the proposed process.
    • Linux Plumbers Conference
    • LSF/MM/BPF contract is being negotiated for SLC
      • Targeting May 13-15 2024
    • BSC chair to represent at upcoming GB meetings
      • Next Nov session has LPC conflict, during the morning conference sessions.
      • Dan offered to bring up the conflict for scheduling that session

Meeting #42 - 2023-08-23

  • Duration:
  • Chair: Daniel Borkmann
  • Participants:
    • Andrii Nakryiko
    • Brendan Gregg
    • Joe Stringer
    • KP Singh
    • Dave Thaler
    • Dan Brown
  • Notes:
    • Kumar asked if eBPF foundation could help sponsor travel to LPC
      • https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?qt=author&q=Kumar+Kartikeya+Dwivedi
      • General requirements from BSC side for travel sponsorship:
        • Active contributor to eBPF ecosystem (not limited to just kernel BPF side, but could be other major projects/infrastructure as well)
        • Intention to submit a CFP for discussion session
          • (Intention given visa application needs to be submitted earlier before a person knows of the session being accepted)
      • Process: Someone directly involved in the same project or knowing them prepares a budget proposal.
      • With regards to Kumar assuming the intention to submit a proposal, BSC has no objections and would give recommendation to fund his travel to GB. (Alexei voted yes via email)
        • AI: KP to check with Kumar and to reach out to GB. Kumar could get one of the two free sponsor passes from eBPF foundation assigned so that he can apply for a visa in time (given this process takes longer).
    • Request for BSC's official position on:

A large company providing eBPF-based solutions at scale reached out to us as BSC asking if Fortune 500-type companies will be okay with us loading several eBPF programs on their servers. We are curious about what the eBPF community thinks about it.

We chatted with KP Singh from Google and with a few kernel developer from Red Hat and we got contrasting opinions: KP seemed to believe eBPF program signature and verification would be happening soon while Red Hat engineers believed it would not for years and told us they were currently focusing on securing eBPF program distribution and loading (with bpfd). In fact their product management is trying to push/mandate bpfd adoption from the Red Hat side.

We are very curious what you think (and if you had any feedback for large companies on this topic).

  • Related: https://next.redhat.com/2023/07/18/using-ebpf-in-unprivileged-pods/

  • Mailing list pointers from past discussion on topic of bpfd:

  • BSC discussion:

    • [AI: Daniel, Joe: getting back to the company with BSC position] (done)
    • There are already at least 4 projects in the overall space of deploying bpf programs: L3AF, bpfd, bumblebee, and Inspektor Gadget. They have differing but partially overlapping tradeoffs, dependencies, and use cases. bpfd is one project from one vendor, other vendors might have different mechanisms as there is no standard.
    • BSC not looking to rubber-stamp one approach to BPF program deployment also as there is no one-size fits all approach
    • Kernel side needs to ensure that there are enough mechanisms to suit the various needs / use-cases
    • There are various models for deploying programs
      • Userspace + BPF program(s) go together, tightly integrated
      • BPF programs are separately managed by a logically central tool
    • There are various mechanisms
      • capabilities, token, signing, lsms, etc
    • Discussion of "npm-style" questions / issues: Are the programs being installed from a legitimate source? Secure supply-chain.
    • One possible answer: BPF has been designed to be a safe secure sandbox, but people can still write illogical high-overhead and therefore harmful programs with it. As they can with any language.
    • Alexei (via email): My position is similar to KP's which is: redhat's bpfd or any other daemon based arbitration is not flexible enough to be a generic loader solution for all types of bpf progs.

  • Misc items:

    • Follow-up on "Proposal to create a BSC slack channel, need full BSC to weigh in on whether slack or something else":

      • If everyone is okay, I can create a Whatsapp group for BSC folks. BSC said yes. [AI: Daniel, Dave wanted to send his number] (done)

    • eBPF Foundation Mentorship program

      • [AI Daniel] Checking with Sridhar on process related to BSC (done)

      • [AI all] Review the mentorship doc which was sent via email

      • Answer on process:

        • The process would be:

          1. This CFP (with dates) will be made public - This will also go under announcements in the website.
          1. Once we receive proposals, it will be brought to BSC for selection and/or approval. BSC will consider availability of the mentor(s) as one of the criteria while selecting/approving.
          1. Once BSC approves the project, it will be add to the LF-Mentorship Program.
          1. The program will be activated and will be open for potential interns to apply.
          1. We will again circulate this LF mentorship program widely.
          1. The mentors will select the interns.
          1. Once the interns are finalized The program will start - Request will be made to mentors to regularly update BSC on the progress.

    • 2 sponsor passes for LPC are needed for speakers

      • One potentially for Kumar

    • Refilling Lorenz' position?

      • One suggestion was that we could bring Lorenz back.
      • Currently nobody feels strongly about the need for backfill.

    • Informational:

      • eBPF Summit (Sep 13) schedule out: https://ebpf.io/summit-2023-schedule/
      • LSF/MM/BPF currently figuring out location logistics, should have more info in September
      • LPC (Nov 13-16) CFP is still open until Sept 27, we're looking for more submissions for eBPF & net track: https://lpc.events/

Meeting #41 - 2023-08-09

  • Duration:

  • Chair: Dave Thaler

  • Participants:

    • Dan Brown
    • Joe Stringer
    • Brendan Gregg
    • Dave Thaler

  • Notes

    • No quorum
    • Dave reported to the GB that BSC is continuing governance discussion.
    • BSC focus areas
      • We started with a charter BSC scope populated from similar wording in other foundations
      • Reviewed/discussed/iterated on Brendan's wip proposal
    • Highlighting projects
    • Proposal to create a BSC slack channel, need full BSC to weigh in on whether slack or something else

      • BSC members should weigh in with what chat systems they are allowed to use.

      • This list was not discussed during the meeting and does not need to be in the minutes:

        • Joe: Prefer Slack, no restriction

        • Brendan: Prefer Slack, no restriction

        • Dave: no preference, no restriction

        • Alexei: Prefer Whatsapp or Signal

        • Dan: Prefer Slack or Whatsapp, no restriction

        • KP:

        • Daniel: Prefer Slack or Whatsapp, no restriction

  • Drafts

    • The BSC:

A) Summarizes eBPF technical value

B) Summarizes eBPF technical best practices (incl. endorsed projects; production cookbook; security).

C) Provides steering for larger eBPF technical activities (implementations, libraries, bytecode, documentation).

D) Works to resolve cross-platform eBPF needs.

E) Provides thought leadership for broader eBPF related projects (e.g., deployment/L3AF)

F) Maintains a list of core projects.

G) Provides recommendations to the LF to not include particular "sandbox" projects.

H) Pushes the industry to further support eBPF (e.g., technical work with distros).

I) Occasionally selects eBPF projects to meet with to show support, guidance, and encouragement.

J) Recommends the allocation of foundation resources.

  • Project Lifecycle:
  1. Exists : On github.
  2. "Emerging" : Listed on ebpf.io by anyone (e.g., Isovalent marketing).
  3. "Sandbox" (optional): Accepted by the LF as an LF project, therefore contributes/grants IP & trademark rights/permissions to the LF. BSC can veto in rare cases where the project is harmful, but the BSC is not reviewing these in depth, and the BSC will not be asked to review or participate with these projects.
  4. "Core" : A small handful of critical eBPF projects selected by the BSC and reviewed by the BSC. (E.g., libbpf, bcc, Windows eBPF, etc.) See prior task (F).
  5. "Guideline" : A project recommended by the BSC for a purpose. See prior task (B).

  • Discussion

    • Hypothetical e.g.: There are five golang eBPF libraries but we only want to encourage one. All five "exist" and are listed as "emerging." Those that want to be an LF project can apply to the LF and become a "sandbox" project, and some will (between zero and five). The BSC is asked if there is any reason to veto them, and there probably isn't in this case (it's just duplicated work, not, for example, some nasty technical/legal risk). The BSC selects the one that we want to encourage as "core" and the BSC also states this in a guideline doc.

    • "Cookie lickers" and project "squatters": If someone wants to own an important piece before anyone else, but do little or zero work, they may push to be accepted by the LF first as a way to claim ownership of the idea. And they may hope the BSC will help them with details to cement their endorsement. With the above plan, the BSC will only have a chance to veto it becoming a "sandbox" project, and since it sounds ok it shouldn't be vetoed. The LF won't ask the BSC to review it in any more depth. The only involvement by the BSC will be if it does actually get developed and grow important enough to be either considered a core project (task F), part of a guideline doc (task B), or warrant a meeting of encouragement (task I). The BSC does not have the capacity to be involved with every sandbox project.

Meeting #40 - 2023-07-27

  • Duration:
  • Chair: Brendan Gregg
  • Participants:
    • Dan Brown
    • Joe Stringer
    • KP Singh
    • Brendan Gregg
    • Alexei Starovoitov
    • Dave Thaler
  • Agenda
    • eBPF Documentary: More interviewees? None come to mind.
    • eBPF Summit: If elections are happening can announce at summit
      • Overlaps with all systems go
      • Close to Tracing summit (Spain) Alexei is presenting
      • Close to Linux security summit
    • Messaging (Dan) no further comments
    • Marketing "state of eBPF" report
      • State, use cases, next year
      • Convey security state? - KP
    • Report on IETF BPF WG meeting 2023-07-24
      • Good meeting
    • Charter voting

      • Why implement voting for the BSC?

        • There has been no problem for eBPF with the make up of the BSC or BSC itself. It was raised that if there had, we would have been told specifics by now. Months ago, someone new to eBPF from the LF raised one problem of the BSC being unwelcoming but did not back it up with specifics, and, the BSC, who is in contact with the community daily and has been for years, has not heard of any problem themselves.

        • The notion of voting was inherited from the copy-n-pasted charter text that we didn't pay much attention to when the foundation was created. In a way, the voting model is at the forefront because we didn't study what we copy-n-pasted.

      • What models should we consider?

        • Taking a step back: It was asked if anyone had a strong preference for a particular model (e.g.: BDFL team, maintainers decide, voting); no one on the call did. Dave strongly wants a model that is documented and matches reality in a year from now.

      • What should we do now?

        • Because no one feels strongly for anything, the only proposal discussed at length is the voting process inherited from the charter text, which Joe has been turning into a documented proposal.

        • This proposal can be made a separate "process document" that the charter refers to, and can be updated as we fine tune things and learn of unexpected issues.

        • It was proposed that the first round of voting be in some ways a trial run for the process.

        • We will follow up over email so that others on the BSC who were not on the call have a chance to discuss.

      • What happens if no one (or few people) vote?

        • Do we want a minimum number of votes to make an election valid? Seems not.

        • It was proposed that the GB or BSC "ratify" an election and checks that things worked, and voters were informed and had a chance to vote.

Meeting #39 - 2023-07-12

  • Duration:
  • Chair: Alexei Starovoitov
  • Participants:
    • Dan Brown
    • KP Singh
    • Dave Thaler
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
    • Mike Dolan
  • Agenda
    • update from GB

      • "the BSC will set initial term length so as to stagger elections"

      • charter October deadline is ambiguous

      • Ideas:

        • Only let maintainers e.g. of major projects vote

        • Solves various issues

          • Keeps bad actors out

          • Keeps MS in for eBPF for windows

      • Voters: "Projects/individuals that have helped advance the progress of eBPF in the last year."

      • Joe will send a list of voters and nominees to bsc mailing list.

Meeting #38 - 2023-06-28

  • Duration:
  • Chair: KP Singh
  • Participants:
    • Dan Brown
    • KP Singh
    • Lisa Caywood
    • Alexei Starovoitov
    • Andrii Nakryiko
    • Dave Thaler
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
  • Agenda
    • IETF WG update (Dave?)
      • Emails went out a week ago, official announcements sent out.
      • IETF 117 Meeting Agenda
      • WG meets regularly
        • 1300 Pacific on 24th.
        • Announce so that folks can book.
        • The week is fixed, the slots may change.
      • Alexei: Please CC BPF@IETF and BPF kernel mailing list
        • AI(Dave): Forward email
    • BPF Docs repository under eBPF will move to IETF
    • Windows roadmap [KP Singh/Dave]
      • Updating slides live
      • bpf / dtrace on windows overlap
      • Alexei: How do we keep parity between BPF on Linux / Windows?
        • Contributions are welcome.
        • Reactive
        • Demand enables parity (similar with ARM).
        • Runtimes that use PREVAIL often use uBPF, so uBPF feature additions result in demand for corresponding PREVAIL additions (e.g., local calls).
        • Biased opinion: Standardization.
        • KP / Dave will work on updating the slides offline.
    • [Brendan] legal update
      • Met with Intel legal and Intel open source. Intel legal will draft a proposal, "3 sentences long" for meeting preamble. Set expectations clearly around the public nature of this meeting.
      • Protect the community and ecosystem from accidental exposure to proprietary information.
    • [Brendan] Purpose of admitting projects into the foundation + expected process.
    • Announcement about IETF | IETF blog & news
    • [Lisa] Joint Board & BSC meeting July 12th
      • Group is meeting with the board to discuss the changes to the election process with the board in 2 weeks.
      • If there are any changes that need to be made, these need to be finalized before 12th July.
      • Brendan: Cannot join, Committee as a "whole" is, why does it need to be done on the 12th and not next year.
      • Lisa: The group was supposed to be having elections

Meeting #37 - 2023-06-14

  • Duration:
  • Chair: Joe Stringer
  • Participants:
    • Dan Brown
    • Daniel Havey
    • KP Singh
    • Lisa Caywood
    • Alexei Starovoitov
    • Andrii Nakryiko
    • Dave Thaler
    • Daniel Borkmann
  • Agenda

    • [20m] messaging document from marketing committee [Lisa/Dan]

      • Point 1 - wording is a bit loose.
        • Follow up over email
      • Point 3 - Angle from hyperscalers is tricky to back up.
        • Is it about Performance or Production Proven?
        • The latter.
        • Discussed what "production" means - includes for example millions of Android devices
      • Goal: Provide feedback by Tuesday

    • [20m] Charter amendment proposals

      • BSC membership
        • Proposal
          • Nominee eligibility - initially keep it open / undefined in charter?
          • Voter eligibility - Should be specified in Charter
      • Direction of funds

    • [20m] Continue discussion of BSC charter and elections process [Lisa/Joe/Dave]

    • Project nominations

Meeting #36 - 2023-05-31

  • Duration:
  • Chair: Dave Thaler
  • Participants:
    • Alexei Starovoitov
    • Brendan Gregg
    • Joe Stringer
    • Andrii Nakryiko
    • KP Singh
    • Daniel Borkmann
    • Lisa Caywood
  • AGENDA
    • Report on May 9 board meeting feedback on BSC report, from minutes:
      • Regarding creating a security whitepaper: "Thomas suggested that Isovalent could help. Thomas added that they have hired a good security researcher analyst who has actually written the security.md for cilium and he would be happy to check if they can volunteer that person to make a first proposal. Isovalent had actually come to this conclusion that this is needed over 2 years ago, and then it failed because they didn't have anybody to actually do a first version. He also said that he is confident that the community will contribute, but the real effort lies in writing this from scratch. Lastly Thomas offered to connect the resource person to the BSC members through the mailing list. Ram added that it is an expected behavior for high-volume systems to drop packets, and having a whitepaper would probably be fine but maybe talking broadly on this through Blog is another option that we could consider. Thomas agreed with this suggestion on writing Blogs."
        • AI [Daniel/Joe]: talk to Thomas about someone to hold pen on whitepaper
      • Regarding charter amendments: "2 charter amendments in a future meeting for the Board to actually vote on: one about BSC makeup and one on the direction of funds to projects in general. Though, the direction of funds to projects in general might not require a charter update just an update to the document (project progression policy)", and action to "facilitate a joint session among the Governing Board and BSC together to essentially work out something in a more timely fashion, just to avoid a 3 month process from this point. Both Dave and Lisa agreed to this suggestion by Thomas, and Dave said that BSC may need one or two meetings, which may take a month from now, before they could participate in such a joint meeting"
        • Proposal: BSC to put together straw-man proposal by June 14 meeting, and plan to schedule joint meeting shortly thereafter for initial discussion with GB.
      • Lisa drafted the one about BSC makeup
      • Need a volunteer for funding (meeting #33)
    • IP risks [Brendan]
      • Scott Nicholas (LF Legal) has a conflict during this time, but will reach out to Intel legal to discuss Windows roadmap [KP Singh/Dave]
      • Brendan's story: don't have private meetings with startups without a legal agreement in place
      • Brendan's story: not all startups are friendly for the eBPF Foundation's mission
      • Brendan's story: the only thing that matters is what is signed
      • Question: is a notice at start of meeting sufficient or do we need evidence of agreement (click I Agree or whatever else)? AI: Brendan to check with legal
      • Encourage wording when discussing technical solutions on BSC meetings:
        • In your Open Source project, how do you do X?
      • Option: Can we evaluate projects without meetings, and only call meetings if/when necessary?
    • IETF update
  • Moved to following meeting June 14th:

Meeting #35 - 2023-05-17

  • Duration:
  • Chair: Daniel Borkmann
  • Participants:
    • Daniel Borkmann
    • Dave Thaler
    • Dan Brown
    • Joe Stringer
    • Alexei Starovoitov
    • Brendan Gregg
    • Andrii Nakryiko
    • KP Singh
  • AGENDA
    • Quick status webinar functionality [Dan]
      • Rough ETA for webinar functionality next month
    • Charter and elections process [Lisa/Joe/Dave]
      • Options:
        • Current categories e.g. runtime, lib, etc as we have today
        • Lisa's proposal: Dropping categories and instead:
          • Active contributors to landscape projects
            • Nr commits/PR may not say much / can be gamed
            • Issues: large projects like LLVM may just have small BPF related group
          • Brendan's suggestion: people eligible "you have demonstrated that you furthered the eBPF ecosystem"
          • Questions:
            • Should there be seat categories or just a set of unspecified seats?
            • Voting eligibility based on landscape projects.
              • Alternative: Any active members
              • Alternative: Top N active members
              • Alternative: Should each landscape project get 1 vote (Linux gets 2)?
            • Practical steps:
              • BSC compile two lists of individuals in the eBPF community
                • Nominees (eg 20-50)
                • Voters (eg 200+)
              • Before sending vote out, check with nominees if they are interested in participating.
              • Each year, new BSC reviews these lists.
              • Voters get an email for something like Condorce to rank nominees. Voting system similar to LF TAB.
            • AI(Joe): Begin assembling lists
              • (?) Call for participation
              • Nominees - start a document shared with BSC to collect names
              • Voters - Joe to write a script to pull these from landscape projects
              • Joe to send the list of landscape projects to BSC list to confirm whether we are missing any eBPF community groups
              • No particular seat categories, half/half swap (2yrs, 1yr overlap).
              • Needs charter amendment
            • Deciding split this time
              • Top 4 nominees this time get 2 year terms, next four get 1 year terms.
            • AI(Joe): Prepare an alternate wording for the charter amendment that would capture the removal of the member categories without encoding the election process in the charter.
            • Alexei: We should have a dedicated mailinglist for any voters for the BSC.
              • These members are the core folks who care about eBPF, regardless of whether they are directly on BSC or not.
              • E.g. LSF/MM/BPF, LLVM, gcc, projects, etc.
              • Needs permission from folks we add there
              • Useful also for CFPs etc
              • Dave: Don't see the need for this to be "nominees" list. For voting or generally for active BPF contributors, we need a broader list for voters.
    • IETF BPF WG charter: anything to discuss? [Dave]
    • BPF Conformance project submission [Dave]
      • Goals seem beneficial
      • Would it remain on Alan's github user? He's indicated that he's open to moving it into a BPF foundation / BSC organization in GitHub.
      • BSC voted to accept it as a technical project
      • Next steps
        • AI(Dave): Reach out to Alan regarding legal procedures
        • Following that, requires board approval to finalize
    • Windows roadmap [KP Singh/Dave]

Meeting #34 - 2023-05-03

  • Duration:
  • Chair: Brendan Gregg
  • Participants:
    • Joe Stringer
    • Dave Thaler
    • Dan Brown
    • Lisa Caywood
    • Alexei Starovoitov
    • Andrii Nakryiko
    • KP Singh
    • Daniel Borkmann
  • AGENDA
    • BSC meeting zoom panelist links
      • AI: Dan Brown will check what we are supposed to use and send out more detailed instructions for next time
    • bcc security vulnerability - Brendan
    • LSF/MM/BPF next week!
      • Joe: can raise awareness of BSC
    • BPF governing board
      • point (2): "Voting Process: Importantly on the nominees, and who are all the voters (electorate), avoiding overlap, preferably, between the two, etc."
      • Lisa: what about letting, say, the top 50 contributors to recognized BPF related projects vote on the new BSC seats?

Meeting #33 - 2023-04-19

  • Duration:
  • Chair: Andrii Nakryiko
  • Participants:
    • Alexei Starovoitov
    • Daniel Borkmann
    • Brendan Gregg
    • Joe Stringer
    • KP Singh
    • Dan Brown
    • Dave Thaler
  • AGENDA:
    • eBPF Foundation Governing Board kindly requests BSC to resolve the following in the upcoming BSC meeting(s):
      • Initial term duration: What should be the initial term for the 8 original members (now reduced to 7), and if it is same for all the categories.
        • Straw man (Dave): Set initial 2-year terms, resolve to nominate 1 year vs. 2 year terms for upcoming election. Do election before October.
      • Voting Process: Importantly on the nominees, and who are all the voters (electorate), avoiding overlap, preferably, between the two, etc.
      • Staggered Voting: If all the members be selected in one go or will it be staggered (preferred). If it is staggered, what will be the order?, tentative dates (if possible), etc.
        • Charter says staggered. We had previously discussed splitting each category to allow continuity within a category from one election to the next.
    • From Alexei:
      • Some iovisor folks expressed several concerns (in attached pdf)
      • regarding the structure of BSC.
      • Let's discuss them tomorrow during our meeting.
      • Nature of funding mechanisms
        • BSC desire to be able to direct funds towards development of features that will benefit the eBPF community, regardless of whether the target software is a member of the eBPF foundation
          • Applies to bpftrace etc (also IOVisor)
          • Applies to LLVM, GCC
          • Applies to Linux kernel (verifier improvements, docs)
          • Faster uprobes (no existing project)
          • Security audits
          • eBPF tutorials, training material
          • etc.
        • There should clearly be some base guidelines
          • OSS
          • eBPF as a core technology
          • Statement of Work
          • etc
        • We would need proposed wording + present to board and eventually vote etc. to change the charter.
          • AI(Alexei): Initial wording proposal regarding projects vs funding independent of foundation project or not
      • Lisa: Wrt contractors for certain technical work items, this may be possible by just directly proposing to the board:
        • Cost
        • Duration
        • Expected outcome/SOW
      • Voting membership
        • Technical projects are making this complicated. One idea: Eliminate them.
      • Opening the call to the public
        • Happy to make the meetings transparent for anyone to join in listen-only mode
        • Primary concern is just moderation - Avoid derailing BSC meeting
          • Related: Early BPF summit had targeted attacks, profanity, etc.
        • We can experiment with new Zoom options to test out settings to allow this.
          • Webinar - Host + Panelists + Viewers.
          • Panelists may be invited from prior discussion with BSC (just ask)
          • AI(Dan): Set up the zoom for next meeting

Meeting #32 - 2023-04-05

  • Duration:
  • Chair:
    • KP Singh
  • Participants:
    • Daniel Borkmann
    • Joe Stringer
    • Kenny Paul
    • Dan Brown
    • Brendan Gregg
    • Alexei Starovoitov
    • Andrii Nakryiko
  • AGENDA:

    • eBPF foundation messaging from marketing committee [Dan]

      • Generalization from the kernel to privileged system context
      • Broader message around generality and beyond kernel

    • Iovisor meeting [Kenny]

      • I/O visor can move to BPF-F after sending a formal request
        • Upcoming sub-projects should be able to apply, some logistics need to be figured out.
        • [Joe] We need to make this low overhead and low friction.
        • eBPF or I/O visor is up-to the community of the project
        • Give users an objective criteria to select their foundation.
          • Kenny: Some pros and cons.
          • Projects get legal entities?
            • Clarify if there are legal implications of project joining one foundation or the other.
        • TL; DR roadblock for I/O visor joining eBPF-F has been removed.

    • Update from IETF116 [Dave/Alexei/Daniel]

      • OASIS:
        • Main seen as putting rubber stamp, but less strong as IETF, so vendors would prefer IETF RFC instead as it has wider industry reach
      • Licensing side-meeting:
        • Dual license of the doc seems okay, no road block from IETF side. IETF legal looking into it, but for now no specific issues come to their mind.
        • We might need to put the docs into subdir with ‘note well‘ doc so contributors are aware that their patch will in the end feed into current/future RFCs
        • IETF legal will get back to us within next 2-3 weeks
      • BOF went well, generally no objections from IETF community on forming a working group for the standardization effort
      • Charter side-meeting:
        • Applying feedback from BOF and discussion on deliverables from BPF wg in particular whether charter needs to be refined or scoped down in some areas (like cross-platform map/prog types)
        • Latest:
      • ^^^AI(everyone): Please look at the IETF Charter document and share your thoughts.

    • BPF Technical roadmap details have been filled out for Linux, quick walk through and we should publish it

      • Roadmap
      • Finalize details for windows too.

Meeting #31 - 2023-03-22

  • Duration:
  • Chair:
    • Alexei Starovoitov
  • Participants:
    • David Vernet
    • Andrii Nakryiko
    • Brendan Gregg
    • Alexei Starovoitov
    • Daniel Borkmann
    • Lisa Caywood
    • Dave Havey
    • Dan Brown
    • Joe Stringer
    • Mykola Lysenko
    • Manu Bretelle
  • AGENDA:
    • Lisa: core messaging doc
      • Looks good
      • Next steps is marketing group to iterate to make it more concrete
      • AI(KP): Update with security enhancements based on eBPF.
      • KP: Linux-specific - Kernel modules vs. eBPF implementations. Could be blog posts. Different user journey / developer workflows with benefits when taking an eBPF path.
      • How will it be used?
        • Internal guide for how to approach content creation
      • Misconceptions
        • Security
        • Complex programs
        • Gartner: eBPF – While it is realistic for technology vendors and hyperscalers, most enterprises lack the expertise and skills necessary to use eBPF. Blog
    • IETF <> OASIS as standardization body, pro/con
      • OASIS-OPEN
      • Well-established, published standards for XML, Virt-I/O
      • Process eventually goes through ISO for recognition
      • Relatively short timelines for steps in the process
      • Can we reach out to others that previously went through this process? Get their perspective?
        • Virt-I/O
        • Michael Tsirkin
        • Questions:
          • How was the process for v1.0? What about v1.1?
          • What was the feedback process like with OASIS?
      • Community aspect - who will contribute to the standard
        • How would Technical Advisory Group (TAG) work in OASIS?
      • How do new iterations of documents work?
        • Full doc or extensions/errata/etc.
    • Discuss licensing of BPF doc vs IETF licensing requirements
      • Currently GPL+BSD, question wrt IETF process
      • GPL - makes internal kernel copy clearer
      • BSD-only seems fine, but we would need to discuss with the contributors to the files.
        • Some kernel uapi headers have used single permissive license already, so there is some precedence.
      • non-BSD license is a no-go.
    • BPF Technical Roadmap
      • What's the best way to publish this technical roadmap?
      • Publish to ebpf.foundation
      • KP to work with Dan Brown on this.

Meeting #30 - 2023-03-08

  • Duration:
  • Chair:
    • Joe Stringer
  • Participants:
    • Dave Thaler
    • KP Singh
    • Andrii Nakryiko
    • Brendan Gregg
    • Alexei Starovoitov
    • Daniel Borkmann
    • Lisa Caywood
  • AGENDA:
    • Review previous action items
      • Participate – eBPF
      • FYI - Labs now up
        • We could create more
        • We can use these for IETF hackathon
        • Question(Dave): Does Isovalent want to contribute these to the foundation?
        • FYI also for marketing committee.
        • AI(Daniel): Talk to Liz Rice about this.
    • Update from Lisa - new marketing person from LF
      • Figuring out marketing strategy etc.
    • IETF update
      • Dave: IETF 116 Meeting Agenda
      • 5 interesting items:
        • Hackathon (sat/sun)
        • Welcome (sun)
        • BPF session (mon)
        • Hackdemo Happy Hour
        • Side meeting yet to be scheduled
      • Deadline for drafts 5pm PT next Monday
        • AI(Dave): Snapshots for instruction set + ELF proposals
        • AI(Everyone): Register for remote participation
    • IOVisor subprojects: Invite drafted to IOVisor board
      • Document
      • Next step: Invite Yunsong + Fulvio onto an upcoming BSC session
        • Likely 5 April
        • Sridhar+Kenny should also be invited for LF context
        • AI(Dave): Extend an invite
    • Landscape projects, List thread from Reza Ramezanpour
      • Related PR:
      • Last notes do not have a conclusion
      • Example (KP): Project migrating to BPF. When can it be added as emerging project?
      • Dave: Falco, Calico, even Linux fails this point:
        • The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed.
      • Proposal:
        • "It must encourage the deployment/use of" BPF.
        • CCC language example: “accelerate the adoption of”
        • Two steps:
        • Action on Calico ebpf.io PR - AI(Daniel): Update: Add project Calico to the projects page by frozenprocess · Pull Request #349 · ebpf-io/ebpf.io-website (github.com)
        • Language update to landscape requirements, on both ebpf.io and ebpf.foundation - AI(KP)
        • Guard against “eBPF washing”: Default install on common platforms deploys with BPF programs?
        • Brendan: Title at the top: "The following projects use BPF at the core of the project"
          • Potentially curated list from BSC at the eBPF foundation page
        • Brendan: ‘eBPF recommended project’
        • Lisa: Avoid product / company links. Stick to OSS projects.
        • Dave: foundation currently gives visibility to non-foundation landscape projects, at Projects – eBPF but it’s out of date compared to ebpf.io. Merging the calico PR on ebpf.io will not add Calico to the ebpf.foundation page, notably. Need a separate PR or process to “recognize” it from the foundation.
        • Foundation page should also list ongoing engagements/projects that have BSC involvement
          • BPF standardization @ IETF
          • Technical Roadmap
          • Organization of BPF technical confs
          • …
        • Lisa: Role of the foundation here, messaging.
          • AI(Lisa): Share the brainstorm doc with the BSC list

Meeting #29 - 2023-02-08

  • Duration:
    • 1h
  • Chair:
    • Dave Thaler
  • Participants:
    • Dave Thaler
    • KP Singh
    • Andrii Nakryiko
    • Brendan Gregg
    • Lorenz Bauer
    • Alexei
    • Daniel
  • AGENDA
    • [Lorenz] Employed at Isovalent now
      • This means there are three BSC members, which is against our charter
      • Will come back to this if Joe joins, regarding charter/BSC election status
    • IO Visor discussion
      • Previous AI Joe: reach out Fulvio, plus invitation of both of them to BSC meeting
      • Email from Sridhar re Yunsong Lu
    • IETF prep, report on previous AIs
      • Previous AI Dave: request side-meeting
      • Previous AI Daniel: announcing to bpf@vger to Cc ietf list for doc changes related to standardization
      • Previous AI Dave: till March 13th posting snapshot of internet draft of BPF RFC
      • Status of BOF request
    • [Dave, Daniel] Landscape projects
      • How do we deal with "projects" that have an eBPF component or mode but also have non-eBPF components/modes?
      • Is the answer the same or different for ebpf.io vs ebpf.foundation (incl. BSC eligibility)?
      • Various different cases:
        • Calico
        • Falco
        • clang/LLVM
        • gcc
        • Linux
        • …
    • Continue BPF Technical Roadmap - Google Slides
      • [Dave] Windows BPF roadmap discussion
    • KP: psABI = "processor specific" ABI https://refspecs.linuxfoundation.org/elf/IA64-SysV-psABI.pdf
    • Publishing BSC minutes on bsc/minutes.md at master · ebpffoundation/bsc (github.com) IETF 116 Hackathon | IETF Community Wiki

Meeting #28 - 2023-01-25

  • Duration:
    • 1h
  • Chair:
    • Daniel Borkmann
  • Participants:
    • Brendan Gregg
    • Andrii Nakryiko
    • Dave Thaler
    • Alexei Starovoitov
    • Joe Stringer
    • Lisa Caywood
  • AGENDA
    • [Joe] Update on LF / iovisor <> eBPF foundation
      • Sridhar reached out to Yunsong to check how eBPF foundation + iovisor would work.
      • Yunsong's PoV:
        • Non-overlapping scope where eBPF foundation could subsume iovisor
        • iovisor could join eBPF foundation
        • iovisor scope:
          • Virtualized in-kernel I/O, doesn't strictly say it has to be eBPF
        • Yunsong likely at IETF
      • No reach out yet to Fulvio, discussion continues
      • AI Joe: reach out Fulvio, plus invitation of both of them to BSC meeting
    • [Brendan] Strategy with regards to startups trying to own an important piece of eBPF ecosystem behind closed doors and/or as patented technology
      • Defensive publication for prior art
      • Example:
        • Placing ideas into technical roadmap of BSC
        • Blog posts on ideas
      • Should we file defensive patents as a foundation?
        • Price tag ~100k per patent
        • Foundation potentially could do that if we see fit
      • Encouraging to upstream core infra pieces into kernel, cannot live OOT
        • Example: fast uprobes
    • [Dave] update on prep for IETF and Internet-Draft submission
    • [AI: all] Continue to extend BPF Technical Roadmap - Google Slides
      • [Dave] Windows BPF roadmap discussion
      • To be continued next meeting

Meeting #27 - 2023-01-11

Meeting #26 - 2022-12-14

  • Duration:
    • 1h
  • Chair:
    • Andrii Nakryiko
  • Participants:
    • Andrii Nakryiko
    • Brendan Gregg
    • Daniel Borkmann
    • Dave Thaler
    • Joe Stringer
    • Lorenz Bauer
    • KP Singh
  • AGENDA
    • IOVisor follow ups
      • Joe will ping Kenny, no updates otherwise
      • We need IOVisor projects to better align with BSC charter
    • Faster uprobes (Brendan)
      • The goal is to avoid mode switch overhead caused by normal uprobes (uprobes are many times slower than kprobes to trigger)
        • Andrii: a good chunk of overhead is when there is no NOP that the uprobe code can patch out. If NOP is present ~3x faster.
      • There are new "zero instrumentation APM" companies in the market
        • Based on uprobes, slows down application
        • Slower than Open Telemetry
        • Dave: Should we invite OTel people to BSC meetings?
        • Brendan: OTel already puts hooks into code, could use those for USDT
        • A lot of the industry outside of SF doesn't have the ability to change source, so uprobe based instrumentation is the only things that works
        • Brendan: imagine a "OTel using eBPF project", possible to do and would get a lot of attention
      • This needs user-space BPF engine, and somehow figure out user-kernel BPF interactions
      • KP: teach kernel to JIT BPF program into privileged user-space memory page within process' memory space. Fall back to syscall-like interface if BPF program needs to interact with kernel state (BPF maps, BPF helpers, etc)
      • Is this a possible outreachy / intern project?
    • Andrii: Fedora has rejected enabling frame pointers, but might get a second shot at this
    • [Dave] BPF vs eBPF terminology
      • Lots of discussion, but leaning towards using eBPF in eBPF foundation-derived documentation, but mention that BPF is perfectly valid name as well
      • BPF is often used as a category / broad term, but this means something different to BSD people
    • [Dave] community topics for meetings (my action item) and Foundation info on the BSC
    • [Dave] BPF technical roadmap (Windows portion) - moved to next meeting
    • Next meeting date?
      • 2023-01-11

Meeting #25 - 2022-11-16

  • Duration:
    • 1h
  • Chair:
    • Joe Stringer
  • Participants:
    • Joe Stringer
    • Alexei Starovoitov
    • Dave Thaler
    • Daniel Borkmann
    • KP Singh
    • Lisa Caywood
    • Mykola Lysenko
    • Brendan Gregg
    • Andrii Nakryiko
  • AGENDA:
    • IOVisor project invitations
      • Joining the eBPF Foundation - IOVisor budget steering committee
      • Joining the eBPF Foundation - Projects
      • Next steps:
        • Get OK from BSC on templates
        • For the IOVisor budget steering board, reach out to Kenny Paul to initiate the reach-out
        • BCC, BPFTrace, Kubectl trace and Ply, uBPF:
          • At this point, the effort to include these projects individually in the eBPF foundation does not outweigh the process.
          • It seems like a more promising path to just follow up directly with the IOVisor budget steering board and follow up on alignment/merging on bulk for all projects.
      • AI (Joe): Follow up with Kenny for the first template. Hold back on reaching out to individual projects, pending progress directly with the IOVisor budget steering board.
    • IETF discussion
      • KP, Alexei, Dave attended the side-meeting at IETF last week
      • Dave summary:
      • Q: How hardware industry intends to use eBPF.
        • KP: With NVME there are papers with concrete proposals
        • Potential benefit of ISA standardization outside kernel to expand usage, in domains where we may not have previously considered
      • Alexei: Suggestion - Begin following the IETF procedure but using rST
        • Dave: By the time something becomes an RFC, it is typically defined in XML. That would likely be the target format preferred by IETF. We could use a rst2xml converter to get it in the right format.
      • Mykola: How would we version RFCs over time (particularly after published)? Consider that the ISA may be further expanded.
        • Dave: Couple of options. Brand new RFC, or new extension RFCs. In the initial RFC, specify that the set of opcodes may be expanded in future RFCs. If there are no breaking changes, just create a new "delta" document for the new bits.
        • Can also opt to reserve some portion of the opcodes to avoid standardization for those ranges. Those reserved set are commonly also managed by IANA for allocation in other RFCs.
        • Errata is also possible for minor amendments.
      • Alexei: We still have the option to choose, but given the range of use cases brought up in the IETF session it seems like it is worth seriously considering
        • Routers, edge, wifi, SRv6, NVME
      • Dave:
        • Possible next steps: New mailing list @ IETF
        • Arrange a BoF at the next IETF (March, Yokohama JP)
        • Based on activity on the ML, we could get a slot for a BoF and/or WG. BoF is typically a first step.
        • AI (Dave): Reach out to IETF folks to set up ML
        • AI (Dave): get on the proposed BOF list for IETF 116
    • KP:
    • KP:

Meeting #24 - 2022-11-02

Meeting #23 - 2022-10-19

  • Duration:
    • 1h
  • Chair:
    • Lorenz Bauer
  • Participants:
    • Alexei Starovoitov
    • Andrii Nakriyiko
    • Dave Thaler
    • Daniel Borkmann
    • Joe Stringer
    • Brendan Gregg
    • Lisa Caywood
    • KP Singh
  • AGENDA:
    • Review Action Items
      • Alexei discussion with Christoph Hellwig
        • Hardware vendors (?) would like standardization
        • Amazon, Intel proposal not viable
        • No IETF is not a deal breaker, but preference from Christoph
      • eBPF/IETF discussion call scheduled for 8am Pacific 10/21†
        • Alexei and Dave will attend
    • [Joe, Dave] Report on discussion with Kenny Paul about iovisor foundation
      • Joining the eBPF Foundation - Google Docs
      • Dave: merge iovisor with eBPF foundation might take longer, offer individual projects to migrate
        • Iovisor has money they can't spend
        • Lisa: bureaucratic process, doable but requires timely action
          • Not much interaction between iovisor technical board and LF
        • Joe: has a list of the current technical board members of iovisor.
          • Alexei Starovoitov (Meta)
          • Fulvio Risso (Politecnico di Torino)
          • Yunsong Lu (Huawei)
          • cf. Fri, Oct 7 mail to BSC from Joe with notes from discussion with LF
      • Migrating a project that is already under LF just requires an application to eBPF foundation
      • Lisa: how would we migrate projects? How many can we migrate?
        • Transfer of ownership insider LF
        • We might have to budget funds for this, maybe we can use iovisor funds?
    • [Lorenz] What's happening to the eBPF trademark?
      • Application is happening
    • [Dave] Use of eBPF logo for landscape projects
      • Bill Mulligan asks: "Since there is currently no logo, would you mind adding just the eBPF one for now?"
    • [Dave] ebpf-docs repo created under github ebpffoundation org. Booked Oct. 27 office hours slot.
    • [Daniel] Applied for FOSDEM'23 for eBPF devroom track (Quentin, Florent, Michal, Daniel)
      • Single day, should know whether it's accepted by end of October
      • Maybe use foundation resources to publicize the CFP?
      • Lisa: started a list of foundation relevant events
        • Funnel this back into website / social media
      • Brendan: has a long list, going to filter that down

Meeting #22 - 2022-10-05

  • Duration:
    • 1h
  • Chair:
    • KP Singh
  • Participants:
    • Alexei Starovoitov
    • Brendan Gregg
    • Daniel Borkmann
    • Dave Thaler
    • Joe Stringer
    • Andrii Nakryiko
  • AGENDA:
    • Standardization
      • Can we standardize eBPF in IETF?
        • Lars, chair of IETF, was open to it.
        • Lars is creating a conference call to discuss?
      • Would eBPF people participate in IETF?
      • Is it in scope for IETF?
      • KP: What are the benefits of standardization in IETF? [Not a lawyer disclaimers from all folks]:
        • Not very clear yet.
        • Dave in IETF for a long time.
        • Alexei: Had attended one IETF meeting
          • A lot of discussion about copyright, licensing, trademarks etc.
          • BPF ISA is not copy-righteable
        • IETF does not require IP assignment
          • But it requires disclosure
        • By submitting one, grants permission to IETF to create derivative works.
          • IETF can, legally, change the standard without eBPF foundation consensus.
          • Google created some RFC, IETF created a derivative.
        • Ratification to ISO for standardization
      • Alexei: Linux foundation has some way to make sub foundations to make standards
        • LF won't help us
        • Check with Christoph, if an RFC number is sufficient, this is lighter than becoming an official IETF standard / document.
      • Daniel: What does it mean to have a RFC number?
      • Brendan: What about POSIX?
        • Dave has been involved with POSIX
        • POSIX is published by 3 ISO, IEEE, the Open Group.
          • 3 need to ratify a standard
          • Likely a time intensive process.
          • See Austin Group - Wikipedia for more details on how the 3 orgs together make up the "Austin Group" for POSIX
          • In ISO, the C group is dormant and got merged into the C++ group at present, where Dave lurks on the mailing list
          • Mailing list is not just open to any subscriber, you have to get an invite
      • Alexei: Where is C++ standard happening?
        • ISO
        • List is locked
      • Alexei: Where is Rust doing its standard work?
        • Andrii: There does not appear to be a standard
      • Andrii:
      • NVME: NVM Express – scalable, efficient, and industry standard, specs are free/public apparently
      • Alexei: A ratification helps hardware vendors have more comfort implementing w.r.t stability, legal etc.
        • Lisa: We do have access to LF legal for a consultation and they can guide us.
      • Check with Christoph about the requirements of the nvme standard to take [] reference for eBPF (eBPF doc, independent-steam RFC, IETF RFC, ISO), take least effort to unblock Christoph.
        • Alexei to check with Christoph in person next week.
    • Dave: Feedback on recruit project contributions process
      • uBPF maintainers under iovisor to submit their project
      • uBPF is writing a compliance test suite based on the ISA doc, possibly, in a way to make it generically pluggable.
        • PR in the uBPF repo.
      • This is from Quentin: https://github.com/ebpffoundation/ebpf-docs/tree/main/tools/ebpf-check, compliance check for an ELF file.
      • Consensus: Encourage to contribute to foundation
    • Dave (with help from others) is doing a lot of standard cleanup work.
      • Alexei: needs reviews from other people.
    • Donald proposed help with documents:
      • Propose inviting Donald to BSC meeting, OH is a possibility, not works for all BSC folks though.
    • Daniel: BPF track at FOSDEM conference
      • FOSDEM 2023 - Home
      • KP: Possibly also a keynote speaker
      • Who is the eBPF community manager?
        • Lisa: Marketing committee. Bill is mostly managing it
        • Consensus: List of conferences we should be engaged with
        • Probably a Wiki, your favorite spreadsheet platform
    • More conferences:
      • Scale20x
      • SRE Con
      • FOSS.in (India)
      • Schedule | Linux Foundation Events is scheduled for Open Source SUmmit Europe (co-located with LPC) and had ebpf talks, just search for ebpf on that page

Meeting #21 - 2022-09-21

  • Duration:
    • 1h
  • Chair:
    • Joe Stringer
  • Participants:
    • Alexei Starovoitov
    • Brendan Gregg
    • Daniel Borkmann
    • Dave Thaler
    • KP Singh
    • Andrii Nakryiko
  • AGENDA:
    • (10m) Documenting prog types and map types
      • Issue on ebpf.io issues
      • Email from BSC list, ebpf.io issue
      • Let's direct people to submit patches to the upstream kernel tree to improve this documentation
      • Long-term, cross-platform docs on ebpf.foundation. Dave Thaler is already beginning work in this direction.
    • (40m) Roadmap
      • BPF Technical Roadmap - Google Slides
      • Verification
        • Extension: Observing verifier decisions. Relevant to signing
      • CI
        • Discussion around arm64 cross-arch testing. Progress being made.
        • BSC should engage with s390, ppc64, risc-v, mips maintainers to get missing features like trampolines, atomics etc.
      • More notes added as comments on the roadmap slides
      • Continue the rest of the roadmap discussion next meeting
    • (10m) Election
      • Were any candidates identified during LPC discussion?
        • None in particular
      • Key question: Do we have the BSC makeup that we want?
        • Other OSes (BSD, Apple, Amazon)
        • AI(Dave): Reach out to Apple folks
      • Proposal: Delay election until IOVisor -> BPF Foundation transition occurs
        • Who owns next steps here?
        • AI(Joe): Reach out to Sridhar on template for eligible projects to ask whether they would be interested to join BPF Foundation.
    • IETF BPF Standardization
      • May be difficult based on scope of BPF (not a protocol)

Meeting #20 - 2022-09-07

  • Duration:
    • 1h
  • Chair:
    • Dave Thaler
  • Participants:
    • Alexei Starovoitov
    • Andrii Nakryiko
    • Joe Stringer
    • Brendan Gregg
    • Daniel Borkmann
    • Lorenz Bauer
  • AGENDA:
    • KP: Roadmap slides some slides have been added). Folks please add slides
      • KP might not be able to make it to this instance
    • Lisa Caywood walked us through her email about ebpf.foundation/projects and the BSC discussed her questions
      • Keep landscape projects off foundation projects page
      • Could link from BSC membership page to projects that are represented, e.g., anchor at ebpf.io/projects
      • Daniel suggested we include efforts like BPF standardization
      • Also add documentation
        • Best practices for distributions
        • ?
      • ACTION (?): create a list with relevant links (+blurb?)
        • Below could be under menu item "Initiatives" or "Featured Work" and highlight ongoing efforts, e.g. similar design as project 'boxes'
          • Brendan: BPF guidelines
          • Dave: standardization
          • KP: BPF roadmap
          • Daniel: ecosystem report
          • Daniel: community events
            • Events we co-org, sponsor and plan to increase user base
            • (but isn't that marketing committee, on a different page?)
    • Minutes
    • Public meeting references
      • Typically the Weds biweekly meetings are open to BSC and invitees only (subject to charter)
      • Typically the thurs BPF office hours is completely open with topics proposed ahead of time on a first come, first serve basis. BSC members attend this regularly. Canceled if there is no agenda. We should advertise this more widely.
      • BSC ML: bsc@lists.ebpf.foundation
    • Joe reported on projects and BSC membership in preparation for nominations
      • Two-week period to poll for candidates
      • Goal for candidate pool next BSC meeting, using LPC to recruit/scout out possible candidates

Meeting #19 - 2022-08-24

  • Duration:

    • 1h

  • Chair:

    • Daniel Borkmann

  • Participants:

    • Alexei Starovoitov
    • Dave Thaler
    • Brendan Gregg
    • KP Singh
    • Joe Stringer

  • AGENDA:

  • Shared / honest roadmap across companies to publish.

  • xyz handled by company abc

  • Adding priorities, difficulties

    • Example priority queue, scheduler.. 3 implementations each
    • Don't want important building blocks "owned" by startups and not widely available as OSS

  • Other points not assigned so we can find interested folks in community

  • Platform specific roadmap vs cross-platform roadmap structure

  • Slidedeck & we add own agenda e.g. related to companies

  • BPF standardization effort

  • BPF ecosystem report (collab with marketing team)

  • Technical Projects:

    • eBPF for Windows
    • tbd: iovisor migration

  • BPF community events

    • 4 recurring ongoing conferences for BPF

      • LPC, LSF/MM/BPF, eBPF day, eBPF summit

    • Sponsoring recommendations to GB

      • Currently above 4 approved
      • More tbd

    • Event wishlist for next year:

  • Communication around BPF

    • "BPF is unsafe"
      • Analysis around BPF bugs/exploits from past CVEs and relation around distributions to clear off FUD
        • Example: ChromsOS bug where they disabled lockdown and attacker used bpf_write_user helper
        • Best practices document around reasonable sec posture
        • BPF guidelines
      • Doc around security use cases that can be solved ("BPF is great for sec" writeup)
      • Post on ebpf.foundation website? User story
      • AI starting Google doc
    • "limited because not Turing complete"
      • Examples vs. service mesh [0][1], call w/ analysts, vs. WASM [2]

  • Other items?

    • Deprecation process of iovisor & migration of GH repositories? [Dave/Brendan/others?]

      • Anything to update from LF side?

      • What concrete steps are needed?

        • Covered above already

    • #6 (project nominations 2022) [Joe]

      • Stalled on #6 (comment) ?
      • TBD for next week:
        • Rework PR to update to current list
        • Nominations

Meeting #18 - 2022-08-10

Meeting #17 - 2022-07-27

  • Duration:
    • 1h
  • Chair:
    • Andrii Nakryiko
  • Participants:
    • KP Singh
    • Daniel Borkmann
    • Dave Thaler
    • Joe Stringer
    • Lisa Caywood
    • Brendan Gregg
  • AGENDA:
    • Lisa Caywood on Charter changes
    • Dave Thaler also merged in
    • Sridhar's (remaining) board meeting updates?
      • Budget is in the process of being approved by the board
      • Marketing Committee is currently, per Sridhar: "We have a Marketing Committee (Lisa Caywood, Daniel Havey and Bill Mulligan) " additional nominations welcome
      • Infrastructure cost estimate?
        • CI/CD currently covered by Meta
        • Documentation
        • These are not currently technical projects.
    • ONE summit submissions for BPF (networking conference in Seattle Nov.)
    • eBPF day co-located at KubeCon (CFP open, too)
    • Stack Overflow Collectives: in progress, SO has been made aware

Meeting #16 - 2022-07-13

  • Duration:
    • 1h
  • Chair:
    • Alexei Starovoitov
  • Participants:
    • Lorenz Bauer
    • KP Singh
    • Brendan Gregg
    • Dave Thaler
    • Joe Stringer
    • Andrii Nakryiko
    • Daniel Borkmann
  • AGENDA:
    • Lisa Caywood will join on July 27th (we need to notify her if meeting is canceled)
    • Follow up to "foster eBPF community" discussion from last time
    • BSC re-election nominations
    • [Dave] ebpf.io vs ebpf.foundation website – done?
      • Lorenz: governance, what is ebpf, and docs like ISA, not other things on ebpf.foundation. Also Technical Projects once we get that going.
      • KP: BSC can periodically review project landscape but not be authoritative on the content for it, so ok to keep landscape projects on ebpf.io
      • Lorenz: ok for ebpf.io to have all ebpf related confs, and foundation only have things that foundation has an official role in
    • Ebpf summit, cloud native ebpf day, LPC ebpf track, lsf/mm/bpf are pre-authorized to use bee logo
    • Should we remove projects discussions from High-Pri items above? yes
    • [Lorenz]: Slack is not viable, messages disappearing and not publicly searchable

Meeting #15 - 2022-06-01

  • Duration:
    • 1h
  • Chair:
    • Lorenz Bauer
  • Participants:
    • KP Singhstack
    • Brendan Gregg
    • Dave Thaler
    • Joe Stringer
    • Andrii Nakryiko
  • AGENDA:
    • Discuss AI since last meeting (5 min)
      • Alexei is the next rotating chair for
      • AI Lorenz: ask Thomas about /bsc permissions again
    • Discussion with LF / Lisa Caywood didn't take place since we didn't communicate the invitation clearly enough, need to reschedule.
    • Where do we want to foster the eBPF community? (Lorenz Bauer) (10 min)

      • Current state: knowledge is locked in cilium Slack

      • We need at least the following from the main community hub:

        • Public archive
        • Easily searchable
        • Accessible from countries with strong censorship, e.g. China
        • Ability to export the data
        • Ability to moderate the community (assumption: CoC applies)
        • Accessible from companies, e.g. Meta (?)
        • Access via web interface, native app for iOS / android?
        • A way to get notified of new questions (mail?)
        • Threaded conversations
        • Social features: mark as answered, upvotes
        • Good integration with GitHub, other issue trackers
        • "Neutral ground": primary affiliation should be the foundation so that competitors can use the same community
        • More?

      • Options

      • Proposal: Lorenz takes an action item to compare available platforms and make a recommendation.

    • Can we create a separate budget for eBPF related projects that are hard to get done otherwise? (Lorenz / Joe)
    • Discussed election schedule / process PRs from Joe
      • #5 is accepted an merged
      • #6 needs decision re charter changes, coordination with LF

Meeting #14 - 2022-05-18

  • Duration:
    • 1h
  • Chair:
    • KP Singh
  • Participants:
    • Alexei Starovoitov
    • Brendan Gregg
    • Dave Thaler
    • Joe Stringer
    • Andrii Nakryiko
    • Daniel Borkmann
    • Joe Stringer
  • AGENDA:
    • Discuss the High priority AIs

      • Dave: bsc github ACL issues, Dave could add any reviewers, but was able to "@" people in comments.

      • Strawman project proposal template form discussion (Example: eBPF for Windows)

        • Does every project need to have a charter?

        • LF: This is a template that can be changed any way that the project wants

        • KP: The template should explicitly mention that "it's flexible"

        • Security checklists from OpenSSF

        • Coverity for OSS: https://scan.coverity.com/

        • Review of the PDF form

          • KP: Does it need to be a delta highlighted
          • Dave: recommended

        • Costs

          • Github CI/CD resources (currently in freebie quota)
          • Code coverage licenses

        • Is the process approved? Discuss concerns, vote

          • Daniel: What happens if a process is not done by a single foundation / company?
            • Do the contributors have a vote?
          • Dave: There is a precedent, but not sure how it worked..
          • There were no changes to the form needed, but took longer as it was the first one. LF now has experience, so should hopefully.
          • A signatory was needed.
          • Positive vote for the process
    • Debrief from LSF/MM/BPF (limited time)
      • BPF Standardization
      • Christoph Hellewig indicated that they're willing to contribute.
    • Daniel: At KubeCon
      • Lot's of traction about eBPF
    • Cloud Native eBPF Day youtube playlist: https://youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYjiVZ42wXDp0Qg

Meeting #13 - 2022-04-20

  • Duration:
    • 1h
  • Chair:
    • Joe Stringer
  • Participants:
    • Alexei Starovoitov
    • Brendan Gregg
    • Dave Thaler
    • Joe Stringer
    • Andrii Nakryiko
    • Daniel Borkmann
    • KP Singh
    • Lorenz Bauer
  • AGENDA:
  • (5m) Review action items
    • Charter amendment

      • Technical project criteria, current WIP proposal (Dave):

        • Criteria 1: Trademark transfer
        • Criteria 2: BPF Foundation is primary governance structure
  • (5m) Charter wording amendment
  • (15m) Decide on re-election schedule with appropriate offsets to avoid replacement of the entire committee at once. Needs resolution by Q2 2022. (Governing board ask)
    • The charter has three election cases for the BSC:
      1. Chair, elected from BSC members. BSC already decided to rotate every two weeks, so this one is done.
      1. eBPF Runtime Representative, from active contributors to the runtime.
      1. Additional Project Representatives, from active contributors to additional important projects
    • (Dave): Note (4bi) - For continuity at least half of these should stay the same at any point in time

      • The rest of the categories do not have this constraint

    • Process:
      • Need the outline of how to do the election
        • Project nomination?
        • AI(Joe): Figure out the projects
      • Need to figure out how to stagger (who to re-elect at 1y mark)
        • Volunteers from BSC
      • Need to set a date (proposal: October 2022)
    • Original list from August 2021:
      • Two representatives (the "Kernel Representatives") from the group of eBPF Linux kernel maintainers
        • Daniel Borkmann, Isovalent, eBPF Maintainer

        • Alexei Starovoitov, Facebook, eBPF Maintainer

      • One representative (each a "eBPF Runtime Representative") for each additional open-source eBPF runtime implementation.

        • Dave Thaler, Microsoft, eBPF Runtime for Windows

      • Up to two representatives ("Additional Project Representatives") from additional open source projects that are important to the eBPF ecosystem, as determined by the BSC.
        • Lorenz Bauer, Cloudflare, eBPF Go library & long-time eBPF contributor

        • KP Singh, Google, eBPF LSM

      • Up to three representatives with maintainer status ("Maintainer
      • Representatives") of major eBPF Foundation projects as approved by the BSC.
        • Brendan Gregg, Netflix, bcc/bpftrace
        • Andrii Nakryiko, Facebook, Katran
        • Joe Stringer, Isovalent, Cilium Maintainer
    • Timeline:
      • Members elected: October
      • Election: Mid sept at latest
      • Projects to elect members from: August
  • (30m) Discuss eBPF Technical Roadmap proposals
    • Expanded the list, included a few additional ideas here
    • More may come up during LSF/MM/BPF
  • (5m) Next meeting: 18 May (Avoid overlap with LSF/MM/BPF)

Meeting #12 - 2022-04-06

  • Duration:
    • 1h
  • Chair:
    • Alexei Starovoitov
  • Participants:
    • Brendan Gregg
    • Andrii Nakryiko
    • Dave Thaler
    • Daniel Borkmann
  • AGENDA:
  • ebpf.io / bpf.io - AI Daniel: Move domains to a BSC owned entity so the domains stay in ownership of the eBPF community represented by BSC. Solely BSC is admin & owner. BSC is good with this.
  • Discussion / update around iovisor transferral
  • AI all: Review and extend KP's doc for next time with roadmap items
    • For next meeting we'll go over them and discuss
  • AI Daniel: Create a brand@ebpf.io (list with: 1 legal, 1 marketing person on it)
    • Check with Bill on status of brand guidelines so we can push PR further
  • BSC agreed to use eBee logo for cloud native eBPF day as well as LSF/MM/BPF conference

Meeting #11 - 2022-03-23

  • Duration:
    • 1h
  • Chair:
    • Dave Thaler
  • Participants:
    • Brendan Gregg
    • Andrii Nakryiko
    • Dave Thaler
    • Alexei Starovoitov
    • Joe Stringer
    • KP Singh
  • AGENDA:
  • Review open AI's
  • Takeaways from Governing Board meeting
    • ebpf.io vs ebpf.foundation website
    • Fixing posted charter
    • Proposal to create a marketing committee to manage website, event logistics, press releases (subcommittee tasked with creating actual proposal: Thomas, Lisa, Stephen, Dave)
    • Open question about slack channel vs Cilium
    • Investigating level of LF PM support, leaning towards "Extended Support (level 3)"
  • [Dave] Plan for next open meeting, should we have another discussion of signed programs at an earlier time slot?
    • 9am Pacific Thursdays is bpf office hours, could use that slot for open meetings
    • Currently under "kernel" section but could be moved up on project page to be more general. Keep rule to cancel if no agenda proposal.
    • AI (KP): investigate creating an app script
    • AI (Dave): PR to update socializing wider than "kernel"
    • KP discussing signing programs with various folks
    • AI (KP): pick a week for signed program discussion
  • [Alexei] Times for future BSC meetings
    • Lorenz missed so should we use a different time that is more convenient for Brendan? Back to 1pm Pacific / 7am Australia / 10pm Switz (April 27th)... why do we have a 3 week gap?
    • AI (Daniel): update invite, meet April 6 and 20 (etc) at 1pm Pacific, with 1 hr duration [DONE]
  • [Dave] Charter says that by default "One representative of any Member may observe meetings of the BSC" but the BSC can change that at any time.
    • Discussion: Don't change, don't proactively invite, but allow requests if they come
  • [Dave] Review of updated #1
    • Proposed sequencing:
      • Review proposal
      • Get ebpf for windows example case
      • Approve proposal
      • Go through acceptance process for ebpf for windows
  • Discussion of project scoping
    • Dave's high level strawman from last meeting: a project must be able to argue how it encourages/fosters the deployment and use of eBPF, not just (e.g.) allow using eBPF as an option
    • AI (Dave): get ebpf for windows to fill out forms
    • AI (All): Review the PR
    • CLA/DCO required?
    • IP declarations?
      • Is there potential for intellectual property or patent problems to arise from participation in eBPF foundation?
      • Legal questions, leave to legal review of project submission, not BSC scope.
    • All BSC to review PR to approve this process
      • Hold back on approval until first project works through the process.
      • eBPF for Windows can be guinea pig
    • AI (KP): create a skeleton doc for categories/roadmap of projects

Meeting #10 - 2022-03-09

  • Duration:
    • 1h
  • Chair:
    • Daniel Borkmann
  • Participants:
    • Andrii
    • Alexei
    • Dave
    • Daniel
    • Joe
    • Brendan
  • AI: Ask from LF
    • Offer an open BSC meeting slot. For example once a month.
    • Cadence could be once every 4 weeks
    • How to propose items for discussion
      • For example, BPF office hours
    • Invitation from BSC side
    • AI: doc for topics & contact points to BPF foundation website
  • [Dave] How to best track AI's – follow-up to review above list w/ current state
  • [Dave] eBPF Foundation projects (as opposed to "landscape") - follow up from 2021-10-13 meeting
    • Review of #1
    • General feedback to be lightweight (minimum viable governance), maybe just have one stage for now, not distinguish between levels
    • KP AI: technical project can ask BSC for an invite
    • KP how do we define an overall mission for technical steering committee
      • BSC meeting to chart out goals
    • E.g. encourage deployment of OSS eBPF as technology
    • Technical vs landscape projects
  • BPF + integrity subsystem

Meeting #9 - 2022-02-23

Meeting #8 - 2022-02-09

  • Duration:

    • 1h

  • Chair:

    • Andrii Nakryiko

  • Participants:

    • Andrii Nakryiko

    • Brendan Gregg

    • Daniel Borkmann

    • Dave Thaler

    • KP Singh

    • Joe Stringer

    • Alexei Starovoitov

    • External:

      • John Fastabend (Isovalent)

      • Daniel Havey (Microsoft)

      • Sophie Schmieg (Google)

      • Jason (Google)

      • Devjit (Google Security)

  • Intros

  • KP and Alexei giving overview of previous discussion on BPF signing and trust

    • Various places where things can be signed

    • Chain of trust problem

    • Dave gives overview on hypervisor type 1 and 2 and how HECI mechanism works by signing any executable memory page.

  • Passing baton to guests to explain their use cases and requirements

    • John Fastabend prefers to have a flexibility to decide on policy. E.g., be strict during early boot process, but allow various classes after the system booted.

      • Bpftrace is important use case, blocking it means losing a lot of BPF advantage

      • Suspects a lot of realistic use case involved some amount of dynamism in BPF program generation

      • Dave Thaler: who would be controlling this policy?

        • A: platform team, there could be even multiple tiers of policies; all this is driven by config

      • Q: for dynamic code loading cases why can't this be pre-signed

        • A: the code can be generated on the fly by local daemon, so no way to pre-sign

      • Do we need to support removing trust for some vendors?

      • Brendan: dynamic programs for zero day/sec issue detection should still work as use case (security team)

      • Alexei: would be great to have something like WWW's model for HTTPS certificates

      • Dave: there should be multiple root anchor keys to prevent vendor buy-in

      • Sophie: what about key rotation and expiration?

      • Jason: crypto agility for post-quantum era

      • X.509 discussion, do we need something simpler or better to stick to complicated x.509 which is already used by the kernel

      • Dave: whatever the signing mechanism, ideally it's cross-platform

        • Sophie: there are attacks that use signed certificate from one platform on another one and exploits slight platform-specific differences for an attack

      • Daniel: how to support delegated trust (e.g., bpftrace is trusted and thus all generated progs by bpftrace should be trusted)

        • Individual JITed program's trust should be revoked independently from the trusted JITer (bpftrace)

          • Could be done via certificate revocation

          • Could be done by changing a policy on what the JITer can do

      • Dave: summarizing use case about chain of gatekeepers with hypervisor enforcing which kernels can be loaded, kernel enforcing which boot-time gatekeeper ebpf program can be started, which in turn controls which user-space apps are allowed/trusted, and those in turn might be enforcing which BPF programs are to be trusted

      • Live policy changes can be additive, but subtractive (like revocation) would require a reboot since may already be in a bad state

      • KP: what do we sign? User-space app with BPF object embedded?

        • John: for dynamically JITed programs it doesn't matter because we already trust JITer

      • John: we can combine both gatekeeper app with pre-populated static key ring for something more static and less privileged.

      • John and Dave: multiple gatekeepers are necessary (Google has its own, Cilium has its own, etc)

        • Andrii: should multiple gate keepers be at one system

          • John: let's allow just one

Meeting #7 - 2022-01-26

  • Participants

  • Recap of L3AF

    • GH PR merged

  • BPF Steering (?) Committee

    • KP took part as representative of the BSC

      • Ownership of ebpf.io

      • Rename "ebpf projects" -> "ebpf landscape"

        • There is a desire to distinguish BPF foundation projects from other things

    • We should set up a dedicated group that cares about ebpf.io (Alexei)

  • Signed Programs (Alexei)

    • Ask is from big distros, large companies (Amazon)

    • Only knob right now: disable BPF entirely. There is a risk that others will solve this problem badly for us.

    • Two types:

      • dynamic generation of BPF (cilium, bpftrace)

      • modification of programs (libbpf CO-RE)

    • What is our position on signing programs?

      • KP

        • We need to be able to trust binaries and BPF programs

        • Trusted binary: may load unsigned BPF

        • Untrusted binary: may load signed BPF

        • Trust doesn't have to mean signing: could be apparmor, selinux, etc.

        • How would signing of BPF programs even work if they are shipped as part of a binary?

        • Distro signing is scary

      • Dave

        • Windows and Linux distro (CBL-Mariner)

        • Windows: change of OS memory protected by hypervisor (HVCI)

          • Executable pages (native code) have to be signed

        • Three ways to sign:

          • Sign JITed code (checked by hypervisor)

          • Sign BPF bytecode (checked by kernel, not hypervisor) (RFC by Matteo Croce)

          • Sign package that contains BPF and any user space app (L3AF repository use case)

        • Tangent: if signing happens offline, we could also verify "offline" (REST API for example)

      • Alexei: Let's not spend much time solving for interpreters. Interpreters are wrought with security concerns. Assume there is no interpreter.

      • Lorenz

        • What about developers of eBPF being shut out by Red Hat, etc.?

        • Alexei: all of these things will inevitably be shut down by signed BPF programs.

      • Andrii

        • Trusting user space binary is more general than trusting BPF programs

        • Will Red Hat actually go ahead and come up with a proprietary way of doing things?

          • Alexei thinks yes

      • What if an LSM is the arbitrator of which programs may be loaded? (KP)

        • Have a list of hashes of allowed programs and check against that

      • Signing BPF bytecode could allow novel uses: serverless, enabled by default on Windows, macOS, etc.

      • Integrity vs singing: how should the root of trust work? Any experts in our companies we can reach out to?

      • Organise an open forum / office hours on trust / signing (w/e) where stakeholders can voice their concerns

        • Are there people that have solved a similar problem before?

        • Operating systems

        • Distributors

        • Tool developers

        • This will happen on the next BSC meeting

  • Cross-project engagement - BSC not involved eg with LLVM (Alexei)

    • GCC people want to standardise BTF before adding support

    • LLVM wants more formal engagement from BPF

      • Is eBPF a standalone dialect of C?

      • Clean up BPF documentation

    • Open up BSC mailing list to the public and CC the list for such discussions

  • Extension of cgroup files (KP)

    • Dynamic file creation on sys , proc, cgroup

Meeting #6 - 2022-01-12

  • Duration:

    • 1h

  • Chair:

    • Alexei Starovoitov

  • Participants:

    • Andrii Nakryiko

    • Brendan Gregg

    • Daniel Borkmann

    • Dave Thaler

    • KP Singh

    • Joe Stringer

    • Jason Niesz (Walmart, L3AF maintainer)

    • Brian Merrell (Walmart, L3AF maintainer)

    • Louis Illuzzi (LF Networking, PM for L3AF)

    • Vicky Brasseur (Wipro CTO, L3AF TSC member)

  • Jason presented L3AF

    • Some questions asked:

    • Who is authoritative for what programs run on the node? (answer: admin of machine, who does so via a JSON config file)

    • Would you really trust a public program repository? (unclear, L3AF TSC is discussing same question, cases today use private ones with paths specified by machine admin)

    • Any coordination with Kubernetes or OpenStack? (today is standalone, may integrate with other things in future)

    • How do you config/customize ebpf programs? (today Walmart's programs used with L3AF factor config/customization to be done via maps)

    • Any standard way of communicating with userspace, like protobufs etc? (not yet but L3AF would like to go in that direction)

    • What about gatekeeping, i.e. reject "bad" tools that were rejected by kernel patch requests? Compare to bcc tool repo. Private program repositories are safer, public repository is dangerous/risky if just accepted (could just be reference implementations, always use private repos from L3AFD?)

    • What happens if something other than L3AFD tries to deploy an ebpf program to the kernel? (today, can interfere, L3AF TSC should discuss) can you have SELinux like functionality or just use SELinux to control?

    • How can you disincent/prevent admins from pointing to a public repo and being unsafe?

    • How does it differ from the [bumblebee]{.ul} project?

  • AI(BSC): Deal with L3AF PR for presenting on the website. Note: Scoped to l3afd.

  • AI(L3AF TSC): Discuss dangers of public repo, gatekeeping

  • AI(L3AF TSC): Map formats, userspace<->kernel communication formats, bundling vs. other orchestrators (eg k8s)

Meeting #5 - 2021-12-08

  • Duration:

    • 1h

  • Chair:

    • KP SIngh

  • Participants:

    • Joe Stringer

    • Andrii Nakryiko

    • Brendan Gregg

    • Daniel Borkmann

    • Dave Thaler

    • KP Singh

  • Projects with PRs waiting: [Pull]{.ul} [requests]{.ul} [·]{.ul} [cilium/ebpf.io]{.ul} [(github.com)]{.ul} (10m)

    • [KP]{.ul} [Singh]{.ul}is not listing the ones that have been already approved

    • [https://github.com/ebpf-io/ebpf.io/pull/150]{.ul} (LibXDP)

      • What section does it belong to?

        • BPF libraries is generic BPF

        • Andrii: Vote to stick to core loading libraries

        • Hybrid between the two user journey based split that was discussed.

        • Consensus:

          • Category: Applications

          • State: Emerging

    • [https://github.com/ebpf-io/ebpf.io/pull/140]{.ul} (hBPF)

      • Joe: One author, follows guidelines

      • Would benefit from advertising / awareness

      • Can we use our technical judgement to recommend projects and help them gain traction

      • Daniel: Inspiration on what one can really do with eBPF

        • If the project goes silent, we can possibly remove it

      • Consensus: Merge it in "Core Infrastructure (emerging)"

    • [https://github.com/ebpf-io/ebpf.io/pull/154]{.ul} (L3AF)

      • David and Lorenz have approved

      • Joe: Technical question on how are we encouraging loading / distribution of eBPF programs

        • Signing

        • Repository of eBPF programs, like a store

        • Orchestration of loading / distribution [L3AF is in this category currently.

        • One of the concerns is whether their technical direction shares the same vision as the BSC, and whether their eBPF store diverges communities

      • We can have leaf people here, and talk to them

      • Consensus: Invite L3AF folks to BSC for Jan 5th before making a call

    • Other PRs postponed to next meeting

  • [KP]{.ul} [Singh]{.ul} Proposal to reduce the time spent on the eBPF Website discussions

    • Ideas, invite people and discuss the next big things we can do in eBPF. e.g Interfacing with the scheduler

    • What's the difference in scope between ebpf office hrs vs the BSC meeting?

    • Possible axes on which scopes may be defined:

      • a) tactical (short term) vs strategic (long term direction/vision)

      • b) Q&A vs review of new proposals

      • c) Linux-specific vs not, or even specific to some other platform like Windows, hBPF, MacOS, etc.

    • Proposal to invite people working on long-term direction projects (e.g. BPF signing)

      • Gives us an opportunity to invite experts and improve technical direction

    • Early contenders for invites:

      • Signed BPF programs

      • L3AF

        • They have office hours (Wed's 8am Pacific time) which Dave has been attending

    • Next meeting is canceled (too close to Holidays), meet again on January 5

Action Items:

  • Dave: Invite L3AF folks to the Jan 5th BSC meeting

  • KP: Comment on PRs

  • Someone: Check with Thomas about externally published meeting notes

Meeting #4 - 2021-11-24

Cancelled

Meeting #3 - 2021-11-10

  • Duration:

    • 1h

  • Chair:

    • Joe Stringer

  • Participants:

    • Joe Stringer

    • Andrii Nakryiko

    • Brendan Gregg

    • Daniel Borkmann

    • Dave Thaler

    • KP Singh

  • Review process for PRs to ebpf.io (10m)

    • BSC coordination of review

      • Every BSC member must approve? Two members? One member?

      • Rotation over BSC member to assign "owner" who is responsible to take the item to BSC for discussion?

    • Additional community assistance ([Codeowners]{.ul} [PR]{.ul}, [previous]{.ul} [Cilium]{.ul} [team]{.ul})

    • Brendan: Session' chair's job to look through some PRs before each meeting and figure out how to make incremental progress on the PR list.

      • Opinion: Minimum number of approvals + time window

        • Example, if a proposal is open for 1 week with 1 approval from BSC and it's uncontroversial, merge it.

          • Uncontroversial: Just merge.

            • Examples: Link fixes, typos.

          • Discussion necessary: wait for next meeting.

            • Examples: New projects

        • Goal: Anyone on BSC should be able to just merge uncontroversial items rather than waiting for the next meeting.

    • Today: Repository admins may "merge". BSC members in general are not "Admin".

      • Who should have merge rights?

      • Daniel is OK to merge for now.

    • Let's follow again with Thomas on Governance page for style? AI: Daniel [DONE, pinged Thomas]

  • Removing projects from the website (5m)

    • [GoBPF]{.ul} [has]{.ul} [low]{.ul} [activity]{.ul}

      • Last commit 6 months ago.

      • Meets criteria 1/2/4 for emerging, but not 3 for major (maintained)

        • Open issues / PRs with no review for 3 months?

          • Trigger? After 3 months we can review it.

      • Is there an "emeritus" status?

        • Prefer not, if it's not maintained we do not need to archive it.

      • Mature project: OK to stay. Emerging -> Stopped emerging? Remove from the project listing.

      • Also see: [https://github.com/iovisor/gobpf/issues/304]{.ul}

      • AI: Remove from the repository (Joe) [DONE]

    • Shall we set a periodic reminder to review these? Or rely on community reports?

      • Joe to add 6 month cadence reminder to raise projects for removal

  • General structuring going forward for the ebpf.io projects page (20m)

  • Projects with PRs waiting: [Pull]{.ul} [requests]{.ul} [·]{.ul} [cilium/ebpf.io]{.ul} [(github.com)]{.ul} (25m)

    • Guidelines for new users on how to get started based on specific use cases (Brendan)

      • AI(Brendan): Make a proposal so that we can review it

        • Already posted on Slack, can be shared with those not on Slack

      • How to get started / have success with eBPF.

    • Kubearmor: AI Daniel to hit merge

      • [Daniel: Seems after the repo transfer I cannot merge yet, pinged Thomas]

    • [Libbpfgo]{.ul}: Need to merge #153 above then they can rebase.

    • [Aya]{.ul}:

      • Concern about which features are supported.

      • Submission on ebpf.io seems OK. Start as emerging category. Will need a rebase against Dave's PR. AI(Dave) let them know to rebase [DONE]

Meeting #2 - 2021-10-27

  • Duration:

    • 1h

  • Chair:

    • Dave Thaler

  • Participants:

    • Alexei Starovoitov

    • Andrii Nakryiko

    • Daniel Borkmann

    • Dave Thaler

    • Joe Stringer

    • KP Singh

    • Lorenz Bauer

    • Thomas Graf

  • Meeting duration

    • This meeting and future meetings will target 1h (not 1.5h) duration

  • Where do we publish meeting notes?

  • Technical Project stages and submission procedures (Dave Thaler)

  • General structuring going forward for the ebpf.io projects page (Daniel Borkmann)

    • How do we structure this in an ideal way without convoluting the projects page too much?

      • Major vs emerging is really a separate axis from categories (runtimes, libraries, applications, ...).

      • For a first step, we should have major vs emerging within each category

      • Bcc should move down

      • AI(Andrii): create a PR to move bcc down the page as appropriate

      • Top section should have label of "Applications"

      • AI(Dave): create a PR to add Applications label [DONE: https://github.com/ebpf-io/ebpf.io/pull/153\]

    • Do we split into multiple pages or keep on one page?

      • Consensus is yes there are two different audiences: developers (bpf libs, compiler, runtimes) vs apps (cilium, katran).

        • bpftrace/bpftools is more like sysadmin.

        • Bpftrace and bcctools can be used by sysadmin, so that page can talk about those aspects

      • It is ok to list a project in two places with different descriptions, if two different things are combined in the same repo like in the bcc case

      • Having lots of descriptions can get hard to read. Maybe use tabs? But if only one is shown, that may give a preselection bias, which we want to avoid. We do want descriptions to call out the essential features that are different from the other options in the same category.

        • We should ask the web content team to figure out the UI details, and just give high level requirements to them.

      • Steps in order: 1) add labels, 2) add libbpfgo once PR is updated, 3) add web content tabs or similar once there is an example of both major and emerging in the same category

      • AI(Dave): Create a PR to add major/emerging labels per category [DONE: https://github.com/ebpf-io/ebpf.io/pull/153\]

  • Projects with PRs waiting: [Pull]{.ul} [requests]{.ul} [·]{.ul} [cilium/ebpf.io]{.ul} [(github.com)]{.ul}

    • The BSC discussed the oldest two PRs that proposed project additions:

      • [Kubearmor]{.ul}: meets the criteria for an emerging project.

        • AI(BSC members): Approve PR if looks ok

      • [Libbpfgo]{.ul}: The PR is not ready to merge as is, since the project would fit the "emerging" requirements, but the Go libraries section being modified is in the Major not Emerging section. The overall page needs to be updated first. Also the PR is missing a description of libbpfgo, which would need to be added.

Meeting #1 - 2021-10-13

  • Duration:

    • 1.5h

  • Chair:

    • Daniel Borkmann

  • State:

    • Notes handed over to GB chair

  • Participants:

    • Alexei Starovoitov

    • Andrii Nakryiko

    • Brendan Gregg

    • Daniel Borkmann

    • Dave Thaler

    • Joe Stringer

    • KP Singh

    • Lorenz Bauer

    • Thomas Graf

  • Decide on a regular meeting schedule, e.g. could be once a month starting from kickoff meeting or every two weeks. (Daniel Borkmann)

    • We decided to meet bi-weekly, on the same day and in rotating time zones. This means the meeting time will alternate between 7am Seattle time and 1pm Seattle time.

      • AI: Daniel to send calendar update. [DONE]

  • Chair election process and timeline (Dave Thaler)

    • Our charter states: "The BSC representatives will elect a chair to preside over meetings, ensure minutes are taken and drive the BSC agenda with input from the BSC representatives."

    • Chair (the default answer per charter)? Chair + vice-chair? Co-chairs? Kidding? (should be simple but not needed answer short term, longer term explanation on call, but not urgent) Dave is all for "Minimum Viable Governance"!

      • We decided for a rotating chair to preside over the meeting every 2 weeks in order to balance the overhead. The chair will round robin alphabetically (based on first name).

        • AI: Daniel to create a list in this doc. [DONE]

      • The GB chair's responsibility is to publish the meeting notes handed over by the chair for the public and/or GB.

        • The notes will be published in a Github repository. TBD e.g. we don't have a eBPF foundation Github org yet.

      • The role of the BSC chair is to prepare the agenda for the upcoming BSC meeting, to take notes, and to have the members approve the notes.

  • eBPF Foundation recap and BSC goals (Lorenz Bauer)

    • Since the foundation has been founded, 2 additional members joined, 4 new members are in the onboarding phase. Current budget is multiple hundred-thousand dollars. There are recurring BSC and GB meetings, each has an email list, and G drive. It's on the BSC to define the direction of BPF and how to use the foundation budget (with GB approval).

  • Requirements around use of eBPF bee logo (Dave Thaler)

    • Is this question one for the governing board or the BSC? I suspect it's ultimately a board decision. (Dave Thaler)

      • The official eBPF logo has been donated by Isovalent to the Linux Foundation (LF). During the BSC meeting, we discussed and elaborated on various options around logo usage guidelines (example: [CNCF]{.ul} [logo]{.ul} [usage]{.ul} [guidelines]{.ul} built upon LF brand guidelines).

      • BSC decided to build upon [LF]{.ul} [brand]{.ul} [guidelines]{.ul} as well for the eBPF logo / brand.

        • It is up to the eBPF Foundation to report logo abuse to the LF, e.g. if the composition of the eBPF logo has been modified in context of some commercial / non-open source product, vendor or event. The brand guidelines protect the composition of the bee logo. Technically, it may be considered a new logo if the eBee is taken and added/modified with other elements (Example: variations of the Golang gopher logo from Golang community).

      • AI: Thomas to get back with logo variants and a set of assets in PNG + SVG format that we can put on the ebpf.io website for download as well as setting up a [https://ebpf.io/brand-guidelines/]{.ul} page based on LF brand guidelines.

      • Example of LF not following LF guidelines :) [https://events.linuxfoundation.org/cloud-native-ebpf-day-north-america]{.ul} (The eBPF bee logo has color changed, and the one used in posters on site had yet another color scheme)

<!-- -->

  • The charter mentions "Technical Projects", "eBPF Projects", and "BSC Projects". Is there a difference? (Dave Thaler)

    • The definition of the three was not entirely clear and it was stated that one of the wording was used in a last minute amendment by LF folks.

    • How can we fix the charter? Procedure: We create a redline version with the changes. We vote on it. It passes 70%. Thomas can send it to Todd (LF). LF lawyers review it. Potentially suggest changes. We vote on the changes. We update the website.

    • AI: Thomas to send a charter amendment proposal that BSC can vote on.

    • Also the question came up, can a project be in multiple foundations e.g. eBPF and CNCF? The answer is yes, as there is no requirement to transfer e.g. ownership rights.

  • Technical Project stages and submission procedures (Dave Thaler)

    • Is the list of Technical Projects the same as, or different from, the list at [eBPF]{.ul} [Projects]{.ul} [Directory]{.ul} today? Dave's reading based on our charter is that it's [different]{.ul}.

    • General structuring going forward for the ebpf.io projects page (Daniel Borkmann)

      • Currently, there are [5]{.ul} [pull]{.ul} [requests]{.ul} for eBPF related projects that would like to be added to the [eBPF]{.ul} [projects]{.ul} [page]{.ul}. Additionally, we have the terminology of "technical projects" versus "eBPF projects". The ebpf.io website currently uses "major projects" versus "emerging projects" as well as "core infrastructure" and "eBPF libraries". Given the pull requests which are to be decided, there is a bigger question about how the eBPF projects page should be restructured to better reflect the current landscape.

        • The question was brought up on whether a category-based approach would be a better fit. The [CNCF]{.ul} [Landscape]{.ul} shows an example of how to categorize projects. Also, the question came up on the maturity of projects. For example, should a new eBPF library which only has seen a few users but is under active development be listed next to the existing libraries (Example Brendan brought up: Aya vs libbpf-rs).

        • How do we determine the maturity / production readiness of the project for user recommendation? An example was brought up that we could have a "recommended projects" tag.

      • Are there any indicators for projects that may not be appropriate for listing on the website?

        • Context can be very important. For example, a project aiming to rewrite everything could be good if it is collaborative, or could be bad if it is aiming to fork and divide the community.

        • Also, malware using eBPF would not be considered appropriate.

      • We discussed the minimum bar for projects to be listed. If there are 5 projects that achieve the same goals and fit to requirements 1/2/4 (the ["Requirements]{.ul} [for]{.ul} [a]{.ul} [project]{.ul} [to]{.ul} [be]{.ul} [listed"]{.ul}) on the project criteria, is that good enough to include all of them?

        • It was suggested that a project must be actively maintained (e.g. fixing bugs that are reported).

        • There may also be a notion of subjective element to admitting projects to the eBPF.io projects page, e.g. "the BSC reserves the right to add or remove a project".

        • Overall some of the listed requirements need to be reworked and generally refined and could be more inclusive or better reflect structuring of the projects page, for example, when there are 5 libraries for the same language, do we list all of them and which one do we recommend, etc.

      • In terms of the eBPF projects page we concluded for now that it needs a rework, but we did not conclude yet on how concrete next steps will look like. The discussion is expected to continue in the next BSC meeting(s). We agreed to make it a high priority item on the agenda.

  • The question came up during the discussion of the eBPF projects page with regards to who has rights to review and/or approve eBPF.io pull requests.

    • AI: Joe and Daniel to collect all Github handles from BSC members and to add handles to the project. [DONE]