Почему гостевые ядра VirtualBox работают в кольце 1 вместо кольца 3?

Question

Когда VirtualBox работает на платформе x86 , согласно документации:

Когда включена аппаратная виртуализация (т. Е. VT-x или AMD-V), гипервизор (т. Е. Сам VirtualBox) работает в корневом режиме VMX (он же кольцо -1), а виртуальные машины работают в режиме без полномочий root (он же кольцо 0). , Так работают и другие гипервизоры.

С другой стороны, когда аппаратная виртуализация недоступна, вместо нее используется программная виртуализация и гостевые ядра работают в кольце 1. Из раздела 10.6 ссылки выше:

• Код гостевого кольца 3 запускается без изменений, на полной скорости, насколько это возможно ...

• Для гостевого кода в кольце 0 Oracle VM VirtualBox использует хитрый трюк. Он на самом деле реконфигурирует гостя так, что его код ring-0 вместо этого запускается в ring 1, который обычно не используется в операционных системах x86). В результате, когда код гостевого кольца 0, фактически выполняющий n звонка 1, такой как драйвер гостевого устройства, пытается записать в регистр ввода-вывода или выполнить привилегированную инструкцию, гипервизор Oracle VM VirtualBox в "реальном" кольце 0 может взять на себя

...

• Запуск кода ring 0 в ring 1 вызывает много дополнительных ошибок команд, так как ring 1 не разрешено выполнять какие-либо привилегированные инструкции, из которых ring-0 гостя содержит много. При каждом из этих сбоев VMM должен вмешиваться и эмулировать код для достижения желаемого поведения. Хотя это работает, эмуляция тысяч таких сбоев обходится очень дорого и сильно снижает производительность виртуализированного гостя.

Это интересно, так как это единственное применение кольца 1, с которым я столкнулся.

Согласно приведенным выше разделам, даже если гостевые ядра работают в кольце 1, когда драйвер гостевого устройства пытается выполнить запись в регистр ввода-вывода или выполнить привилегированную инструкцию, гипервизор VirtualBox (кольцо 0) должен вступить во владение. Таким образом, создается впечатление, что потери производительности, связанные с виртуализацией программного обеспечения, будут одинаковыми, если гостевые ядра работают в кольце 1 против кольца 3.

Я наткнулся на этот пост, который говорит:

Кольца 1 и 2 в некотором смысле "в основном" привилегированы. Они могут получить доступ к страницам супервизора, но если они попытаются использовать привилегированную инструкцию, они по-прежнему будут GPF, как кольцо 3. Так что это не плохое место для водителей, как планировала Intel ...

Вопросы

1. Как запуск гостевых ядер в кольце 1 вместо кольца 3 повышает производительность.

2. Каковы последствия безопасности запуска гостевых ядер в кольце 1 (и, следовательно, предоставления гостевым ядрам "доступа к страницам супервизора")?

Answer 1

Я получил несколько очень полезных ответов от людей на # vbox-dev на freenode, а также от других онлайн-ресурсов.

1. Это не улучшает производительность. Как упомянуто в документации VirtualBox, гостевое пространство пользователя работает в кольце 3, а гостевое ядро - в кольце 1. Это позволяет защитить пространство гостевого ядра от гостевого пространства пользователя посредством нумерации страниц (см. Слайд 19). Ниже объясняется, как используется нумерация страниц для достижения этой защиты.

   https://manybutfinite.com/post/cpu-rings-privilege-and-protection/

   Каждая страница памяти представляет собой блок байтов, описываемый записью таблицы страниц, содержащей два поля, связанных с защитой: флаг супервизора и флаг чтения / записи. Флаг supervisor - это основной механизм защиты памяти x86, используемый ядрами. Когда он включен, страница не может быть доступна из кольца 3. Хотя флаг чтения / записи не так важен для обеспечения привилегий, он все же полезен.

2. Хорошей новостью является то, что гости не могут выполнять привилегированные инструкции, поскольку только кольцо 0 может это сделать. Плохая новость заключается в том, что в 64-битной системе кольцо 1 потенциально имеет доступ к страницам памяти хоста. Это связано с тем, что в 64-битном режиме ограничения сегментов больше не применяются, поскольку сегментация в основном заменена на подкачку страниц. К сожалению, подкачка не различает уровни привилегий 0-2, когда речь идет об изоляции памяти. Эта проблема известна как сжатие кольца (см. Слайд 19).

   https://cseweb.ucsd.edu/~jfisherogden/hardwareVirt.pdf

   Кольцевое сжатие

   Чтобы обеспечить изоляцию между виртуальными машинами, VMM работает в кольце 0, а виртуальные машины - в кольце 1 (модель 0/1/3) или в кольце 3 (модель 0/3/3). Хотя модель 0/1/3 проще, ее нельзя использовать при работе в 64-разрядном режиме на процессоре, который поддерживает 64-разрядные расширения архитектуры x86 (AMD64 и EM64T).

   Чтобы защитить VMM от гостевых ОС, можно использовать ограничения на пейджинг или сегмент. Однако ограничения сегментов не поддерживаются в 64-битном режиме, и подкачка на x86 не различает кольца 0, 1 и 2. Это приводит к сжатию кольца, когда гостевая ОС должна работать в кольце 3 без защиты от пользовательских приложений.

   В приведенном выше абзаце предполагается, что в 64-битных системах из-за отбрасывания сегментации и гостевое ядро, и гостевое пользовательское пространство должны работать в кольце 3 (модель 0/3/3), чтобы защитить хост от гостя. Однако см. Слайд 37 показывает, что можно было бы поддерживать модель 0/1/3 и предотвратить доступ кольца 1 к хосту через очень сложную двоичную трансляцию (BT). Возможно, это стратегия, которую реализует VirtualBox?

Важно помнить, что вся эта дискуссия относится только к полной виртуализации программного обеспечения и поэтому очень устарела, так как очень немногие процессоры не поддерживают аппаратную виртуализацию. Как указал кто-то из # vbox-dev.

виртуализация программного обеспечения - умирающий вид, все же. так мало процессоров остались без поддержки аппаратной виртуализации. В какой-то момент нам придется принять трудное решение - поддержание кода стоит времени и денег.