Qemu внутри chroot на OpenBSD

Немного не в тему, но советую сразу скептически относиться к официальной документации. Несколько лет назад я поел говна, когда моя программа не могла открыть (EPERM, емнип) named semaphore другого процесса. Оказывается, OpenBSD это не умеет в целях безопасности, а соответствующее пояснение в мане появилось только спустя какое-то время.

qemu из портов или откуда? без чрута работает (вряд ли но стоит упросить конфигурацию)

Есть задача запустить qemu в chroot среде

Для чего?

Коль уж в такое полез то должен знать о типичных шагах:

1. Просто запуск Qemu от пользователя (не от рута)
2. Запуск без X11-сессии
3. Настройки лимитов (ulimit)
4. Запуск с трассировкой ktrace

Qemu много чего надо: доступ к устройствам, много памяти сразу - это же эмулятор.

я бы уже и забил на эту идею, сославшись на невозможность ее реализации в опенбсд, если бы не встречал на форумах ветки пользователей с такой конфигурацией (реквестирующих решение более глубинных задач) Насчет портов - спасибо! Честно говоря воспринимал их как истину в последней инстанции, тк все на них буквально молятся))

У меня вопрос, зачем в принципе запускать Qemu в chroot? Это и так уже виртуальная машина, такой изоляции мало?

нет, порты не установлены в принципе. Qemu и, насколько я понимаю, все зависимые компоненты установил pkg_add qemu. в основной системе (вне чрута) от рута работает нормально. При попытке запуска от nobody опять ругается на mprotect и jit buffer, но в этот раз с permission denied. Короче, как я понимаю проблема с доступом к памяти, но почему она возникает у рута в чруте - для меня вопрос.

*насчет манов, конечно же

Спасибо! Насколько я понимаю первые два пункта относятся ко второй части моей задачи (про запуск из под nobody), а вот ulimit и ktrace я попробовал, правда понятнее не стало))

вывод ktrace:
833337 qemu-system-x86_64 CALL mprotect(0xacd767b8000,0x1000, 0x1<PROT_READ>)
833337 qemu-system-x86_64 RET mprotect 0

833337 qemu-system-x86_64 CALL mprotect(0xacd767b8000,0x1000,0x3<PROT_READ|PROT_WRITE>)
833337 qemu-system-x86_64 RET mprotect 0

833337 qemu-system-x86_64 CALL kbind(0x7b9635c758f8,24,0x1f944c833083bd5)
83337 qemu-system-x86_64 RET kbind 0

833337 qemu-system-x86_64 CALL munmap(0xacdc0ed4000,0x1000)
833337 qemu-system-x86_64 RET munmap 0

mprotect вызывается с 2 разными аргументами более 20 раз munmap с различными аргументами, но на всех возвращает 0

лимитов нет, вывод ulimit -a в чруте:
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 4194304
stack(kbytes) 8192
lockedmem(kbytes) 87381
memory(kbytes) 16140744
nofiles(descriptors) 128
processes 1310

хорошо бы увидеть ktrace для mprotect, который вернул EPERM или ENOTSUP. Если верить https://man.openbsd.org/mprotect.2, то первое может быть вызвано последсвиями mimmutable(2), второе PROT_WRITE|PROT_EXEC (во что я могу поверить, учитывая JIT)

натолкнуло на мысль добавить wxallowed в fstab для раздела на котором chroot. Помогло)) ошибка с моей совсем детская. Надо бы тему удалить, чтоб народ в заблуждение не вводить;)

мне кажется, тема вполне заслуживает жить и быть проиндексированной поисковиками. Я бы даже саммари написал

Несколько лет назад я поел говна, когда моя программа не могла открыть (EPERM, емнип) named semaphore другого процесса. Оказывается, OpenBSD это не умеет в целях безопасности, а соответствующее пояснение в мане появилось только спустя какое-то время.

Вот это поворот! Я когда-то давно на старой макоси 10.5 безуспешно пытался использовать именованные семафоры для межпроцессного взаимодействия, и решил, что макось говно, а её юникс-сертификация куплена за взятки. А это оказывается для безопасности!