Làm cách nào để kiểm tra xem Linux đang chạy kernel đã được tải bằng kexec chưa?


7

Bằng cách kiểm tra tôi có nghĩa là một cái gì đó khá vững chắc, tức là, cố gắng phân tích cấu hình của trình tải hoặc các tệp kernel có sẵn và khớp với đầu ra của uname rõ ràng không phải là một tùy chọn.


dmesg hay cat /proc/cmdline?
SHW

Tôi không có kexec theo ý của tôi để kiểm tra. Do đó yêu cầu kiểm tra một trong hai dmesghoặc cat /proc/cmdline?
SHW

Nhiều hệ thống dựa trên POWER khởi động kernel "thực" bằng cách sử dụng kexecbộ tải khởi động dựa trên Linux.
Simon Richter

Câu trả lời:


7

Trong trường hợp chung, không, điều đó là không thể, bởi vì không có gì đáng tin cậy ở trạng thái trước đó và không thể phân biệt được với khởi động lại thông thường.

Chỉ cần nói ví dụ bạn có một hệ thống KHÔNG xóa RAM khi khởi động (xóa bộ nhớ khi khởi động được yêu cầu bởi một số thông số khởi động an toàn, v.v.); Quá trình khởi động ban đầu và mỗi lần khởi động lại bình thường thường sẽ xảy ra ở cùng một độ lệch và xóa sạch mọi thứ từ lần khởi động trước theo thời gian. Hạt nhân sẽ hầu như luôn được tải tại cùng một địa chỉ.

Bây giờ hãy xem xét kexec thay vì khởi động lại bình thường và nhận ra rằng mọi thứ sẽ kết thúc ở cùng một độ lệch, và hầu như không thể phân biệt được.

Có trường hợp đặc biệt nào mà kexec CÓ THỂ được phát hiện không? ĐÚNG!

  • Kdump tải rõ ràng kernel mới tại một địa chỉ khác và hy vọng sẽ bảo toàn bộ nhớ của kernel trước đó để nắm bắt trạng thái lỗi.
  • Nếu BIOS và kernel khởi tạo phần cứng khác nhau thì rõ ràng (rõ ràng) có thể được ghi nhận vì sẽ có thay đổi trên mỗi lần khởi động với công tắc "thường / kexec".
  • Như một ví dụ cụ thể về điều này, bộ đệm khung EFI chắc chắn bị thay đổi bởi kernel trong khi khởi động và không bao giờ trở lại trạng thái ban đầu trên kexec.
  • Hệ quả của điều này là, nếu bạn không điều khiển khởi động của kernel kexec'd và nó chạm vào phần cứng, thì gần như không có cách nào để quyết định xem đó là boot thật hay boot kexec .

Như một bản demo, tôi đã khởi động một VM với kernel, bắt dmesg, sau đó ngay lập tức thực hiện một kexec cứng trên nó, bắt dmesg một lần nữa. Đây là sự khác biệt giữa hai lần chạy của dmesg: https://gist.github.com/robbat2/7609be2715591eac8ace3f46e852c549


> Điều này chỉ cho phép bạn phát hiện khởi động lại FIRST với kexec - tại sao bạn nhấn mạnh FIRST? Nếu bạn khởi động bình thường, trạng thái sẽ trở lại BIOS và nó có thể được phát hiện. Vì vậy, mỗi lần bạn biết liệu nó không phải là BIOS khởi động. ;)
poige

@poige Tôi đã cập nhật câu trả lời của mình vì hộp bình luận này quá ngắn.
robbat2

Vẫn không chắc tại sao. kexec trông giống nhau cho dù chúng có ít liên tiếp hay chỉ độc thân. Trong trường hợp bạn khởi động w / o kexec dmesg sẽ khác. Vì vậy, đó là lý do tại sao tôi thấy không có điểm nào trong việc nhấn mạnh này
poige

2

Tôi chỉ tìm thấy câu trả lời trong mã và tôi muốn chia sẻ.

Để kiểm tra bộ tải khởi động được sử dụng để tải kernel đang chạy là gì, hãy kiểm tra:

/proc/sys/kernel/bootloader_type

Sau đó, bạn cần phải dịch chuyển 4 bit sang phải để lấy bootloader_type, được mô tả trong tệp sau cho x86 (trong cây kernel): Documentation / x86 / boot.rst [0]

Trình tải kexec sẽ hiển thị 0xD sau khi dịch chuyển (từ mã công cụ kexec, chúng ta có thể thấy nó được định nghĩa là #define LOADER_TYPE_KEXEC 0x0D).

Thật không may, đó chỉ là một trò lừa x86 !!! Hy vọng nó giúp.

[0] www.kernel.org/doc/Documentation/x86/boot.rst


không cần phải xin lỗi ở đây, sẽ hợp lý hơn khi cung cấp cơ hội trả lời một chủ đề thay vì thúc giục mọi người bỏ qua việc chia sẻ phát hiện của họ hoặc thúc giục họ mở các phiên bản mới của cùng một câu hỏi. Cá nhân tôi đã thấy điều này trên diễn đàn của Apple mà tôi không thích một phần do giới hạn này (nhưng không chỉ).
poige

1
Tôi đồng ý với bạn @poige hehe Cảm ơn =)
guipy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.