(이것은 x86-64 Linux의 맥락입니다.)
저는 매우 안정적이고 생성된 어셈블리를 완전히 제어할 수 있는 사용자 공간 실행 파일을 작성하려고 합니다. 자동 스택 할당에 의존하고 싶지 않기 때문에 스택을 알려진 위치에 배치하고 싶습니다. 내 프로그램이 (정확하게는) 최대 414바이트의 스택 공간을 사용한다고 계산한다고 가정해 보겠습니다. .bss 섹션에 414바이트를 할당하고 RSP를 맨 위로 가리키는 것이 안전합니까? 나는 스택 관리가 언제든지 이 영역 외부의 바이트에 접근하지 않도록 하고 싶습니다.
확신하지만내 거프로그램은 이 영역 외부에 쓰지 않으며 일부 시스템 호출(instructions 사용)을 수행해야 하며 syscall적어도 커널 코드의 일부는 호출 실행 가능 컨텍스트에서 실행되는 것 같습니다. 내 스택이 깨질까요?
또한 인터럽트는 프로그램의 어느 지점에서나 발생할 수 있으며 "빨간색 영역" 뒤에 숨은 이야기는 인터럽트 핸들러가 RSP-128 외부의 임의의 넓은 영역에 자유롭게 쓸 수 있으며 잠재적으로 내 데이터를 손상시킬 수 있음을 나타내는 것 같습니다. 이 동작에 대해 어떤 보증이 있습니까?
답변1
.bss 섹션에 414바이트를 할당하고 RSP를 맨 위로 가리키는 것이 안전합니까?
실행 파일에 대한 모든 것을 제어하고 아마도 어떤 라이브러리에 대해서도 링크하지 않으므로 괜찮을 것입니다. 특히,MAP_STACK mmap깃발 현재는 효과 없음, 읽고 쓸 수 있는 모든 페이지를 스택에 사용할 수 있습니다.
적어도 커널 코드의 일부는 호출 실행 가능 컨텍스트에서 실행됩니다.
예, 시스템 호출은 호출 프로세스 내에서 실행되지만...
내 스택이 깨질까요?
...커널 실행자체 스택에— 그렇지 않으면 시스템 호출 실행 중에 사용자 공간이 커널 내부 값을 변경할 수 있습니다! 일부 시스템 호출은 스택에 관심을 두지만 사용자 공간 스택을 건드리지 않습니다(clone특히).
또한 인터럽트는 프로그램의 어느 지점에서나 발생할 수 있으며 "빨간색 영역" 뒤에 숨은 이야기는 인터럽트 핸들러가 RSP-128 외부의 임의의 넓은 영역에 자유롭게 쓸 수 있으며 잠재적으로 내 데이터를 손상시킬 수 있음을 나타내는 것 같습니다. 이 동작에 대해 어떤 보증이 있습니까?
하드웨어 인터럽트도 자체 스택을 사용하므로 사용자도 안전합니다. 신호 처리기로부터 자신을 보호하려면 다음을 사용하여 개인 스택을 설정할 수 있습니다.sigaltstack.