▲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에 이제서야 도입되는지에 대한 의문이 제기됨
Hacker News 의견
커널 메일링 리스트에서 "매운 토론"이 언급되었음. 내부자가 이의와 우려를 요약해줄 수 있는지 궁금해하는 의견이 있음. 메일링 리스트는 너무 강렬해서 피하는 경향이 있음
Chrome이 이 호출을 원하지만, 공격자가 다른 플래그로 다시 매핑할 수 있으므로 봉인된 페이지를 해제할 수 없음
mseal() 및 그 이후의 기사 링크가 제공됨
현대의 (x86_64) 아키텍처가 안전한 프로그래밍을 촉진하는 많은 기능을 가지고 있음에도 불구하고, 운영 체제가 이러한 호출을 구현해야 한다는 점에 슬픔을 느낌
mseal시스템 호출을 LD_PRELOAD 트릭으로 무효화할 수 있는지에 대한 질문이 있음기사에 있는 mseal() 프로토타입이 문법적으로 올바르지 않음. 첫 번째 인수는
unsigned start addr가 아니라unsigned long start_addr이어야 함OpenBSD는 오래전부터 이 기능을 가지고 있었음. 왜 Linux에 이제서야 도입되는지에 대한 의문이 제기됨