GN⁺ 2024-10-27 | parent | ★ favorite | on: Linux의 새로운 mseal syscall 심층 분석(blog.trailofbits.com)
Hacker News 의견
  • 커널 메일링 리스트에서 "매운 토론"이 언급되었음. 내부자가 이의와 우려를 요약해줄 수 있는지 궁금해하는 의견이 있음. 메일링 리스트는 너무 강렬해서 피하는 경향이 있음

    • 메커니즘 자체는 합리적으로 보이지만, 커널에 이미 존재하지 않는 것이 놀라움
  • Chrome이 이 호출을 원하지만, 공격자가 다른 플래그로 다시 매핑할 수 있으므로 봉인된 페이지를 해제할 수 없음

    • 이는 런타임에 할당된 페이지에 사용할 수 없음을 의미하며, 전체 프로세스 수명 동안 보유할 의도가 없는 한 사용 불가
    • JS 샌드박스와 같은 메모리에는 사용할 수 없음을 의미하는지에 대한 질문이 제기됨
    • Chrome의 메모리/프로세스 관리 방식에 익숙하지 않아 왜 문제가 되지 않는지 확신할 수 없음
  • mseal() 및 그 이후의 기사 링크가 제공됨

  • 현대의 (x86_64) 아키텍처가 안전한 프로그래밍을 촉진하는 많은 기능을 가지고 있음에도 불구하고, 운영 체제가 이러한 호출을 구현해야 한다는 점에 슬픔을 느낌

    • 구식 시스템을 패치하려는 시도가 컴퓨팅의 진보를 저해하고 수십억 명을 위험에 빠뜨림
    • 아키텍처 버그가 존재하지만, 소프트웨어가 현재 기능을 제대로 활용하지 못함
  • mseal 시스템 호출을 LD_PRELOAD 트릭으로 무효화할 수 있는지에 대한 질문이 있음

  • 기사에 있는 mseal() 프로토타입이 문법적으로 올바르지 않음. 첫 번째 인수는 unsigned start addr가 아니라 unsigned long start_addr이어야 함

  • OpenBSD는 오래전부터 이 기능을 가지고 있었음. 왜 Linux에 이제서야 도입되는지에 대한 의문이 제기됨