LINUX.ORG.RU

Есть ли какие-либо преимущества по безопасности внутри гостя при эмуляции другой архитектуры?

 , , , ,


0

1

Если, например, на X86 хостинге запускать qemu-system-arm с полной эмуляцией даже ядра.

Или наоборот на одноплатнике запускать bochs для эмуляции X86, когда нужен именно X86 для каких либо программ.

Но, наверно, еще лучше запускать на более редкой, чем X86 «серверной» архитектуре, например, на ARMv7 эмуляцию каких-нибудь совсем уж редких (именно для серверов) архитектур типа MIPS и т.п.? Понятно, что тормоза и более заметные, чем в OpenBSD, но секурность же так ее перетак? OpenBSD покажется супербыстрой после этого.

Повышается ли при этом безопасность в плане защиты от встроенных в процессоры закладок типа рутования гостя извне виртуалки через God mode?

Например, представим, что SSH сервер внутри ARM гостя каким-то образом закидали некими запросами (переполнение буфера и т.п.) и он попытался запустить код, который запускать не должен был с точки зрения админа.

1) Код внешней атаки был рассчитан на X86, чтобы переключиться на root с помощью год моде, а там ARM - обломс ?

2) Атакующие переделали код внешней атаки, чтобы он был рассчитан на ARM, чтобы переключиться на root с помощью год моде или какого-нибудь отладочного переключателя AllWinner, а там эмулация ARM вместо аппаратного ARM - обломс ?

3) У хостеров инфраструктура заточена на извлечение ключей из X86 гостей, а там ARM с немного другими своими структурами данных - обломс ?

Применительно к микро серверам интернет: SSH, почта, чатег и т.п.

X86 вообще позволяет запретить переход из режима 32 бита в 64 бита? VMWare Workstation 32 bit ведь умела запускать 64 битные оси, с помощью своих драйверов ядра, да.

Можно ли из QEMU ARM гостя начать общаться командами с внешним процессором X86 и даже зарутоваться к нему каким-либо образом?

Подразумевается использование Linux ядер версий >= v5.3, где якобы внедренны все сколько-нибудь стоящие патчи из открытого PAX.

Т.е. ядро 5.3 и на хосте и внутри гостя.

simoshina ()
Ответ на: комментарий от simoshina

PAX

Это те питушки, которые лепили какие-то там карго патчи имитирующие безопасность, когда все эти годы рядом были дырищи spectre и ко, полностью всё это аннулирующие?

anonymous ()
Ответ на: комментарий от anonymous

Разве spectre подобные уязвимости позволяют например из вебстраницы браузера (а не его внутренних закладок от гугла и т.п.) записывать в оперативку компа и выполнить свои машинные инструкции для рутования через god mode процов?

simoshina ()
Ответ на: комментарий от simoshina

Ну если тебя беспокоит только это, то к чему все заморочки? Сиди на обычном компе, можешь даже mitigations=off прописать.

anonymous ()
Ответ на: комментарий от anonymous

А можно примеры, когда spectre обходит защиту PAX?

Чтение левыми процессами чужой оперативки? Что-то еще?

simoshina ()
Ответ на: комментарий от anonymous

Я уже даже не надеюсь добиться одиночной безопасной рабочей станции,

Придется попытаться разносить многие сервисы по разным аппаратным компам, изолировать все PCI устройства кроме древней сетевухи вынесением их на отдельные аппаратные хосты.

К примеру выделенный хост для дисков по iSCSI:

Workstation (ZFS->LUKS)->iSCSI древний 16 битный Ethernet вроде бы даже без DMA -> dedicated Disk host (ZFS ZVol - вдруг в в открытом iSCSI тоже троян?, непосредственно диски)

Все хосты Libreboot, ну и еще отдельно дополнительно безопасные выделенные SSH консольки под ARM.

simoshina ()
Ответ на: комментарий от anonymous

Я кстати прописал, хрен бы с ними когда на пк в среднем одно приложение запущено. Куда проще исполнить код и заовнить систему через какой-нибудь network manager или pulseaudio/systemd чем сканировать месяцами память в поисках инфы которой там может не оказаться. Нагрев и нездоровая активность опять же заметны, так что это всё полная херня, тот же pax не в пример актуальней, жаль только софт ломался.

anonymous ()
Ответ на: комментарий от ValdikSS

Медленно чатег или почтовик?

Ну что вы народ то смешите.

Секурность стоит того.

simoshina ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.