Các vòng đặc quyền của CPU: Tại sao các vòng 1 và 2 không được sử dụng?


102

Một số câu hỏi liên quan đến đặc quyền CPU x86 đổ chuông:

  • Tại sao vòng 1 và vòng 2 không được hầu hết các hệ điều hành sử dụng? Nó chỉ để duy trì khả năng tương thích của mã với các kiến ​​trúc khác, hay có lý do nào tốt hơn?

  • Có hệ điều hành nào thực sự sử dụng các vòng đó không? Hay chúng hoàn toàn không được sử dụng?


Câu trả lời:


110

Là một người có sở thích viết về hệ điều hành, tôi nhận thấy rằng vì phân trang (một phần chính của mô hình bảo vệ hiện đại) chỉ có khái niệm đặc quyền (vòng 0,1,2) và không đặc quyền, lợi ích cho vòng 1 và 2 đã giảm đi đáng kể.

Mục đích của Intel khi có vòng 1 và 2 là để hệ điều hành đặt các trình điều khiển thiết bị ở mức đó, vì vậy chúng có đặc quyền, nhưng hơi tách biệt với phần còn lại của mã nhân.

Nhẫn 1 và 2 là một cách, "chủ yếu là" đặc quyền. Họ có thể truy cập các trang giám sát, nhưng nếu họ cố gắng sử dụng một chỉ dẫn đặc quyền, họ vẫn GPF như vòng 3. Vì vậy, nó không phải là một nơi tồi tệ cho các trình điều khiển như Intel đã lên kế hoạch ...

Điều đó nói rằng, chúng chắc chắn có công dụng trong một số thiết kế. Trên thực tế, không phải lúc nào OS cũng trực tiếp. Ví dụ, VirtualBox , một Máy ảo , đặt mã hạt nhân khách ở vòng 1. Tôi cũng chắc chắn rằng một số hệ điều hành có sử dụng chúng, tôi chỉ không nghĩ rằng nó là một thiết kế phổ biến vào lúc này.


28
wHOA VirtualBox sử dụng vòng 1 ?! Đó là sự tuyệt vời thuần túy !! Cảm ơn rất nhiều vì thông tin, đó là một câu trả lời tuyệt vời! +1
dùng541686

10
OS / 2 đã sử dụng Ring 2 rộng rãi cho mã I / O. Đây là lý do tại sao rất khó để ảo hóa.
kinokijuf

Từ superuser.com/questions/1402537/… : "Chạy mã chuông 0 trong vòng 1 gây ra nhiều lỗi hướng dẫn bổ sung, vì vòng 1 không được phép thực hiện bất kỳ hướng dẫn đặc quyền nào, trong đó chuông-0 của khách chứa rất nhiều. Với mỗi đối với những lỗi này, VMM phải bước vào và mô phỏng mã để đạt được hành vi mong muốn. Mặc dù điều này hoạt động nhưng việc mô phỏng hàng nghìn lỗi này rất tốn kém và ảnh hưởng nghiêm trọng đến hiệu suất của khách ảo hóa. "
Dustin Oprea

24

Từ quan điểm của thiết kế hệ điều hành, có nhiều vòng đặc quyền là một điều kỳ lạ của x86 - hầu hết các CPU khác chỉ có hai chế độ (người giám sát và người dùng). Do đó, việc thiết kế một hệ điều hành để yêu cầu nhiều chế độ đặc quyền sẽ ngay lập tức ngăn nó được chuyển sang bất kỳ CPU nào khác. Ngoài ra, nhiều gói ảo hóa hiện đại không mô phỏng chính xác các mức đặc quyền khác 0 và 3, khiến hệ điều hành sử dụng các mức này khó kiểm tra hơn nhiều.


7

Theo trang Wikipedia về Ring Security , vòng 1 và 2 được sử dụng cho trình điều khiển (vòng 1), hệ điều hành khách (vòng 1) và mã đặc quyền i / o (vòng 2), người giám sát ngồi ở -1/0 (tùy thuộc vào hyper-visor) không phải là 1 như tôi đã nêu trước đây.

Tuy nhiên, hai chiếc nhẫn phụ không bao giờ thực sự hữu ích và do đó hiếm khi được sử dụng. TBH, hầu hết các mã sử dụng vòng 1 và vòng 2, những mã này đã bán thay thế chúng từ mục đích sử dụng ban đầu của chúng (chẳng hạn như các siêu giám sát). Hầu hết mã cửa sổ ngày nay dường như coi hệ thống chỉ có hai cấp (nhân và người dùng), có thể là do chi phí liên quan đến việc nhập và rời vùng đất nhân.


1
Tôi nghĩ rằng bạn đã bỏ lỡ một -nơi nào đó. Bạn có chắc chắn những người giám sát sử dụng vòng 1?
user541686,

Heh, không suy nghĩ, nên siêu Bọc trong -1 và hệ điều hành khách trong 1, sẽ cập nhật nhanh chóng mà
Necrolis

4
Windows chỉ sử dụng hai vòng vì nó được thiết kế để chạy trên các bộ xử lý khác (hiện không còn tồn tại) chỉ có hai vòng.
David

Trong tâm trí của tôi, có rất ít chi phí để chuyển đổi chế độ. Theo những gì tôi hiểu, chỉ có phần cứng mới có thể gán nhiều đặc quyền đặc quyền hơn cho cpu (như nếu xảy ra ngắt kết thúc IO). Nếu việc chuyển đổi đặc quyền này xảy ra trong phần cứng, tôi nghi ngờ rằng việc chuyển vòng không phải là chuyện nhỏ. Tôi nghĩ rằng Windows, Linux hoặc MacOS chỉ sử dụng hai cực đoan nhất trong số các vòng vì các kiến ​​trúc sư dành các vòng ở giữa cho những thứ như ảo hóa được lưu trữ trên hệ điều hành.
Nate Symer
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.