You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Attendees & Representation. Please add your name to the attendance table below.


LF Staff: LJ Illuzzi 

Agenda

  • LF Antitrust Policy

  • Meeting note taker

  • Welcome to new attendees

  • LF ONE Summit recording to be added in l3af.io

  • Last week TSC output

    • Standardize Interface for communication between BPF maps from user-space <-> eBPF kernel space
    • Gate keeping and security and concerns around public market place
    • How do we handle other programs that might load eBPF and conflict with l3AF. Do we block them?
    • How are we different from BumbleBee?
    • Boiler plate generator that generates all the bpf_tail call and manage the maps
    • Here's the notes from the BSC minutes, let Dave know if any corrections:
      • 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 project?
  • PR to add l3af as one of the projects under ebpf.io
  • Building eBPF programs (suggested by Luka from Sartura; they have a tool they find helpful)
  • Status of PEN
  • LFN Induction
    • Setup separate call. Propose weekly on Tuesday 10:30 to 11:30am ET/ 7:30amPT / 9pm IST
    • First meeting 01/25
  • General Topics (cover as needed)

    • Use Cases

    • Roadmap

    • Project structure

      • Governance

      • Technical Steering Committee

Minutes/Updates

  • Key takeaways BSC meeting

    • Standardized communication for maps from UM to KM
      • Good to have a map level spec around map and data types
      • Vicky: How useful outside of L3AF? Would be good to have a de-facto standard.
      • Agree, standards would be helpful.
      • Louis: Create sub-project to write documents?
      • Karan:  Does this change for Windows?
      • Dave: Believe the answer is no.
        • Both use libBPF
    • Gatekeeping, security and public repository
      • Different types of signing.
      • Just because a program is in a public repo - it would be dangerous to install
      • Have a private repo and the only thing that pulls from a public repo is one that is trusted by admin
      • This isn't like an app store - this is kernel stuff
      • Karan: Could we allow only trusted sources to put stuff into a public repo
      • Dave: That would not change the security situation because trust is not transitive.
      • Karan: Could we have a hybrid model?
      • Dave: The BSC might go along with this, but I don't recommend it.
      • Vicky: Experience does not bear out trusting public repositories.
        • Incredibly rife with situations where security issues arise. We need the possibility for people to have private models
        • If we don't set up the pubilc repo then someone else will. We should do it so that we can at least have some safeguards for security.
        • At the same time users should do their own testing and evaluation.

Action Items

  • LJ Illuzzihave draft working documents ready for LFN Induction meeting on 01/25, including proposed timeline

Future Agenda Items


  • No labels