С бухгалтерией и похожими вещами я ещё могу представить такую схему, но как быть с ОС, смартфонами, играми, текстовыми редакторами, СУБД, браузерами и IoT? Хотя в случае с IoT это уже потихоньку начали регулировать, по крайней мере в ЕС (и это хорошо).
Фрилансер-оператор ОС, выполняющий распоряжения пользователя для работы с ней, при этом не могущий подать в суд на разработчика ОС, поскольку является её соавтором — вы примерно так себе это представляете?
Лицензии можно выдавать компаниям, ЧП и фрилансерам.
В Германии есть хороший пример в этом плане (в других областях), называется Meisterbrief. Это сертификат, выдаваемый профессионалу (с необходимостью доказать свои знания в теории и практики), и дающий ему право на осуществление соответствующей деятельности и открытие фирмы по профилю. Он может нанять «подмастерьев» и вообще кого угодно для выполнения работы, с образованием или без, но отвечать за работу будет лично он. Для ряда профессий наличие этого сертификата является обязательным условием для оказания услуг на коммерческой основе (и даже «просто так» — для врачей и юристов, например).
Эта система, увы, не идеальна и не свободна от недостатков, но сама идея довольно здравая — если кто-то хочет быть врачом, электриком, сантехником, то он обязан доказать свою профпригодность, и должен нести ощутимую ответственность за свои ошибки. При правильном подходе можно исключить (или сильно уменьшить) варианты когда «зубрилы» получают такие лицензии, реально не обладая необходимым опытом или знаниями.
А теперь представьте, что система таки реализована. Вы — владелец лицензии, и вам нужно нанять программистов. Зная, что за их ошибки с вас могут снять либо голову либо много денег, вы примете все меры чтобы они были очень крутыми, либо сами будете перепроверять их работу по десять раз, пока не убедитесь что они не накосячили. Тяжко? Тяжко, зато на выходе будет качественный продукт. Ну или придётся заняться чем-то ещё, чтобы с голоду не умереть.
К сожалению, всё это только теория. На практике скорее ИИ научат писать программы не хуже людей, чем произойдут такие законодательные изменения, а до этого момента будем страдать.
Я клоню к тому же что и раньше — никакие инструменты не изменят качество кода (сами по себе), а вот пряморукие разработчики — изменят.
И да, если бы я был законодателем — ввёл бы экзамены на качество кода и лицензию на коммерческое программирование. В конце концов, за руль без прав не пускают, врачебную практику тоже лицензируют, почему тут должно быть иначе?
А для хобби, за бесплатно — пусть себе пишут без лицензии, так уж и быть :)
Посмотрите на sqlite — он вообще public domain, фичи регулярно добавляются, баги фиксятся, да и код вылизан покруче чем у большинства.
Да, сейчас у него много донатов, но вначале было не так — тем не менее на качество это не влияло.
Можно и ещё найти примеры, но их можно на пальцах пересчитать, хотя сам факт их наличия (при отсутствии у авторов кучи денег) говорит о том что для качественного кода совсем не нужны миллиарды и сотни лет разработки.
В этом-то и проблема. В случае осязаемых продуктов (техника, лекарства etc) есть и другие обязанности, которые невозможно исключить никаким договором (гарантия, например, или ответственность за причинение вреда).
«Гарантия, обеспеченная законом» — это как раз гарантия, которая не требует «специального договора», т.е. гарантия по умолчанию.
Когда вы покупаете автомобиль или дом, вы заключаете специальный договор? Сомневаюсь. Но производитель всё равно несет ответственность если откажут тормоза, или если дом рухнет потому что плохо построен или спроектирован.
Ответ на вопрос «зачем» очень прост — если кто-то берет деньги за свой продукт, он обязан нести за это ответственность, или, как минимум, заранее огласить весь список возможных проблем.
Вы не купите автомобиль если не будете уверены что его тормозная система тщательно проверяется и работоспособна, а если вдруг в конкретном случае она будет глючить, то производитель будет нести полную ответственность — так почему с программными продуктами должно быть иначе?
Мне кажется очевидным что такие договора подпишут единицы, так что компании придётся искать другие источники дохода, соответственно, выбора не будет у них.
Хотя проще, вероятно, будет сделать иначе — не берёшь денег — не несёшь ответственности, берёшь — несёшь в полной мере и никак не можешь её исключить в лицензии.
При таком раскладе, компании которые изначально озаботятся качеством, окажутся однозначно в выигрыше — да, их продукция будет стоить дороже, но зато у них будет гарантированный доход. Остальные могут давать свои продукты тестировать бесплатно, пока не вылижут до возможности брать деньги.
Любой пользователь коммерческих программных продуктов должен иметь обеспеченную законом гарантию, причём на уровне покрытия доказуемых понесенных убытков, а не просто «вернём деньги» или «заменим бесплатно» — тогда дело сдвинется с мёртвой точки.
Софт, даже большой и сложный, и даже на C или ассемблере, можно писать без багов, просто весьма ограниченное число компаний (и людей) на это способно и имеет желание, и ещё меньше имеет достаточно денег.
Лучше опечатанный ноутбук с вордом, но при этом уверенность в том что никакой левый файл, открытый в этом ворде, не сможет натворить дел, а также уверенность в том что он не угробит работу нескольких дней при попытке сохранения (такое тоже бывало, очень много лет назад).
Да, написание качественного софта стоит денег и времени, но вы посчитайте все убытки связанные с уязвимостями и критичными багами — во многих случаях они явно превышают затраты на разработчиков, которые потребовались бы для написания софта без таких багов, которые приводят к этим самым убыткам.
Неважно кто будет совершать коммиты — штраф получит компания, и пусть сама разбирается со своими сотрудниками. Несколько крупных штрафов — и политика найма дворников сойдёт на нет. Или хитрая компания сойдёт на нет.
Даже ядро ОС и то спокойно пишется на полностью безопасном языке, т.к. мизерное количество кода напрямую работает с памятью.
Рискну предположить, что в этом случае ядро будет очень сильно тормозить. Как пример — безопасный язык просто обязан проверять соответствие индекса размерам массива, это несколько лишних операций, больно бьет по кэшу и т.п. — а в ядре ОС таких операций немало, причём в довольно критичных местах.
Ни одна проверка не обходится даром, за это приходится платить либо производительностью, либо памятью, либо и тем и другим — для ядра это очень расточительно.
А для остальных приложенией — да посмотрите на мир Java, типа супер-безопасный язык (с точки зрения указателей как минимум), и сколько уязвимостей уже было в продуктах на нём писанных.
Не поймите неправильно, я не утверждаю что не нужны безопасные языки, или что не нужно жертвовать производительностью ради безопасности — просто проблему нужно решать с другой стороны.
Если законодательно ввести штраф за каждую обнаруженную уязвимость, т.е. ответственность разработчика за качество кода, вот тогда проблемы начнут решаться — код будут вылизывать. В конце концов, почему, если рушится мост или дом, архитектора или строителей могут наказать, а программистов — нет? Уязвимость (и даже банальный баг) в программном продукте также может быть смертельной, или приносит существенные убытки, только вот никто за это не несет никакой ответственности (если и несёт, то в лучшем случае это бьет по репутации, и то ненадолго).
Пока все лицензии на софт (включая коммерческий, и даже критичный, типа ОС) содержат явный отказ от ответственности, или, в лучше случае, «мы вернем вам деньги за покупку», у производителей почти нет никакого стимула делать его свободным от уязвимостей или ошибок.
С другой стороны, возьмём софт который работает в борткомпах каждого современного автомобиля, самолёта etc — часто там обнаруживают уязвимости? А удаленные? Да хотя бы просто баги, такие, которые не позволяют нормально пользоваться техникой — часто? А ведь он чуть меньше чем полностью писан на C, а то и ассемблере. Автомобили сами не тормозят и не ускоряются (только давайте не будем про Tesla & co), не мигают фарами, самолёты не меняют высоту, и т.п. Отдельные фейлы случаются, но это исключительно редкий случай. Дело же просто в том, что как раз баги и уязвимости в таком софте приводят к реальной ответственности — поэтому их там почти нет, по крайней мере не такие какие были бы заметны обычным пользователям.
А Rust действительно проверен. Он безопасен по-определению, т.к. все перечисленные проблемы в нем конкретно решены в самом языке.
Он (сам по себе) не решает более серьезные проблемы — валидации [внешних] данных, не говоря уже про логические ошибки.
К примеру, если (предположим) писать веб-сайты на Rust, он никак не спасёт ни от SQL injection, ни от кучи других проблем имеющих отношение к Web Application Security, равно как и вообще любых проблем которые выходят за рамки безопасных указателей и безопасной работы с памятью.
Ради интереса, пройдитесь по CVE и посчитайте долю уязвимостей связанных с неправильной работы с памятью, и долю всех остальных — результат явно укажет что «безопасный» язык проблему не решит.
Давая возможность для возникновения ошибок типа «memory unsafety», языки программирования, такие как C и C++, могут способствовать распространению почти бесконечного потока критических уязвимостей безопасности на протяжении многих лет.
Очень популярный язык PHP не даёт таких возможностей (сам язык — отдельные уязвимости run-time можно не считать, они исключительно редко использовались).
Тем не менее, в не менее популярной CMS, написанной на PHP, включая весь зоопарк плагинов к ней (я о WordPress, если это не очевидно) имеются просто зиллионы уязвимостей (которые никак не эксплуатируют уязвимости run-time).
Можно покопаться в популярных приложениях на Java или .NET и тоже найти немало уязвимостей, несмотря на то что там вполне неплохая «memory safety».
А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально?
Мы можем описать её функцию и интерфейс: «Нужна такая штука для создания заметок с голосовым вводом, чтобы их можно было приклеивать на десктоп». Далее можно сделать несколько итераций и уточнить, в итоге умный ИИ сообразит как это лучше сделать, оперируя ему известными алгоритмами, структурами данных и API для целевой системы.
Я надеюсь, в будущем (наверное, далеком, хотя хотелось бы и пораньше) именно так и будут создавать приложения, что решит массу проблем которыми сейчас кишит IT — потому что машина лучше всего справится с разработкой и не допустит ни ошибок, ни уязвимостей, ни быдлокода.
Про писателей, предпочитающих — ну так это не про имя человека, а про литературные псевдонимы.
В Германии есть «литературные псевдонимы» (Künstlernamen) — абсолютно легальные имена, которые можно использовать наравне с настоящим именем (для подачи налоговой декларации, открытия счёта в банке и заключения договоров тоже). Для этого, правда, их нужно зарегистрировать — но это реальный пример из совсем не экзотической страны, когда у человека может быть два абсолютно легальных имени, причём записанных в паспорте, и при этом используемых независимо и взаимозаменяемо.
Да. Я взял ядро 4.19, добавил ему virtnet/virtblk статикой (чтобы обойтись без initrd), и запустил Ubuntu 18.04. Ядро можно урезать до минимума, всякая поддержка железа не нужна.
Всё почти как обещано — CPU на уровне 95% от хоста (прикидывается ксеоном), а вот с сетью и диском — на полной загрузке жрёт CPU хоста просто безбожно. Сеткой даёт около 30 Gbits/s с хостом (на i7-6700). Впрочем, с qemu ситуация несколько хуже, оверхед там поболе будет, но это зависит.
В остальном — гипервизор как гипервизор, нужно просто юзать. Привлекает то что это один статический экзешник, никакого инсталла, простой API. Расстраивает что нет годного UI (пока), хотя они вроде уже запилили поддержку в containerd.
Если Proxmox это подхватит (рядом с QEMU) — может неплохая альтернатива lxc получится (в плане изоляции как минимум).
Сильно I/O loaded штуки в нём гонять будет накладно (как, впрочем, и в qemu/docker), но «стандартный пакет» для в основном ожидающих задач (веб-сервера & co) вполне сойдёт.
по таким словам очень сложно найти упоминание о поддельном сайте
В гугле искать можно буквально — «icloud.com.id-apple.info» (да, именно в одиночных кавычках, которые хабр меняет), если кто-то про него написал, то найдёт. В данном случае поиск привел к двум ссылкам, причём первая из них — эта публикация.
Проблема в том что поддельные сайты создаются обычно прямо перед экшн, и за то время пока идёт компания по фишингу никто не успевает ничего написать, к моменту же когда кто-то напишет сайт уже будет неактивен (скорее всего).
потому что всем, по какой-то невиданной причине, почему-то оказывается очень нужна эмуляция всевозможного оборудования
Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция. В случае с qemu это большой оверхед (там много лишнего), поэтому минималистический гипервизор который дает только изоляцию, сеть и block-device, при этом способный выполнять любое ядро — это реальная тема, потому что это всё что нужно большинству контейнеров.
Уже бы тушили питание посредством bios-uefi
Тушить питание не проблема, проблема надёжно и безопасно дать OS знать что пора делать graceful shutdown, ACPI/UEFI etc тут явно будет перебором — клавиатуру эмулировать проще на порядок.
Да, с меньшими — он не эмулирует реальное железо или процессор, и гораздо шустрее. Скорее он ближе к Xen или к UML, чем к QEMU.
Всё что ему нужно от KVM — это изоляция процесса + прямое выполнение инструкций на хостовом железе (в изоляции от других процессов, разумеется), т.е. с точки зрения гостя у него процессор хоста, но это всё что гостю может быть видно из железа.
cgroups/seccomp нужны исключительно для того чтобы никто не выбрался дальше, ведь фактически Firecracker нужно только read/write и ещё несколько простых и сравнительно безопасных системных вызовов, в то время как QEMU нужно гораздо больше для нормальной работы, и его гораздо сложнее изолировать.
Таким образом, роль самого Firecracker заключается только в инициализации и реализации обмена данными с хостом (на уровне файлов/сокетов для virtio устройств), больше ни к чему гость не имеет доступа и соответственно навредить вряд ли сможет (разве что поедая ресурсы — но от этого как раз спасут cgroups).
С NBD нужны телодвижения со стороны хоста — как минимум, серверная часть, которая будет отдавать файлы или устройства. Плюс оверхед никуда таки не денется — всё пойдёт через сетевой стек (+ память на буфера, дополнительно к кэшу), пожирая ресурсы дважды, как у гостя, так и у хоста, при этом разбивая доступ на сравнительно мелкие пакеты (никто не даст гостю Jumbo Frames, хотя и они не сильно помогут).
В то же время «прямой» доступ через virtblk — это просто проброс на уровне read()/write(), вероятно даже с прямым доступом к памяти гостя со стороны хоста. Оверхед конечно останется, но ощутимо меньший.
Теперь умножим это на много VM на одном физическом хосте — и получим ужасную картину с оверхедом в случае NBD + гость может воспользоваться уязвимостью со стороны NBD сервера на хосте (если таковая обнаружится).
Фрилансер-оператор ОС, выполняющий распоряжения пользователя для работы с ней, при этом не могущий подать в суд на разработчика ОС, поскольку является её соавтором — вы примерно так себе это представляете?
В Германии есть хороший пример в этом плане (в других областях), называется Meisterbrief. Это сертификат, выдаваемый профессионалу (с необходимостью доказать свои знания в теории и практики), и дающий ему право на осуществление соответствующей деятельности и открытие фирмы по профилю. Он может нанять «подмастерьев» и вообще кого угодно для выполнения работы, с образованием или без, но отвечать за работу будет лично он. Для ряда профессий наличие этого сертификата является обязательным условием для оказания услуг на коммерческой основе (и даже «просто так» — для врачей и юристов, например).
Эта система, увы, не идеальна и не свободна от недостатков, но сама идея довольно здравая — если кто-то хочет быть врачом, электриком, сантехником, то он обязан доказать свою профпригодность, и должен нести ощутимую ответственность за свои ошибки. При правильном подходе можно исключить (или сильно уменьшить) варианты когда «зубрилы» получают такие лицензии, реально не обладая необходимым опытом или знаниями.
А теперь представьте, что система таки реализована. Вы — владелец лицензии, и вам нужно нанять программистов. Зная, что за их ошибки с вас могут снять либо голову либо много денег, вы примете все меры чтобы они были очень крутыми, либо сами будете перепроверять их работу по десять раз, пока не убедитесь что они не накосячили. Тяжко? Тяжко, зато на выходе будет качественный продукт. Ну или придётся заняться чем-то ещё, чтобы с голоду не умереть.
К сожалению, всё это только теория. На практике скорее ИИ научат писать программы не хуже людей, чем произойдут такие законодательные изменения, а до этого момента будем страдать.
И да, если бы я был законодателем — ввёл бы экзамены на качество кода и лицензию на коммерческое программирование. В конце концов, за руль без прав не пускают, врачебную практику тоже лицензируют, почему тут должно быть иначе?
А для хобби, за бесплатно — пусть себе пишут без лицензии, так уж и быть :)
Да, сейчас у него много донатов, но вначале было не так — тем не менее на качество это не влияло.
Можно и ещё найти примеры, но их можно на пальцах пересчитать, хотя сам факт их наличия (при отсутствии у авторов кучи денег) говорит о том что для качественного кода совсем не нужны миллиарды и сотни лет разработки.
Когда вы покупаете автомобиль или дом, вы заключаете специальный договор? Сомневаюсь. Но производитель всё равно несет ответственность если откажут тормоза, или если дом рухнет потому что плохо построен или спроектирован.
Вы не купите автомобиль если не будете уверены что его тормозная система тщательно проверяется и работоспособна, а если вдруг в конкретном случае она будет глючить, то производитель будет нести полную ответственность — так почему с программными продуктами должно быть иначе?
Хотя проще, вероятно, будет сделать иначе — не берёшь денег — не несёшь ответственности, берёшь — несёшь в полной мере и никак не можешь её исключить в лицензии.
При таком раскладе, компании которые изначально озаботятся качеством, окажутся однозначно в выигрыше — да, их продукция будет стоить дороже, но зато у них будет гарантированный доход. Остальные могут давать свои продукты тестировать бесплатно, пока не вылижут до возможности брать деньги.
Любой пользователь коммерческих программных продуктов должен иметь обеспеченную законом гарантию, причём на уровне покрытия доказуемых понесенных убытков, а не просто «вернём деньги» или «заменим бесплатно» — тогда дело сдвинется с мёртвой точки.
Софт, даже большой и сложный, и даже на C или ассемблере, можно писать без багов, просто весьма ограниченное число компаний (и людей) на это способно и имеет желание, и ещё меньше имеет достаточно денег.
Да, написание качественного софта стоит денег и времени, но вы посчитайте все убытки связанные с уязвимостями и критичными багами — во многих случаях они явно превышают затраты на разработчиков, которые потребовались бы для написания софта без таких багов, которые приводят к этим самым убыткам.
Рискну предположить, что в этом случае ядро будет очень сильно тормозить. Как пример — безопасный язык просто обязан проверять соответствие индекса размерам массива, это несколько лишних операций, больно бьет по кэшу и т.п. — а в ядре ОС таких операций немало, причём в довольно критичных местах.
Ни одна проверка не обходится даром, за это приходится платить либо производительностью, либо памятью, либо и тем и другим — для ядра это очень расточительно.
А для остальных приложенией — да посмотрите на мир Java, типа супер-безопасный язык (с точки зрения указателей как минимум), и сколько уязвимостей уже было в продуктах на нём писанных.
Не поймите неправильно, я не утверждаю что не нужны безопасные языки, или что не нужно жертвовать производительностью ради безопасности — просто проблему нужно решать с другой стороны.
Если законодательно ввести штраф за каждую обнаруженную уязвимость, т.е. ответственность разработчика за качество кода, вот тогда проблемы начнут решаться — код будут вылизывать. В конце концов, почему, если рушится мост или дом, архитектора или строителей могут наказать, а программистов — нет? Уязвимость (и даже банальный баг) в программном продукте также может быть смертельной, или приносит существенные убытки, только вот никто за это не несет никакой ответственности (если и несёт, то в лучшем случае это бьет по репутации, и то ненадолго).
Пока все лицензии на софт (включая коммерческий, и даже критичный, типа ОС) содержат явный отказ от ответственности, или, в лучше случае, «мы вернем вам деньги за покупку», у производителей почти нет никакого стимула делать его свободным от уязвимостей или ошибок.
С другой стороны, возьмём софт который работает в борткомпах каждого современного автомобиля, самолёта etc — часто там обнаруживают уязвимости? А удаленные? Да хотя бы просто баги, такие, которые не позволяют нормально пользоваться техникой — часто? А ведь он чуть меньше чем полностью писан на C, а то и ассемблере. Автомобили сами не тормозят и не ускоряются (только давайте не будем про Tesla & co), не мигают фарами, самолёты не меняют высоту, и т.п. Отдельные фейлы случаются, но это исключительно редкий случай. Дело же просто в том, что как раз баги и уязвимости в таком софте приводят к реальной ответственности — поэтому их там почти нет, по крайней мере не такие какие были бы заметны обычным пользователям.
Так что, повторюсь — язык это дело десятое.
Он (сам по себе) не решает более серьезные проблемы — валидации [внешних] данных, не говоря уже про логические ошибки.
К примеру, если (предположим) писать веб-сайты на Rust, он никак не спасёт ни от SQL injection, ни от кучи других проблем имеющих отношение к Web Application Security, равно как и вообще любых проблем которые выходят за рамки безопасных указателей и безопасной работы с памятью.
Ради интереса, пройдитесь по CVE и посчитайте долю уязвимостей связанных с неправильной работы с памятью, и долю всех остальных — результат явно укажет что «безопасный» язык проблему не решит.
Очень популярный язык PHP не даёт таких возможностей (сам язык — отдельные уязвимости run-time можно не считать, они исключительно редко использовались).
Тем не менее, в не менее популярной CMS, написанной на PHP, включая весь зоопарк плагинов к ней (я о WordPress, если это не очевидно) имеются просто зиллионы уязвимостей (которые никак не эксплуатируют уязвимости run-time).
Можно покопаться в популярных приложениях на Java или .NET и тоже найти немало уязвимостей, несмотря на то что там вполне неплохая «memory safety».
Так что не в языке дело, однако.
Мы можем описать её функцию и интерфейс: «Нужна такая штука для создания заметок с голосовым вводом, чтобы их можно было приклеивать на десктоп». Далее можно сделать несколько итераций и уточнить, в итоге умный ИИ сообразит как это лучше сделать, оперируя ему известными алгоритмами, структурами данных и API для целевой системы.
Я надеюсь, в будущем (наверное, далеком, хотя хотелось бы и пораньше) именно так и будут создавать приложения, что решит массу проблем которыми сейчас кишит IT — потому что машина лучше всего справится с разработкой и не допустит ни ошибок, ни уязвимостей, ни быдлокода.
В Германии есть «литературные псевдонимы» (Künstlernamen) — абсолютно легальные имена, которые можно использовать наравне с настоящим именем (для подачи налоговой декларации, открытия счёта в банке и заключения договоров тоже). Для этого, правда, их нужно зарегистрировать — но это реальный пример из совсем не экзотической страны, когда у человека может быть два абсолютно легальных имени, причём записанных в паспорте, и при этом используемых независимо и взаимозаменяемо.
Всё почти как обещано — CPU на уровне 95% от хоста (прикидывается ксеоном), а вот с сетью и диском — на полной загрузке жрёт CPU хоста просто безбожно. Сеткой даёт около 30 Gbits/s с хостом (на i7-6700). Впрочем, с qemu ситуация несколько хуже, оверхед там поболе будет, но это зависит.
В остальном — гипервизор как гипервизор, нужно просто юзать. Привлекает то что это один статический экзешник, никакого инсталла, простой API. Расстраивает что нет годного UI (пока), хотя они вроде уже запилили поддержку в containerd.
Если Proxmox это подхватит (рядом с QEMU) — может неплохая альтернатива lxc получится (в плане изоляции как минимум).
Сильно I/O loaded штуки в нём гонять будет накладно (как, впрочем, и в qemu/docker), но «стандартный пакет» для в основном ожидающих задач (веб-сервера & co) вполне сойдёт.
В гугле искать можно буквально — «icloud.com.id-apple.info» (да, именно в одиночных кавычках, которые хабр меняет), если кто-то про него написал, то найдёт. В данном случае поиск привел к двум ссылкам, причём первая из них — эта публикация.
Проблема в том что поддельные сайты создаются обычно прямо перед экшн, и за то время пока идёт компания по фишингу никто не успевает ничего написать, к моменту же когда кто-то напишет сайт уже будет неактивен (скорее всего).
Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция. В случае с qemu это большой оверхед (там много лишнего), поэтому минималистический гипервизор который дает только изоляцию, сеть и block-device, при этом способный выполнять любое ядро — это реальная тема, потому что это всё что нужно большинству контейнеров.
Тушить питание не проблема, проблема надёжно и безопасно дать OS знать что пора делать graceful shutdown, ACPI/UEFI etc тут явно будет перебором — клавиатуру эмулировать проще на порядок.
Всё что ему нужно от KVM — это изоляция процесса + прямое выполнение инструкций на хостовом железе (в изоляции от других процессов, разумеется), т.е. с точки зрения гостя у него процессор хоста, но это всё что гостю может быть видно из железа.
cgroups/seccomp нужны исключительно для того чтобы никто не выбрался дальше, ведь фактически Firecracker нужно только read/write и ещё несколько простых и сравнительно безопасных системных вызовов, в то время как QEMU нужно гораздо больше для нормальной работы, и его гораздо сложнее изолировать.
Таким образом, роль самого Firecracker заключается только в инициализации и реализации обмена данными с хостом (на уровне файлов/сокетов для virtio устройств), больше ни к чему гость не имеет доступа и соответственно навредить вряд ли сможет (разве что поедая ресурсы — но от этого как раз спасут cgroups).
В общем, я бы назвал это UML на стероидах.
В то же время «прямой» доступ через virtblk — это просто проброс на уровне read()/write(), вероятно даже с прямым доступом к памяти гостя со стороны хоста. Оверхед конечно останется, но ощутимо меньший.
Теперь умножим это на много VM на одном физическом хосте — и получим ужасную картину с оверхедом в случае NBD + гость может воспользоваться уязвимостью со стороны NBD сервера на хосте (если таковая обнаружится).