ELF 공유 라이브러리-PLT에 대한 동기


11

동적으로 링크 된 라이브러리에서 함수 호출 속도를 높이기 위해 자체 수정 코드를 사용할 수 있습니까?

내가 이해하는 한 ELF 공유 라이브러리 는 일종의 간접 점프 테이블 (프로 시저 연결 테이블 또는 PLT)을 사용하여 라이브러리 함수의 지연 바인딩을 가능하게합니다. 목적은 코드 세그먼트에서 테이블을 수정하지 않고도 첫 번째 호출에서 함수 위치의 지연 해결을 가능하게하는 것 같습니다.

로드 타임 또는 첫 번째 함수 호출에서 해당 테이블에 대한 코드를 동적으로 생성하는 것이 더 빠르지 않습니까?

프로세스간에 코드 세그먼트를 가능한 많이 공유 할 수 있습니까 (동적 테이블은 프로세스 전용)? 보안상의 이유입니까 (쓰기 가능한 코드 는 실행 가능해서는 안되지만 JIT는 항상 그렇게하고 실제로 프로그램을 시작하기 전에 로더 가 쓰기 권한 을 추가하고 제거 할 수 있습니까)?

아니면 그것들의 조합입니까? 함수 호출 당 작은 성능 이득은 그만한 가치가 없을까요?

답변:


8

우리가 x86 아키텍처에 대해 이야기하고 있다고 가정합니다.

코드 세그먼트는 항상 읽기 전용 이기 때문에 내가 알고있는 대부분의 UNIX 기반 운영 체제에서 사용되는 보호 모드 에서 자체 수정 코드를 사용할 수 없습니다 . 로더는 -it가 커널의 메모리 관리 서브 시스템에 의해 처리되는 것으로 제어하지 않습니다.

그러나 "로드 타임에 해당 테이블에 대한 코드를 만들 수있다"고해도 공유 라이브러리의 전체 목적을 무시할 수 있습니다. 이러한 방식으로 각 프로세스는 주소 공간에 라이브러리 기능의 "비공개"복사본을 가지게되므로 공유 라이브러리가 만들어진 이유 중 하나 인 메모리 풋 프린트를 효과적으로 증가시킬 수 있습니다.

설명하는 전체 프로세스는 상당히 복잡하며 오늘날 사용되는 PLT 방법보다 더 많은 처리주기가 필요하며 새롭고 흥미로운 보안 문제가 더 많이 발생할 수 있습니다.


2
mprotect (2) 시스템 호출을 사용하여 .text 세그먼트 페이지를 쓰기 가능하고 실행 가능하게 만들 수 있습니다.
브루스 에디 거

1
맞습니다. 아마도 일반적인 UNIX 기반 시스템에서는 제대로 작동하지만 누군가가 mprotect (2)에 대한 제한을 적용하는 PaX로 시스템을 강화하려고하면 전체 연결 프로세스가 중단 될 수 있습니다.
dkaragasidis

(그것은 내 이전의 코멘트에 @BruceEdiger을 언급 놓친 것 같다)
dkaragasidis

1

ELF DSO는 플래그 (DF_TEXREL)를 사용하여 텍스트 섹션 (일반적으로 읽기 전용)을 수정하여 재배치가 필요함을 알릴 수 있습니다. 그러나 PIE 위치 독립 코드와 함께 점프 테이블 접근 방식이 더 최적이어야합니다.

( http://www.akkadia.org/drepper/dsohowto.pdf 에서 발견 되었지만 다른 리소스에서도 언급됩니다).

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.