Hacker News 의견

• Microsoft의 eBPF 지원이 Windows에서 생산 준비가 되면, Windows 보안 소프트웨어도 eBPF로 포팅될 수 있음

  • 현실적이지 않음
  • Windows eBPF의 "hooks"는 패킷 필터링에만 사용됨
  • NT 커널에 연결되는 다른 드라이버와 달리, eBPF는 제한적임
  • eBPF가 커널 공간의 안티멀웨어 드라이버를 대체하려면 많은 시간이 필요함

• eBPF 프로그램이 할 수 있는 최악의 일은 CPU 사이클과 메모리를 더 많이 소비하는 것이라는 주장에 반대함

  • eBPF 프로그램은 무한히 해로울 수 있음
  • 커널에서 BPF로 코드를 이동함으로써 특정 취약점을 완화할 수 있음
  • eBPF 프로그램이 일반적으로 안전하다는 의미는 아님

• Brendan Gregg와 논쟁하기 싫지만, 벤더들이 실패 체인을 완전히 조사하는 포괄적인 접근 방식을 취하길 바람

  • 특정 버그 클래스에서는 CPU 사이클 낭비가 유일한 부정적 결과일 수 있음
  • 나쁜 규칙 집합이 시스템을 망가뜨릴 수 있는 다양한 실패 모드가 있음
  • eBPF 기반 보안 모듈이 많은 벤더에게 적합할 수 있지만, 위험을 이해하는 것이 중요함

• 코드가 깨졌을 때 시스템이 작동하지 않아야 함

  • 의료 기기의 안전 잠금 장치가 작동하지 않으면 전체 시스템이 작동하지 않는 것이 더 나음

• eBPF가 Windows에서 특정 문제를 해결한다고 가정하면, Microsoft는 하위 호환성을 제공하지 않아야 함

  • 하위 호환성은 Windows 세계에서 중요한 문제임
  • 오래된 NT 코드와 접근 방식을 정리하는 것이 더 유익함

• eBPF 프로그램은 소프트웨어 검증기에 의해 안전하게 체크되고 샌드박스에서 실행되므로 시스템 전체를 크래시할 수 없음

  • 운영 체제의 목적 중 하나는 소프트웨어를 감시하는 것임
  • 복잡성을 줄이는 것이 더 나음

• 새로운 기술이 필요하지 않음

  • 기본적인 품질 관리 방법을 사용해야 함

• 금요일을 쉬는 날로 정해 더 많은 사람들이 생각할 시간을 가질 수 있도록 해야 함

• eBPF에 버그가 있으면 Windows 커널 크래시를 유발할 수 있음

• 부팅 시 필터가 로드되고 모든 것에 연결되면 시스템을 잠글 수 있음

  • Microsoft가 복구에 필요한 필수 항목을 포함하는 하드코딩된 화이트리스트를 포함하면 버그 수정이 더 쉬워질 수 있음