Обнаружена очередная local root уязвимость в ядре Linux 3.8

Где располагается libarp? Где располагаются ее кэши?

в юзерспейсе конечно

Смешно.

тут надо подумать — есть разные варианты

Да, прежде, чем фонтанировать фейспалмами, неплохо бы подумать.

вместе с каждым сисколлом к ядру «послать ip4 пакет» добавлять «по моим сведениям, вот его mac-адрес»;

Еще немного, и будут Ethernet-фреймы.

можно чуть замедлить процесс путем обращения ядра к юзерспейсному arp-серверу, если нужно *такое* arp-security

А security тут причем? Без общесистемного ARP-кэша ты будешь посылать ARP-запросы из каждого стартующего процесса, и в каждом процессе будет своя копия кэша. Или тебя такие мелочи не пугают?

Насчет стека в пользовательском режиме - гугли «userspace tcp protocol library» и «Van Jacobson network channels».

Смешно.

где?!

Да, прежде, чем фонтанировать фейспалмами, неплохо бы подумать.

ты явно читал меня неполностью

Еще немного, и будут Ethernet-фреймы.

почему?

А security тут причем?

при том, что основным доводом против юзерспейсного arp может быть только security

Без общесистемного ARP-кэша ты будешь посылать ARP-запросы из каждого стартующего процесса, и в каждом процессе будет своя копия кэша. Или тебя такие мелочи не пугают?

с чего вдруг? libarp может обращаться как к демону через сокет (медленно конечно, но часто ли это надо?), так и например расшарить в памяти таблицу «100500 моих последних уникальных arp-запросов и ответов на них»

Насчет стека в пользовательском режиме - гугли «userspace tcp protocol library» и «Van Jacobson network channels».

обязательно

но ты так и не сказал, чем его идеи были лучше моих

и в каждом процессе будет своя копия кэша

как quick & dirty вариант это вполне нормально — много ли адресов в современной локалке?

libarp может обращаться как к демону через сокет (медленно конечно, но часто ли это надо?)

Мде. Какому демону? Ладно, думай еще.

Мде. Какому демону?

ну мы че, в детском саду что ли? проблема: «не делать повторяющихся arp-запросов»; очевидное решение: «сделать юзерспейсного демона, который будет этим заниматься»; решение торвальдса: «поместить arp resolution в ядро!111»

Ладно, думай еще.

я подумаю в любом случае

я пока что вижу единственную проблему: ядерные реализации, хотя и страдают от взлома, потенциально могут предоставлять большую консистентность данных, чем сделанные на коленке libvasypupkintcpip.so (т.к. данные будут констентны по построению)

но проблема эта решается тем, что ядро будет валидировать то что важно, а то, что не очень важно (типа как случай когда libvasypupkintcpip.so по ошибке послала пакет, предназначавшийся для 192.168.0.1 mac AABBCCDDEE11 по адресу 192.168.0.1 mac AABBCCDDEE22, где последний мак адрес — это адрес 192.168.0.2) окупается повышением устойчивости в случае взлома

з.ы. могут быть, кстати, и другие, более интересные решения

Если хочешь, можешь запостить это в Devel, срачь будет знатный.

Я воздержусь от комментариев т.к. ничего нового по сравнению с тем что было сказано на тему микроядер или «давайте распилим systemd на куски» не скажу. Кроме того, вопрос не так прост как кажется. Плюс у каждого свои приоритеты и своё видение того «как это должно быть». Сейчас ты поймёшь о чём я.

просветите — можно ли сейчас ограничить *полный* размер памяти, занимаемый пакетами, лежащие в backlog-очереди интфейса, в зависимости от юзера, которому эти пакеты предназначены?

Нет, а надо ли? Имхо, есть 100500 более насущных проблем. Хорошо когда полезняшки появляются «бесплатно» просто за счёт хорошей архитектуры, но и бездумно гнаться за фичами не стоит.

Я, скажем так, не в восторге от всего ядра в целом, как и от ЯП на котором оно написано. Но по-другому в ближайшем будущем не будет, если только ты Торвальдса не переубедишь что это абсолютно необходимо. Но это фантастика. Но я люблю порассуждать на тему «как можно сделать лучше».

Мне отдельно интересна тема безопасности в монолитных ядрах. Я верю что можно изобрести такой ЯП и такие методы статистического анализа кода что многих проблем можно было бы избежать. Но это тоже палка о двух концах - можно сильно потерять в скорости и гибкости. Т.е. ты патаешься с одного конца решить проблему, а я хочу двигаться со всех сторон и считаю что лучший выбор это гибридное ядро. Но на вопрос что должно быть в ядре, а что нет вызовет немало споров.

Кстати, что поразительно, при всей своей монструзности линух нормально работает. Местами не идеально, местами плохо, но в среднем гораздо лучше чем любая другая ОС. Единственное мне жалко тех кто занимается реалтаймом на нём. Тут, правда, тоже можно спорить.

У Mach драйвера в ядре, так что нерелевантно (у Hurd вроде тоже)).

надо будет посмотреть что это за ядра... и у Mach че правда, в ядре?

а что такое по-твоему микроядерность? я так понимаю под микроядерностью «вот у нас есть вызовы функций и чтение-запись данных, давай их заменим ipc/посылкой сообщений/whatever» — ну и отсюда почти неизбежные тормоза

в случае сетвого стека у нас, грубо говоря, нет этой проблемы, т.к. *и так* общение идет пакетами, так что на лишние переключения контекста насрать

Нет, а надо ли?

ну да, конечно, «юзер» это фикция — ресурсы за ним хрен подсчитаешь, а если очень надо — запускай виртуалку под каждого пользователя

я че-то смутно припоминаю, что и другие лимиты «в расчете на юзера» не поддерживаются — что вроде «10000 семафоров на всю систему и не больше 30 на процесс»

и че, это в 21 веке называется OS? а почему не «студенческая поделка?»

Имхо, есть 100500 более насущных проблем.

какие?

У Mach драйвера в ядре, так что нерелевантно (у Hurd вроде тоже)).

Подтверждаю. В макоси драйвера в одном адресном пространстве с Mach, в Hurd линуксовые драйвера прямо в исходниках GNU Mach лежат.

Единственное мне жалко тех кто занимается реалтаймом на нём.

Вот так новости. И почему же?

ну мы че, в детском саду что ли?

Когда на вопрос «как работает libarp?» следует ответ «она обращается к юзерспейсному демону» - это однозначно деццтво.

Когда на вопрос «как работает libarp?» следует ответ «она обращается к юзерспейсному демону» - это однозначно деццтво.

вопрос был не такой, а «как libarp избегает посылки повторных arp запросов»

что же касается самой *работы* — ты думаю сам прекрасно знаешь, как работает arp протокол, и вряд ли будешь у меня это спрашивать

так что неясным могло быть лишь то, находится ли arp-кэш в юзерспейсе или в ядре

Подтверждаю. В макоси драйвера в одном адресном пространстве с Mach, в Hurd линуксовые драйвера прямо в исходниках GNU Mach лежат.

у меня нет мнения из первых рук, но вот в википедии пишут, что:

Mach's derivatives are the basis of the modern operating system kernels in Mac OS X (which is not a microkernel[1]) and GNU Hurd (which is a microkernel).

то, где лежат исходники, еще не дает окончательный ответ, так что полезны были бы дополнительные разъяснения

запускай виртуалку под каждого пользователя

Так, прежде чем я отвечу расскажи что именно ты имеешь в виду? net.core.netdev_max_backlog?

какие?

Да хотя бы нормальный аналог zfs :)

Вот так новости. И почему же?

А каковы минимальные гарантированные задержки?

Единственное мне жалко тех кто занимается реалтаймом на нём.

Вот так новости. И почему же?

А каковы минимальные гарантированные задержки?

Ненене. Тебе их уже жалко, почему?

Что до минимальных гарантий - это высчитывается для конкретного аппаратно-программного комплеккса. На ядре -rt - десятки микросекунд для абстрактной конфигурации в вакууме.

gnumach/i386/i386/spl.S, комментарий к SETIPL():

...
/*
 * Set IPL to the specified value.
 *
 * NOTE: Normally we would not have to enable interrupts
 * here.  Linux drivers, however, use cli()/sti(), so we must
 * guard against the case where a Mach routine which
 * has done an spl() calls a Linux routine that returns
 * with interrupts disabled.  A subsequent splx() can,
 * potentially, return with interrupts disabled.
 */
...

cli/sti из непривелигированого режима не сделать. Сетевой стек вынесен в юзерспейс и находится в HURD, логично было бы и драйверы перенести туда же, если бы они не были частью Mach.

слой совместимости с linux: gnumach/linux/dev/glue/kmem.c:

...
/* Allocate SIZE bytes of memory.  The pages need not be contiguous.  */
void *
vmalloc (unsigned long size)
{
  kern_return_t ret;
  vm_offset_t addr;

  ret = kmem_alloc_wired (kernel_map, &addr, round_page (size));
  if (ret != KERN_SUCCESS)
    return NULL;

  vmalloc_list_insert (addr, round_page (size));
  return (void *) addr;
}
...

kmem_alloc_wired() не экспортируется вне Mach.

Так, прежде чем я отвечу расскажи что именно ты имеешь в виду? net.core.netdev_max_backlog?

int listen(int sockfd, int backlog);

вот смотри, допустим юзерский процесс открыл слушающий сокет на порту скажем 1025; туда пришел tcp/ip пакет, который процесс (по злому умыслу или по небрежению) не прочитал; затем второй, третий, backlog-ый — все они успешно принимаются

все эти пакеты лежат где-то в пространстве ядра и не учитываются как память, занимаемая процессом (в том числе не влияют на решение oom killer-а кого прикончить) — я правильно понимаю?

Linux drivers, however, use cli()/sti()

Сетевой стек вынесен в юзерспейс и находится в HURD, логично было бы и драйверы перенести туда же, если бы они не были частью Mach.

было бы очень странно, если бы ЛИНУКСОВЫЕ драйверы заработали в mach вне ядра

то, что mach_вместе_с_линуксовыми_дровами не микроядерна, это понятно, но следует ли отсюда, что mach сама по себе не микроядерна?

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

было бы очень странно, если бы ЛИНУКСОВЫЕ драйверы заработали в mach вне ядра

Ну почему же, механизмы в Mach для этого есть. Для портов ввода-вывода есть специальный i386 IPC, с регистрами отображенными на память думаю сработает стандартный. Что делать c sti/cli не могу придумать так сразу, но думаю что решение есть.

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

Я считаю, что классификации Mach как микроядра мешает то, что нет ни одной ОС с чисто микроядерным Mach (в оригинальном Mach 3 тоже есть драйверы). PoC бы не помешал. Ну а формально «чистый» Mach (которого как бы и нет в дикой природе) - микроядро, конечно.

В общем фиксить конечно нужно, но юзерам оно не грозит.

А почему оно должно юзерам грозить? Оно админам грозит и вендорам, тем что юзер может свои права поднять.

Или будет ведроид на этом ведре и его смогут через эту уязвимость прорутовать и какой-нибудь амазон(киндл как пример огороженного девайса) денег потеряет на этом

каков должен быть правильный дизайн:

1. libudp4, libtcpip4, libnat4, libsctp4, ... libupd6, libtcpip6, libsctp6, ... работающие в *пространстве пользователя*

Ох уж эти любители микроядер... Есть тут некоторые проблемы:

0. Для начала подумай о том, как будет в таком случае выглядеть файрвол, маршрутизатор, NAT... то есть банальный ADSL-модем или Ethernet-роутер. Сделаешь демоны, которые будут выполнять эти функции? Типа iptablesd, ethernetd, natd, routerd, и т.ḋ.

1. Система получится жутко сложной. Когда пакет входит в сетевой интерфейс, это просто байты, ядро не знает, что с ними делать. А вдруг этот пакет NAT-ится и уходит в локалку через другой интерфейс? А может это ICMP-пинг и на него надо ответить? Или запрос от смонтированной по сети samba? А может это часть сессии запущенного локально wget-а? Как это узнать? Надо передать пакет на разбор демону ethernetd, который поспрашивает демонов iptablesd, natd, routerd... И какой-то из этих демонов должен будет его принять и передать дальше либо процессам, либо в другой сетевой интерфейс или кому-то ещё.

2. Эти демоны способны передать пакет любому процессу, в любой сетевой интерфейс, модулю файловой системы... Т.е. на практике они имеют права рута. А значит безопасность они ничем не улучшают.

3. Падение такого демона — это катастрофа, все дескрипторы сокетов (а может и файлов) у всех запущенных в системе процессов становятся невалидными, и все процессы нужно перезапускать. Это всё равно что сделать ребут.

4. Кроме того из-за сложности и кучи переключений между процессами, результат получается очень медленный. Гигабитные сетевухи, которые способны генерировать такие пакеты миллионами в секунду, для современного линукса — обычное дело. А миникс, в котором реализован похожий «правильный дизайн», на них дохнет. Он даже на 100МБит не всегда может выжать полную скорость.

Итого: такой «правильный дизайн» это сложно, медленно и ничего полезного не дает.

по п.1 и 2: анонимус не читатель, анонимус писатель!

иди внимательно читай мой пост, а затем — переписку с тейлганнером

по п.3:

Падение такого демона — это катастрофа, все дескрипторы сокетов (а может и файлов) у всех запущенных в системе процессов становятся невалидными

ну извините, инвалидация сокетов — это специфика сети в любом случае

юзер взял и выдернул wifi usb модуль, или монтажник корбины пришел, и порезал чужие провода, или говно-мтс взяло и потеряло на 15 минут связь с куском заграницы (где находится hetzner — это было недавно)

говно-мтс, кстати, довольно часто теряет связь надолго... да и pppd демон — это же вопиющее нарушение!1111 его надо в ядро!!!111 как торвальдс-то недоглядел?!!11

на п.4. повторю — у меня не микроядро, а всего лишь (основная) часть сетевого стека в юзерспейсе;

откуда дровишки насчет «миникс даже на 100МБит не всегда может выжать полную скорость»? правда интересно

На ядре -rt - десятки микросекунд для абстрактной конфигурации в вакууме.

неплохо, я думал хуже. Значит я был не прав.

все эти пакеты лежат где-то в пространстве ядра и не учитываются как память, занимаемая процессом (в том числе не влияют на решение oom killer-а кого прикончить) — я правильно понимаю?

эээ, это же копейки. Ты своей системой «каждому процессу свой сетевой стек» внесёшь в тыщу раз больше оверхеда чем там пара кб (не помню сколько, данные были в гугле, но для разных ядер оно немного разное) на каждое соединения.

Короче, это не серьёзно. Таких блох найти можно очень много (например, каждая программа и каждая нить имеют запись в глобальном списке процессов, ты это тоже хочешь учитывать? Или записи на фаерволе тоже потребляют память и ресуры.

по п.1 и 2: анонимус не читатель, анонимус писатель!
иди внимательно читай мой пост, а затем — переписку с тейлганнером

Не вижу ответов на вопросы о том, как будет выглядеть маршрутизация или взаимодействие между процессами. Ещё раз повторяю: когда ядро получает пакет оно не знает, какому из сотен запущенных процессов его надо отдать или куда дальше его надо завернуть. Каким образом оно должно это узнать, если кода для разбора пакета в ядре нет?

ну извините, инвалидация сокетов — это специфика сети в любом случае

Сокетов — да, но тут есть ещё и файлы. Как ты себе представляешь реализовать выделение сокетов в одном процессе, а файлов в другом? Как ядро должно ориентироваться, кто из них что обрабатывает? Ты же не можешь выделять сокет внутри самого процесса? Ведь такой сокет нельзя будет передать от одного процесса другому.

юзер взял и выдернул wifi usb модуль

Нее... Это не то... Есть некоторая разница между shutdown-утым сокетом и инвалидным. Инвалидный дескриптор может снова выделиться, например, при следующем вызове socket(), и в результате ты получишь таки валидный сокет, но указывающий совсем не туда, куда он указывал до падения. Кстати, это тоже забавный вопрос — как процессы будут определять какие дескрипторы свободны? Тут ещё развлекаться и развлекаться...

откуда дровишки насчет «миникс даже на 100МБит не всегда может выжать полную скорость»? правда интересно

Это по памяти. На каком-то русском миниксовом форуме народ, которому удалось найти железо, на котором миникс таки запустился, бенчмарки делал. А разработка гигабитного драйвера была чуть-ли не предметом чьей-то диссертации, и там в тексте упоминалось, что после длительных тюнингов удалось достингуть скорости типа 10МБ/сек. Могу ошибаться с цифрами, но порядок такой.

Как ты себе представляешь реализовать выделение сокетов в одном процессе, а файлов в другом?

ЕМНИП, дескрипторы открытых файлов мапятся на дескрипторы портов, которые глобальны для системы, так что принципиальных трудностей нет. В общем, всё предложенное вполне реализуемо.

после длительных тюнингов удалось достингуть скорости типа 10МБ/сек. Могу ошибаться с цифрами, но порядок такой.

Странно, я в статье о Миникс3 читал, что они выжали из гигабитки столько же, сколько и Линукс.

там пара кб (не помню сколько, данные были в гугле, но для разных ядер оно немного разное) на каждое соединения.

там как минимум 100кб на каждый сокет в виде буфера сокета (причем это я подтверждал экспериментально — отправил и затем получил; попытка то же сделать с 4МБ привела к забавному результату — получено было 20МБ (гы-гы), похоже где-то баг в ядре стабильного дебиана или libc)

если я правильно понимаю, то rmem_max — Sets the receive socket buffer maximum size in bytes.

$ cat /proc/sys/net/core/rmem_max 
131071

ЕМНИП, дескрипторы открытых файлов мапятся на дескрипторы портов, которые глобальны для системы, так что принципиальных трудностей нет. В общем, всё предложенное вполне реализуемо.

Когда есть один демон который всё парсит, то да, реализуемо. Не всё и довольно сложно, конечно, но реализуемо. Собственно, оно и реализовано, в том же миниксе. Но когда парсинг делается в библиотеке, которая у каждого процесса своя, и ядро заранее не знает даже к кому обратиться за парсингом, то возникают некоторые сложности... :-)

Странно, я в статье о Миникс3 читал, что они выжали из гигабитки столько же, сколько и Линукс.

В какой статье? Не в этой ли случайно? ;-)

Любопытно, я об этом не подумал.

Хотя, знаешь, мне не очевидно что твой путь это правильный. Ты привёл ситуацию когда надо шарить ресурсы между потенциально враждующими юзерами. Или если юзеры хотят напакостить друг другу. Тогда это имеет смысл. Но для таких ситуаций мы можем использовать виртуализацию. Т.е. задача имеет красивое решение.

А если сервер твой то это просто не нужно. Поэтому у меня есть сомнения в целесообразности изменений.

ЕМНИП, дескрипторы открытых файлов мапятся на дескрипторы портов, которые глобальны для системы, так что принципиальных трудностей нет. В общем, всё предложенное вполне реализуемо.

Когда есть один демон который всё парсит, то да, реализуемо.

Есть несколько демонов, каждый из которых отвечает за свой вид дескрипторов (файлы, сокеты). И есть единое микроядро, выделяющее дескрипторы портов.

Странно, я в статье о Миникс3 читал, что они выжали из гигабитки столько же, сколько и Линукс.

В какой статье? Не в этой ли случайно? ;-)

Нет. Но, насколько я понимаю, даже в этой статье _драйвер_ выжал из карты полную производительность.

Каким образом оно должно это узнать, если кода для разбора пакета в ядре нет?

код для разбора пакета в ядре есть, и это писалось уже неоднократно

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

однако, этот код stateless и очень туп — на уровне смещений в пакете (или file magic)

(а когда необходимо сделать что-то stateful, скажем nat, то этим занимается не ядро — какой-то демон регистрируется как обработчик *всех* пакетов)

какому из сотен запущенных процессов его надо отдать или куда дальше его надо завернуть

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах (в частности, оно может не позволять двоим процессам слушать один порт или позволить это (если надо))

т.е. ядро все-таки оперирует кое-каким state-ом, однако *логически* это state процесса (процесс pid=12345 слушает порты 67 и 890), хотя *физически* это скорее всего будет таблица скажем 64Кпорта*4байта=256кб на каждый сетевой интерфейс

еще раз — поскольку *логически* слушаемые порты являются состоянием *процесса*, а не сети, ядро об этом знает и работает с этим, ибо ядро работает с процессами

а вот уже досылка пропавших пакетов, скорость передачи, всевозможные буфера сокета и т.п. — это дело сетевого стека

Но для таких ситуаций мы можем использовать виртуализацию. Т.е. задача имеет красивое решение.

красивое решение.

бугага

емнип уже находили баги, позволяющие выбраться из domU

да и вообще виртуализатор — это та же ос, только чуть меньше, со всеми своими возможностями что-то сломать из-за багов

емнип уже находили баги, позволяющие выбраться из domU

Это не аргумент. Баги находили везде. Это не делает решение менее элегантным. Как раз та модульность о которой ты говорил - выделяем юзеру немного памяти и проца и пусть что хочет делает с этим.

да и вообще виртуализатор — это та же ос

виртуализатор это в первую очередь гипервизор. Потом уже идёт (почти) стандартая ОС с которой юзер может делать всё что угодно.

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах

вот тут уже напрочь поехала твоя красивая архитектура полного разделения уровней. И возникает вопрос стоит ли так извращаться. На твоём месте я бы каждому процессу выделил по ipv6 адресу и в ядре смотрел только адрес назначения. А уже внутри приложения оно бы запускало всякие libtcp итп. В таком случае логики на уровне ядра почти не будет.

Сокетов — да, но тут есть ещё и файлы. Как ты себе представляешь реализовать выделение сокетов в одном процессе, а файлов в другом? Как ядро должно ориентироваться, кто из них что обрабатывает? Ты же не можешь выделять сокет внутри самого процесса? Ведь такой сокет нельзя будет передать от одного процесса другому.

я совершенно не въехал в этот абзац про файлы

это вообще про что? man 2 sendfile? или что?

вот тут уже напрочь поехала твоя красивая архитектура полного разделения уровней. И возникает вопрос стоит ли так извращаться. На твоём месте я бы каждому процессу выделил по ipv6 адресу

ну так это то же самое: true_admin_ipv6=strcat(ip4addr, ip4port)

и нет, архитектура не поехала

ну так это то же самое

а потом ты вспомнишь про icmp, igmp, туннели...

а потом ты вспомнишь про icmp, igmp, туннели...

это *ты* вспомнишь; твой «один ipv6» это неудачное архитектурное предложение

давай лучше найди недостатки или неясности в том, что я предложил

Это не аргумент. Баги находили везде. Это не делает решение менее элегантным.

ну епрст, если ты не согласен с тем, что баги, позволяющие выйти из domU не делают решение менее элегантным, мне не ясно как с тобой говорить об элегантности

виртуализатор ..... Как раз та модульность о которой ты говорил - выделяем юзеру немного памяти и проца и пусть что хочет делает с этим.

выделяем юзеру памяти, проца и несколько fd — это как раз обычный linux-user-in-seccomp

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

если ты не согласен с тем, что баги, позволяющие выйти из domU не делают решение менее элегантным, мне не ясно как с тобой говорить об элегантности

Очень просто: докажи что твоё решение будет абсолютно свободно от багов и уязвимостей.

выделяем юзеру памяти, проца и несколько fd — это как раз обычный linux-user-in-seccomp

Ты забыл добавить что для этого нужно будет переписать всё ядро.

а юзер под вирутализатором получает еще устройства

не обязательно (прямой механизм общения гость-мастер, вроде, есть), но так проще всего.

Очень просто: докажи что твоё решение будет абсолютно свободно от багов и уязвимостей.

ты неправильно поставил вопрос

правильная постановка — «докажи, что твоя архитектура будет полностью свободна от багов, позволяющих выйти в dom0 или root»

и доказательство уже было: сетевой стэк работает под юзером, а на стороне ядра тупой до невозможности код (который, кстати, поэтому можно формально верифицировать)

выделяем юзеру памяти, проца и несколько fd — это как раз обычный linux-user-in-seccomp

Ты забыл добавить что для этого нужно будет переписать всё ядро.

че?!

бегом читать википедию: http://en.wikipedia.org/wiki/Seccomp

не обязательно (прямой механизм общения гость-мастер, вроде, есть), но так проще всего.

а вот это я не пониманию, можно на конкретном примере?

если я скажем хочу запустить firefox http://example.com в госте, но так, чтобы сетевая карта не эмулировалась, то что?

Ты совсем в сторону отвалился. Я знаю что такое seccomp. Это тут вообще ни при чём, это просто фильтр системных вызовов. Про переписывания ядра я имел в виду переписывание всего и вся под твою новую архитектуру ОС.

сетевой стэк работает под юзером, а на стороне ядра тупой до невозможности код

Ну окей, всё вернулось к микроядру. В чём новшество?

а вот это я не пониманию, можно на конкретном примере?

Замапить страницы памяти гостя и мастера в одно место.

Заодно читаем http://scarybeastsecurity.blogspot.it/2009/02/linux-kernel-minor-seccomp.html

Пичалька, по твоей логике и seccomp нельзя использовать.

Про переписывания ядра я имел в виду переписывание всего и вся под твою новую архитектуру ОС.

неверно — надо лишь оторвать сетевой стек

Ну окей, всё вернулось к микроядру. В чём новшество?

это не микроядро — это, скорее, сетевой стек в юзерспейсе (да и то чуть-чуть не весь)