확인한다는 것은 매우 신뢰할 수 있는 것을 의미합니다. 즉, 로더의 구성이나 사용 가능한 커널 파일을 분석하고 uname의 출력을 일치시키려는 것은 분명히 옵션이 아닙니다.
답변1
일반적인 경우에는 아니요. 이전 상태 중 어느 것도 신뢰할 수 없고 정기적인 다시 시작과 구별할 수 없기 때문에 이는 불가능합니다.
예를 들어, 시스템은 부팅 시 RAM을 지우지 않습니다(특정 보안 부팅 사양 등에서는 부팅 시 메모리를 지워야 함). 일반적으로 모든 일반 재부팅은 동일한 오프셋에서 발생하며 시간이 지나면 모든 내용이 지워집니다. 마지막 부팅부터. 커널 자체는 거의 항상 동일한 주소에 로드됩니다.
이제 일반적인 재부팅 대신 kexec를 사용하는 것을 고려하고 모든 것이 동일한 오프셋으로 끝나고 본질적으로 구별할 수 없어야 한다는 점을 인식하십시오.
kexec를 감지할 수 있는 특별한 경우가 있습니까? 예!
- Kdump는 다른 주소에 새 커널을 명시적으로 로드하고 이전 커널의 메모리를 보존하여 오류 조건을 포착합니다.
- "usual/kexec" 스위치를 사용하여 부팅할 때마다 하드웨어가 변경되므로 BIOS와 커널이 하드웨어를 다르게 초기화하는 경우 이를 (분명히) 알 수 있습니다.
- 구체적인 예로 EFI 프레임 버퍼는 부팅 중에 커널에 의해 확실히 변경되며 kexec에서 원래 상태로 반환되지 않습니다.
- 이것에서 얻을 수 있는 점은 kexec 커널의 실행을 제어하지 않고 하드웨어에 닿는 경우 나중에 그것이 kexec 커널인지 여부를 확인할 방법이 거의 없다는 것입니다.진짜부팅 또는프로그램 실행시작합니다.
데모로서 커널이 있는 가상 머신을 시작하고 dmesg를 캡처한 다음 즉시 하드 kexec하고 dmesg를 다시 캡처했습니다. dmesg를 두 번 실행하는 것의 차이점은 다음과 같습니다.https://gist.github.com/robbat2/7609be2715591eac8ace3f46e852c549
답변2
방금 코드에서 답을 찾았고 이를 공유하고 싶었습니다.
실행 중인 커널을 로드하는 데 사용되는 부트로더를 확인하려면 다음을 확인하세요.
/proc/sys/kernel/bootloader_type
그런 다음 bootloader_type을 얻으려면 4비트의 오른쪽 시프트가 필요합니다. 이는 다음 x86 파일(커널 트리)에 설명되어 있습니다.문서/x86/boot.rst
kexec 로더는 이동 후 0xD를 표시합니다(kexec-tools 코드에서 #define LOADER_TYPE_KEXEC 0x0D로 정의되어 있음을 볼 수 있습니다).
불행히도 이것은 x86 전용 트릭입니다! 도움이 되었기를 바랍니다.