ELF 공유 라이브러리 - PLT의 동기

ELF 공유 라이브러리 - PLT의 동기

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

내가 아는 한, ELF 공유 라이브러리는간접 점프 테이블 사용(Procedure Linkage Table, 즉 PLT)을 사용하여 라이브러리 기능의 지연된 바인딩을 활성화합니다. 목적은 첫 번째 호출에서 함수 위치의 지연 해결을 활성화하면서 코드 조각에서 테이블을 수정하지 않아도 되도록 하는 것 같습니다.

로드 시 또는 첫 번째 함수 호출 시 테이블을 동적으로 생성하는 코드를 사용하는 것이 더 빠르지 않을까요?

가능한 한 프로세스 간에 코드 세그먼트를 공유하는 것입니까(동적 테이블은 프로세스 전용임)? 보안상의 이유로(코드를 작성할 수 있습니까?)실행 가능하면 안 된다- 하지만 JIT는 쓰기 권한을 사용하여 이 작업을 계속 수행합니다.추가 및 제거 가능실제로 프로그램을 시작하기 전에 로더에 의해 로드됨)?

아니면 이들의 조합이고 함수 호출당 작은 성능 향상이 노력할 가치가 없습니까?

답변1

제 생각에는 x86 아키텍처에 대해 이야기하고 있는 것 같습니다.

자체 수정 코드를 가질 수 없습니다보호 모드, 내가 아는 한, 대부분의 UNIX 기반 운영 체제(뿐만 아니라)에서도 이를 사용합니다. 왜냐하면 코드 조각이 다음과 같기 때문입니다.언제나읽기 전용입니다. 로더는 이를 제어할 수 없으며 커널의 메모리 관리 하위 시스템에 의해 처리됩니다.

그러나 "로드할 때 테이블에 대한 코드를 생성"할 수 있다고 하더라도 공유 라이브러리의 전체 목적을 무너뜨리게 됩니다. 이러한 방식으로 각 프로세스는 해당 주소 공간에 라이브러리 함수의 "개인" 복사본을 갖게 되어 메모리 공간을 효과적으로 늘릴 수 있습니다. 공유 라이브러리가 생성되는 이유 중 하나는 이 문제를 해결하는 것입니다.

귀하가 설명하는 전체 프로세스는 매우 복잡하고 현재 사용되는 PLT 접근 방식보다 더 많은 처리 주기가 필요하며 새롭고 흥미로운 보안 문제가 더 많이 발생할 수 있습니다.

답변2

ELF DSO는 플래그(DF_TEXREL)를 사용하여 텍스트 부분(일반적으로 읽기 전용)을 수정하여 재할당해야 함을 알릴 수 있습니다. 그러나 점프 테이블 접근 방식과 PIE 위치 독립적 코드는 더욱 최적화되어야 합니다.

(에서 찾았습니다.http://www.akkadia.org/drepper/dsohowto.pdf, 그러나 다른 출처에서도 이에 대해 언급합니다).

관련 정보