Вы так не нервничайте пожалуйста. Винда ваша не идеальная система, и уж точно не лучше всего на свете, примиритесь с этим.
Я абсолютно спокоен. Более того, это один из нечастых случаев, когда вместо обсуждения моей матушки завязалась техническая дискуссия (хотя и были попытки в духе «вы их этих» и «застрял в прошлом веке»). Я могу ошибаться (все могут), я могу не суметь донести свою точку зрения, но само наличие такой дискуссии — огромный плюс. Что же до идеальности. У меня вот есть тяга к микроядрам с capability-based безопасностью. Ничего не могу с собой поделать. NT не является ни тем ни другим (хотя по многим пунктам достаточно близко — особенно секьюрити), так что нет — не идеально даже ядро, а уж про юзермод (и особенно про Win32 как прямого наследника Win16) я и сам порассказать могу. Моя позиция касательно конкретно данного поста в том, что NT ЗНАЧИТЕЛЬНО лучше Linux в плане дизайна.
Вам могут сдуплицировать 1 хендл или 1000 или 100000, вы этот процесс уже не можете контролировать
...
Ну, ок. Для предметного разговора мне нужна модель угрозы. Покажите, пожалуйста, конкретный пример ситуации, когда процесс, наделенный правами станет эти права абьюзить (не из-за бага — которых может быть полно и в любом другом месте, а именно как угрозу). Отмечу лишь, что sendmsg/recvmsg легко реализуется на основе NtDuplicateHandle при помощи доверенного брокера (если это ДЕЙСТВИТЕЛЬНО понадобится, что само по себе еще не доказано), а вот реализовать NtDuplicateHandle на основе сокетов — не получится (как пример: как мне восстановить связь с клиентами после рестарта демона). Ну или уже приведенный пример seccomp sandbox. При этом на момент написания данного сендбокса Windows версия уже давно существовала и не требовала написания кода без использования памяти (даже стека). Вообще идея запуска двух потоков с разным уровнем доверия в одном процессе кажется мне несколько, как бы это сказать… неочевидной, что ли.
О полном доверии речи не идет — лишь о доверии, необходимом для дублирования хендлов. Не доверяешь процессу — ставь брокера. Вот только чаще всего хендлы открываются процессом с более высокими привилегиями и копируются в процесс с более низкими (см, например, инфраструктуру брокеров в win8 или опять же песочницы Хрома/ИЕ).
Вы как-то странно понимаете термин безопасность. По факту — она есть.
В POSIX она «implementation defined». Даже для файлов, где chmod сотоварищи пришлось оставить (посмотрите так же всякие open/fopen и прочие — попробуйте найти хоть какое то упоминание того, что конкретно может привести к EACCES), не говоря уже о kill и прочих штуках традиционно требовавших рута (и целого букета дополнительных ad-hoc правил, позволяющих обойти ограниченность классической модели безопасности).
Так вот я никак не пойму, как можно создать анонимный пайп с сохранением границ сообщений. А именованные пайпы надо с локальными сокетами сравнивать.
Ок. Вот только это Win32 вызов (к некоторым частям которого я имею немало претензий). И именованные и анонимные пайпы сводятся к NtCreateNamedPipeFile, который позволяет указать режим.
Короче вам асинхронный ввод-вывод подавай, иначе не православно :)
Да, именно так :-)
Ваши собственные слова. Вот видите — реализацию можно и пофиксить. А тезис об ущербности epoll опровергнут выше.
В целом вынужден согласиться. epoll в будущем вполне можно будет использовать для ожидания окончания асинхронных операций. Причем в рамках текущего интерфейса — не прибегая к костылям типа signalfd сотоварищи. Кстати, насчет kqueue, официальная документация прямо и непосредственно упоминает AIO. Кроме того, поверхностный поиск вернул множество результатов с таким контекстом использования. Так что похоже kqueue все-таки получше epoll прямо сейчас.
Пруф или не было.
Очередная самоцитата:
epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом
И да, я уже согласился, что epoll «в принципе» может быть использован. В данном случае я самоцитируюсь для того, чтобы показать, что моя претензия к epoll изначально заключалась в отсутсвии поддержки асинхронного I/O.
Кстати стандартом предусмотрена функция posix_spawn(), которая работает как fork+exec и может быть реализована отдельным системным вызовом
Так а кто ж спорит. posix_spawn и pthread_create — то что должно было использоваться изначально. Речь о том, что проблемы у fork-а (причем опять же, не я начал это сравнение), а не о том, что ничего другого нет.
Я их наизусть знаю. Так какие «проблемы» вы видите?
Проблема в том, что fork предполагает исключительно однопоточный контекст (при этом «поток» является одновременно и «процессом» — контейнером ресурсов). «Разветвление» потока исполнения автоматически приводит к «разветвлению» ресурсов, что уже требует всяких хитростей в случае эксклюзивного владения. Введение POSIX thread-ов запутало ситуацию еще больше. pthread_atfork — попытка решения проблемы и, соответственно, признание ее существования.
Просто мне идея имперсонации кажется плохим техническим решением. Но по этому вопросу я себя экспертом не считаю, вот и спрашиваю вашего мнения.
Не знаю откуда у Вас такое впечатление. Может Вы просто не совсем правильно понимаете призвание имперсонации. Это не механизм защиты (например, понижения привилегий для исполнения недоверенного кода), это механизм, облегчающий написание сервера: вместо того, чтобы самостоятельно сверять токен с дескриптором безопасности перед каждой операцией, эта работа возлагается на ОС: «пока не попрошу обратного сверяй весь доступ из этого потока с вот этим вот токеном, потому что мне лень делать это самостоятельно». То есть он позволяет сэкономить на вызовах Get(Named)SecurityInfo/AccessCheck и больше ничего (при этом делая код более надежным исключая человеческий фактор).
Многие идеи, воплощенные в VMS и позже NT существовали еще в MULTICS и при создании UNIX были просто напросто выброшены. Так что Вы уж определитесь с позицией: либо конкретные реализации живут с 70-х и юниксы тех времен те же, что сейчас, либо идеи живут и развиваются. Идеи, воплощенные в NT тоже не возникли на пустом месте и тоже постепенно переносятся в те же юниксы (взять хотя бы ту же модель безопасности: солярисы, BSD, XNU/OSX и прочие переняли NT-шное файловое подмножество ACL-ов один в один)
Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Ну хотя бы тем, что у процесса, в которого дуплицируется хендл, нет никакого контроля над тем, что в него дуплицирует.
Неправда.
hTargetProcessHandle [in]
A handle to the process that is to receive the duplicated handle. The handle must have the PROCESS_DUP_HANDLE access right.
Все контроллируется теми же средствами, что и весь остальной доступ в системе.
Примерная аналогия — два процесса могут общаться через пайп; а могут путем прямой записи в адресное пространство друг друга. Так вот DuplicateHandle — это второе. А если нам нужно получить хендл из непривилегированного процесса?
Еще раз: весь доступ контроллируется Security Reference Monitor-ом. Если непривелигированному процессу нужно дублировать хендлы в процесс, который не получается открыть самостоятельно, хендл этого процесса с PROCESS_DUP_HANDLE можно получить и из других источников.
Цитата вобще ни о чем.
Цитата о том, что сам POSIX говорит о том, что вопросы безопасности стандарта не касаются.
Повторюсь:
Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Речь про сокеты. Какая разница? Вам шашечки или ехать?
Перечитайте еще раз контекст. Изначально речь шла о пайпах.
Кстати на MacOS kqueue не поддерживает AIO в принципе. На FreeBSD, не уверен что AIO может работать с чем-то помимо файлов.
Спасибо, что поправили — признаться честно, не знал. Хотя могу поклясться, что точно читал про асинхронный ввод/вывод с kqueue: может я ошибаюсь, а может и автор той статьи — найти ее сейчас не представляется возможным, так что готов принять позицию, что kqueue настолько же плох, насколько и epoll.
Я, честно говоря ожидал, что вы будете сравнивать AIO vs. non-blocking IO.
Именно это я и сделал для epoll. И да, принципиальная разница есть, по крайней мере при высоких нагрузках (а зачем еще возиться с epoll/kqueue или IOCP).
таблица она же иерархическая, все ветки можно сразу не заполнять
У иерархии всего два уровня. Зависимость от размера рабочего набора родительского процесса все равно линейная.
Кстати, какие вы видите проблемы в сочетании fork+треды?
А Вы почитайте вот прямо сам SUS, разделы fork, pthread_atfork (ссылки я уже приводил), там все рассматривается.
Как вы кстати оцениваете концепцию имперсонации в windows?
А давайте Вы мне не будете экзамен устраивать. Тем более по «концепциям». Не знаю, что Вы хотите услышать. Поэтому вот Вам такой же расплывчатый ответ: имперсонация имеет области применимости (исполнение доверенного кода с модифицированными правами: чаще всего сервер имперсонирует клиента и исполняет СВОЙ код). Внутри своей области применимости — это отличный механизм, за пределами — иногда может быть с успехом использован (как например в хромовой песочнице для винды), но чаще всего использовать ЛЮБОЙ механизм за пределами области применимости — ОЧЕНЬ плохая идея.
Да ради бога. Но не соизволите привести пример моего фанатизма? До сих пор я как раз пытался аргументировать каждое свое утверждение, а в ответ получал в основном в духе «противопоставить нечего».
Нет, Cygwin работает в Win32 подсистеме и вместо CoW использует полное копирование.
ужас какой
Что ужасного? Процесс в NT — один из нескольких десятков типов объектов ядра, любые операции с ним проходят через Security Reference Monitor и являются securable. Никаких special case-ов: доступ ко всем объектам проверятся одинаково и обязательно. Самое забавное, что больше всего костылей и каких то «отфонарных» правил в USER/GDI — исторически они были полностью в user mode и после переноса в ядро семантику менять было уже поздно.
p.s. ваши посты интересно читать очень, но уж очень какая-то радикальная позиция
Ой, да никакой радикальности. Посмотрите сотни постов про «сегодня я перевел на линукс школу» и пр — есть ли ХОТЬ В ОДНОМ что нибудь «Да задолбали со своим линуксом — почему не какая нибудь другая ОС?». Гляньте первый комментарий в этом посте. А теперь представьте на секунду, что дизайн Линукса (и POSIX) действительно убог и лучше бы держаться от него подальше, перечитайте первый комментарий еще раз и попробуйте поставить себя на мое место.
А как на виндузе передать хэндл в другой процесс? Про DuplicateHandleEx знаю, но это решение на порядки хуже.
Потрудитесь показать, чем же хуже. Я вот например увидев на какие извращения пошли бедные создатели Хрома для Линукса — даже зауважал их. Незадача оказалась в том, что seccomp не поддерживает recvmsg. На винде все замечательно работает через NtDuplicateHandle.
В линуксе создание процесса ничего не стоит, в отличие от винды. Это куда более серьезное подспорье для декомпозиции чем так критикуемый вами sh скрипт.
Ответил выше. fork помимо проблем с семантикой, просто тупо дороже. Про vfork знаю, но он вообще ничего не гарантирует. Вот такой вот чистый и красивый POSIX: у нас есть системный вызов, но реализациям позволено его реализовывать как угодно.
«Безопасность» если что поддерживается — есть базовая UNIX модель прав доступа, есть ACL.
One of the fundamental security problems with many historical UNIX systems has been that the privilege mechanism is monolithic-a user has either no privileges or all privileges. Thus, a successful «trojan horse» attack on a privileged process defeats all security provisions. Therefore, POSIX.1 allows more granular privilege mechanisms to be defined. For many historical implementations of the UNIX system, the presence of the term «appropriate privileges» in POSIX.1 may be understood as a synonym for «superuser» (UID 0). However, other systems have emerged where this is not the case and each discrete controllable action has appropriate privileges associated with it. Because this mechanism is implementation-defined, it must be described in the conformance document. Although that description affects several parts of POSIX.1 where the term «appropriate privilege» is used, because the term «implementation-defined» only appears here, the description of the entire mechanism and its effects on these other sections belongs in this equivalent section of the conformance document. This is especially convenient for implementations with a single mechanism that applies in all areas, since it only needs to be described once.
Вот как то так. Безопасность в POSIX — implementation defined, что уже на много порядков лучше «классической юникс безопасности». ACL-ов в POSIX никогда не было (мы же не будем считать отозванный 15 лет назад ЧЕРНОВИК настоящим стандартом?).
Message-oriented каналы тоже есть
Те, которые pipe() или те которые socketpair()? Если присмотреться, я говорил именно о пайпах.
kqueue использует тот же принцип, что и IOCP. Какие там подробности реализации — уже неважно — огрехи реализации легко исправимы (даже если таковые имеются), огрехи дизайна — нет. epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом.
А Вы посмотрите на POSIX тот же — там все написано. fork используется либо для создания потока исполнения, либо для создания нового процесса. Давайте посмотрим на затраты:
fork+exec vs CreateProcess: fork сначала выделяет и инициализирует новое адресное пространство (PDE/PTE) только для того, чтоб немедленно его дискарднуть. Расходы не то, чтобы сильно большие, но линейно зависят от количества физической памяти, доступной родительскому процессу на момент форка. Что еще хуже, любые области доступные родительскому процессу на запись в момент форка должны быть помечены как read-only (чтоб дать pagefault обработчику возможность сделать CoW), а в момент exec — пометить все обратно.
fork vs CreateThread: опять таки, fork КОПИРУЕТ адресное пространство (повторюсь, не саму память, а именно таблицы страниц, которые указывают на те же самые страницы). Точно так же вся r/w память перепомечается как ro и прочая ненужная активность, которой можно избежать при использовании потоков.
В SUS описаны проблемы, возникающие у fork-а с потоками, но этом не все проблемы. К примеру, fork — один из основных виновников того, что приходится overcommit-ить память (помните ту футболку «malloc never fails»? Так вот в случае Линукса — это чистейшая правда.) и вводить OOM Killer. Кстати, NtCreateProcess поддерживает семантику fork: если ему передать родительский процесс, но не передать секцию — родительский процесс форкнется. Для Win32 подсистемы это не работает, потому что каждый win32 процесс регистрируется у csrss, а форкнуть эту регистрацию невозможно, а вот Interix и SFU/SUA использовали эту возможность для нативной реализации fork.
по поводу select-это в винде он используется на всю катушку
Справедливости ради, стоит отметить, что WinSock-овая реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе, хотя все так же использует алгоритмы с линейной сложностью (это в select by design). И нет ни о какой катушке речи не идет, все хоть минимально претендующее на серьезность использует IOCP.
Что же до юникс сокетов — костыль с пересылкой дескрипторов нужен потому, что нет возможности «открыть» процесс и работать с ним напрямую (ptrace доступен только суперпользователю, который, кстати, является еще один костылем для того чтобы обойти ограничения классической юникс безопасности).
Мдя, в линуксе я знаю больше Вашего (хотя я никогда и не особо стремился глубоко его изучать).
Да, реализаций asyncIO в ванильном ядре две.
Одна из реализаций — в glibc и для каждого запроса создает новый поток. Но вторая реализация асинхронного ввода/вывода в ядре таки есть — в «block layer» (они вообще слышали хотя бы о DRY не говоря уже о более «продвинутых» принципах).
И обе работают, и каждая удобнее, чем IOCP.
Вы даже примерно не представляете о чем говорите, да? IOCP можно сравнивать с epoll или, там, kqueue. При чем здесь AIO вообще и каким место оно удобнее?
Create* стал удобнее fork через mingw? Это разные подходы, но использовать удобнее pthead.
Да, CreateProcess/CreateThread удобнее потому что РАБОТАЕТ, а fork только создает проблемы.
Что вы на select наговариваете. Вам в одном потоке зачем 1024 дескриптора? За такое по рукам бьют…
То есть если я правильно понимаю, Вы сейчас хотите «защищать» убожество select? Мдя. Позвольте Вас спросить, Вы вообще хотя бы примерно знаете как работает IOCP, чтобы обсуждать его?
С распространенностью я еще готов отчасти согласиться. Эмбед кругом и там частенько Линукс. В остальном — мимо. Инструментарий убог: для ядра — так вообще даже отладчика не было еще 5 лет назад — а все потому что Линус «не верит» в интерактивную отладку да и сейчас отладчик хромой и кривой. Статические/динамические анализаторы кода уровня driver verifier/static driver verifier? Да блин, автоматический поиск символов и чекаут соответствующих исходников есть хотя бы (symbol server/source server)?
Что же до подробной документированности, я давно ищу что-нибудь поновее этого. Да, я знаю о kernel-docs.txt и проблема как раз в том, что это лучший источник, который там приводится. И это не говоря уже о чем нибудь типа MSDN с подробными секциями описательными и референсными секциями.
Не в обиду, но вы застряли в прошлом веке — и средствами, и инструментами, и мыслями…
Мдя, не в обиду, конечно, но именно ЛЮДИ, подобные Вам — основная проблема Линукса. Вы совершенно не знаете ничего ни о винде («средствах, инструментариях»), ни обо мне («мылях»), но при этом УВЕРЕНЫ, что противопоставить нечего.
О, epoll — просто отличный пример, ибо в POSIX (к которому epoll не относится никаким боком) и Linux в частности (который относится) традиционно все ОЧЕНЬ ХРЕНОВО с асинхронным вводом/выводом. IOCP появился в винде 20 лет назад и с первой же версии был сделан правильно (хотя бы тот факт, что он до сих пор используется практически без изменений, хотя и с оговоркой, что современные скорости сетевых соединений требуют узких оптимизаций типа registered I/O). select — просто позорище. FD_SET — битовая маска, которая в первых реализациях занимала один регистр — 16 бит, потом ситацию улучшили расширив битовый набор до тысячи (ага, тысячи одновременных соединений достаточно каждому), ухудшив при этом производительность (алгоритмы с линейным временем, там где обычная очередь может обеспечить константное? SRSLY?). /dev/poll — улучшил ситуацию еще немного при этом все еще используя алгоритмы с линейным временем. /dev/epoll — еще чуть улучшил ситуацию, при этом все еще не дотягивает до механизма, который использовался 20 лет назад — он не является асинхронным (в связи с этим возникает еще куча проблем: лишние копирования, локальность кешей, увеличение задержек при hiperf для дополнительных раундтрипов в ядро и пр..). При этом POSIX получил свое асинхронное API (полностью отдельное от синхронного) только, если не ошибаюсь в 2008-м, а тот же Linux имеет ДВЕ реализации aio_* вызовов, ни одна из которых не предназначена для работы с сетью.
fork — настолько плохая идея (он плохо совместим с потоками, он напрочь убивает нормальный аккаунтинг памяти, он смешивает понятия контейнера ресурсов и единицы исполнения и пр..), что POSIX (почитайте о некоторых проблемах прямо в стандарте секция rationale, ну или в этой попытке решить некоторые из проблем) говорит следующее:
There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.
Что забавно, в обоих случаях, fork менее эффективен, чем CreateThread и CreateProcess соответственно. Это один из немногих случаев, когда проблемы настолько существенны и очевидны, что их описание включено в текст стандарта (самым большим признанием проблем было исключение любого описания безопасности).
named pipes в \\.\pipe\ — wtf
А что не так? Это просто симлинк на \Device\NamedPipe. Причем, если уж мы этого коснулись, скажите мне сами, что лучше для идентификации устройств — free-form строки или два БАЙТА (major/minor number — хотя позднее было введено расширение при помощи магического значения этих байт)? Ну и совсем мелочь, а неприятно: каналы в POSIX не поддерживают фрейминг (message oriented в терминах винды).
unix сокетов нет
Странная претензия, а в POSIX нет LPC/ALPC. Давайте будем обсуждать задачи, а не конкретные способы их решения.
mmap только в виде file-mapping
Не очень понимаю о чем Вы. ZwCreateSection/ZwMapViewOfSection дают возможность как мепить файлы, так и разделять память без какого либо файла («pagefile backed» — просто не совсем удачное НАЗВАНИЕ, ибо таким секциям абсолютно плевать на существование pagefile-а). Каким образом это существенно отличается от mmap?
Хороший дизайн должен. Лично мне, да. И если есть пример хорошего дизайна, лично я не вижу ни единой причины использовать плохой при обучении.
Что же до hh и пр, раз уж Вы использовали это как аргумент, то давайте Вы сами посчитаете количество вакансий на одно и на другое, но только в одной и той же выборке (один город, один регион, одна страна и пр..). Прошу отметить, это не я начинал доказывать, что знание устройства одной конкретной ОС — совершенно не котируется на рынке. Постарайтесь доказать Ваше же утверждение. И да, еще раз повторюсь, к «фундаментальности» знаний наличие вакансий на рынке мало относится.
Насчет Самсунга, хоть это и ничего не означает, просто забавно, что Вы упомянули, потому как конкретно для них я разрабатывал НЕСКОЛЬКО драйверов. Под Windows.
Каким образом ReactOS оторван от жизни? Он дает общее представление об архитектуре NT (из-за того, что это реимплементация там, естественно, есть отличия от оригинала, но я сильно сомневаюсь, что в рамках одного курса дело дойдет до рассмотрения подобных нюансов). Да, кстати, почему Вы желаете ограничиться только эмбедом?
Я честно говоря затрудняюсь вспомнить вообще хоть одну вещь, которая в Linux-е сделана лучше чем в NT.
Насчет поста — пытаюсь, но по тому сколько времени я уже «пытаюсь» — не уверен, что я его закончу в обозримом будущем.
Mach/L4/Minix не имееют POSIX-а в ядре, а слои совместимости клепать — так это даже хорошо. Вон NT тоже POSIX совместимая (была, пока это еще требовалось для продажи в госучреждения США), при этом насколько я помню, ни одни Linux дистрибутив не получал сертификата POSIX-совместимости.
Да нет, это Вы из «этих». Одного факта, что человек «болеет за другую футбольную команду» уже достаточно, чтоб снисходительно сбрасывать со счетов любые аргументы.
Есть такая удобная штука, которая называется Open/Closed Principle (буква O вSOLID дизайне). Хороший дизайн должен предоставлять возможность расширения БЕЗ необходимости модификации оригинального кода.
В моем родном городе (Запорожье, Украина) я знаю как минимум ДВЕ конторы, которые занимаются низкоуровневой разработкой под Windows. Это крупный индустриальный центр и глубокая культурная/интеллектуальная провинция. В соседнем Днепропетровске я знаю/слышал о десятке подобных контор (при том, что я там не живу). Не видел ни одной которая бы занималась «изменением кода ядра линукс и портированием его под новые платформы» — может Вы подскажете?
Знание платформы (низкоуровневой или нет) нужно для того, чтобы писать ПОД платформу, а не обязательно заниматься разработкой самой платформы. Но даже это не важно, потому как курс должен быть ОБЩИМ, применимый к операционным системам вообще. И Линукс здесь — один из худших выборов.
А на фига матан и кванты? Можно миникс, можно вообще Mach или L4. Можно NT (WRK). А можно и Linux — никто не спорит, просто этот выбор надо бы обосновать.
Интересно, а чем вам posix не нравится, почему так «не надо делать»?
О, на эту тему надо писать длинный пост, на который я не могу собраться уже лет 5. Вкратце — там абсолютно нет дизайна. Грязная заплатка на грязной заплатке и все это выливается в какую то невообразимую кашу. Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Целый раздел посвящен шелл-скриптингу — это вообще закопать, ибо оно не справляется даже с базовыми целями поставленными перед ним: декомпозиция системы на мелкие независимые модули, которые легко комбинируются друг с другом.
В остальном практически каждая существенная подсистема (деление на «подсистемы» чисто условное, ибо никакой подобной группировки POSIX/SUS не описывает) имеет огромные торчащие наружу изъяны: обработка исключительных ситуаций, ввод/вывод, управление памятью и т.д…
Ага, давайте замечать сотни разных линуксов кругом — в тостерах и микроволновках, а реальные Windows-ы (а дизайн ReactOS — это именно что дизайн NT) проигнорируем.
Я еще согласен с предложениями изучать на упрощенных ОС типа Minix-а, но если брать реальную ОС и преподавать ее дизайн, то лучше брать ОС, которая действительно была СПРОЕКТИРОВАНА и имеет этот самый дизайн.
Это не ответ. Теперь Вам придется ответить что «фундаментального» в POSIX.
Вообще, POSIX конечно преподавать надо, но дополнительным материалом в качестве примера того, как не надо делать. Посвящать ему отдельный курс или заменять им курс «Операционные системы» — неприемлемо.
Я абсолютно спокоен. Более того, это один из нечастых случаев, когда вместо обсуждения моей матушки завязалась техническая дискуссия (хотя и были попытки в духе «вы их этих» и «застрял в прошлом веке»). Я могу ошибаться (все могут), я могу не суметь донести свою точку зрения, но само наличие такой дискуссии — огромный плюс. Что же до идеальности. У меня вот есть тяга к микроядрам с capability-based безопасностью. Ничего не могу с собой поделать. NT не является ни тем ни другим (хотя по многим пунктам достаточно близко — особенно секьюрити), так что нет — не идеально даже ядро, а уж про юзермод (и особенно про Win32 как прямого наследника Win16) я и сам порассказать могу. Моя позиция касательно конкретно данного поста в том, что NT ЗНАЧИТЕЛЬНО лучше Linux в плане дизайна.
Ну, ок. Для предметного разговора мне нужна модель угрозы. Покажите, пожалуйста, конкретный пример ситуации, когда процесс, наделенный правами станет эти права абьюзить (не из-за бага — которых может быть полно и в любом другом месте, а именно как угрозу). Отмечу лишь, что sendmsg/recvmsg легко реализуется на основе NtDuplicateHandle при помощи доверенного брокера (если это ДЕЙСТВИТЕЛЬНО понадобится, что само по себе еще не доказано), а вот реализовать NtDuplicateHandle на основе сокетов — не получится (как пример: как мне восстановить связь с клиентами после рестарта демона). Ну или уже приведенный пример seccomp sandbox. При этом на момент написания данного сендбокса Windows версия уже давно существовала и не требовала написания кода без использования памяти (даже стека). Вообще идея запуска двух потоков с разным уровнем доверия в одном процессе кажется мне несколько, как бы это сказать… неочевидной, что ли.
О полном доверии речи не идет — лишь о доверии, необходимом для дублирования хендлов. Не доверяешь процессу — ставь брокера. Вот только чаще всего хендлы открываются процессом с более высокими привилегиями и копируются в процесс с более низкими (см, например, инфраструктуру брокеров в win8 или опять же песочницы Хрома/ИЕ).
В POSIX она «implementation defined». Даже для файлов, где chmod сотоварищи пришлось оставить (посмотрите так же всякие open/fopen и прочие — попробуйте найти хоть какое то упоминание того, что конкретно может привести к EACCES), не говоря уже о kill и прочих штуках традиционно требовавших рута (и целого букета дополнительных ad-hoc правил, позволяющих обойти ограниченность классической модели безопасности).
Ок. Вот только это Win32 вызов (к некоторым частям которого я имею немало претензий). И именованные и анонимные пайпы сводятся к NtCreateNamedPipeFile, который позволяет указать режим.
Да, именно так :-)
В целом вынужден согласиться. epoll в будущем вполне можно будет использовать для ожидания окончания асинхронных операций. Причем в рамках текущего интерфейса — не прибегая к костылям типа signalfd сотоварищи. Кстати, насчет kqueue, официальная документация прямо и непосредственно упоминает AIO. Кроме того, поверхностный поиск вернул множество результатов с таким контекстом использования. Так что похоже kqueue все-таки получше epoll прямо сейчас.
Очередная самоцитата:
И да, я уже согласился, что epoll «в принципе» может быть использован. В данном случае я самоцитируюсь для того, чтобы показать, что моя претензия к epoll изначально заключалась в отсутсвии поддержки асинхронного I/O.
Так а кто ж спорит. posix_spawn и pthread_create — то что должно было использоваться изначально. Речь о том, что проблемы у fork-а (причем опять же, не я начал это сравнение), а не о том, что ничего другого нет.
Проблема в том, что fork предполагает исключительно однопоточный контекст (при этом «поток» является одновременно и «процессом» — контейнером ресурсов). «Разветвление» потока исполнения автоматически приводит к «разветвлению» ресурсов, что уже требует всяких хитростей в случае эксклюзивного владения. Введение POSIX thread-ов запутало ситуацию еще больше. pthread_atfork — попытка решения проблемы и, соответственно, признание ее существования.
Не знаю откуда у Вас такое впечатление. Может Вы просто не совсем правильно понимаете призвание имперсонации. Это не механизм защиты (например, понижения привилегий для исполнения недоверенного кода), это механизм, облегчающий написание сервера: вместо того, чтобы самостоятельно сверять токен с дескриптором безопасности перед каждой операцией, эта работа возлагается на ОС: «пока не попрошу обратного сверяй весь доступ из этого потока с вот этим вот токеном, потому что мне лень делать это самостоятельно». То есть он позволяет сэкономить на вызовах Get(Named)SecurityInfo/AccessCheck и больше ничего (при этом делая код более надежным исключая человеческий фактор).
Неправда.
Все контроллируется теми же средствами, что и весь остальной доступ в системе.
Еще раз: весь доступ контроллируется Security Reference Monitor-ом. Если непривелигированному процессу нужно дублировать хендлы в процесс, который не получается открыть самостоятельно, хендл этого процесса с PROCESS_DUP_HANDLE можно получить и из других источников.
Цитата о том, что сам POSIX говорит о том, что вопросы безопасности стандарта не касаются.
Повторюсь:
Перечитайте еще раз контекст. Изначально речь шла о пайпах.
Спасибо, что поправили — признаться честно, не знал. Хотя могу поклясться, что точно читал про асинхронный ввод/вывод с kqueue: может я ошибаюсь, а может и автор той статьи — найти ее сейчас не представляется возможным, так что готов принять позицию, что kqueue настолько же плох, насколько и epoll.
Именно это я и сделал для epoll. И да, принципиальная разница есть, по крайней мере при высоких нагрузках (а зачем еще возиться с epoll/kqueue или IOCP).
У иерархии всего два уровня. Зависимость от размера рабочего набора родительского процесса все равно линейная.
А Вы почитайте вот прямо сам SUS, разделы fork, pthread_atfork (ссылки я уже приводил), там все рассматривается.
А давайте Вы мне не будете экзамен устраивать. Тем более по «концепциям». Не знаю, что Вы хотите услышать. Поэтому вот Вам такой же расплывчатый ответ: имперсонация имеет области применимости (исполнение доверенного кода с модифицированными правами: чаще всего сервер имперсонирует клиента и исполняет СВОЙ код). Внутри своей области применимости — это отличный механизм, за пределами — иногда может быть с успехом использован (как например в хромовой песочнице для винды), но чаще всего использовать ЛЮБОЙ механизм за пределами области применимости — ОЧЕНЬ плохая идея.
Что ужасного? Процесс в NT — один из нескольких десятков типов объектов ядра, любые операции с ним проходят через Security Reference Monitor и являются securable. Никаких special case-ов: доступ ко всем объектам проверятся одинаково и обязательно. Самое забавное, что больше всего костылей и каких то «отфонарных» правил в USER/GDI — исторически они были полностью в user mode и после переноса в ядро семантику менять было уже поздно.
Ой, да никакой радикальности. Посмотрите сотни постов про «сегодня я перевел на линукс школу» и пр — есть ли ХОТЬ В ОДНОМ что нибудь «Да задолбали со своим линуксом — почему не какая нибудь другая ОС?». Гляньте первый комментарий в этом посте. А теперь представьте на секунду, что дизайн Линукса (и POSIX) действительно убог и лучше бы держаться от него подальше, перечитайте первый комментарий еще раз и попробуйте поставить себя на мое место.
Потрудитесь показать, чем же хуже. Я вот например увидев на какие извращения пошли бедные создатели Хрома для Линукса — даже зауважал их. Незадача оказалась в том, что seccomp не поддерживает recvmsg. На винде все замечательно работает через NtDuplicateHandle.
Ответил выше. fork помимо проблем с семантикой, просто тупо дороже. Про vfork знаю, но он вообще ничего не гарантирует. Вот такой вот чистый и красивый POSIX: у нас есть системный вызов, но реализациям позволено его реализовывать как угодно.
Appropriate Privileges
Вот как то так. Безопасность в POSIX — implementation defined, что уже на много порядков лучше «классической юникс безопасности». ACL-ов в POSIX никогда не было (мы же не будем считать отозванный 15 лет назад ЧЕРНОВИК настоящим стандартом?).
Те, которые pipe() или те которые socketpair()? Если присмотреться, я говорил именно о пайпах.
kqueue использует тот же принцип, что и IOCP. Какие там подробности реализации — уже неважно — огрехи реализации легко исправимы (даже если таковые имеются), огрехи дизайна — нет. epoll — хуже хотя бы потому, что никак не помогает с асинхронным вводом/выводом.
fork+exec vs CreateProcess: fork сначала выделяет и инициализирует новое адресное пространство (PDE/PTE) только для того, чтоб немедленно его дискарднуть. Расходы не то, чтобы сильно большие, но линейно зависят от количества физической памяти, доступной родительскому процессу на момент форка. Что еще хуже, любые области доступные родительскому процессу на запись в момент форка должны быть помечены как read-only (чтоб дать pagefault обработчику возможность сделать CoW), а в момент exec — пометить все обратно.
fork vs CreateThread: опять таки, fork КОПИРУЕТ адресное пространство (повторюсь, не саму память, а именно таблицы страниц, которые указывают на те же самые страницы). Точно так же вся r/w память перепомечается как ro и прочая ненужная активность, которой можно избежать при использовании потоков.
В SUS описаны проблемы, возникающие у fork-а с потоками, но этом не все проблемы. К примеру, fork — один из основных виновников того, что приходится overcommit-ить память (помните ту футболку «malloc never fails»? Так вот в случае Линукса — это чистейшая правда.) и вводить OOM Killer. Кстати, NtCreateProcess поддерживает семантику fork: если ему передать родительский процесс, но не передать секцию — родительский процесс форкнется. Для Win32 подсистемы это не работает, потому что каждый win32 процесс регистрируется у csrss, а форкнуть эту регистрацию невозможно, а вот Interix и SFU/SUA использовали эту возможность для нативной реализации fork.
Справедливости ради, стоит отметить, что WinSock-овая реализация select по крайней мере на накладывает ограничений на количество дескрипторов в наборе, хотя все так же использует алгоритмы с линейной сложностью (это в select by design). И нет ни о какой катушке речи не идет, все хоть минимально претендующее на серьезность использует IOCP.
Что же до юникс сокетов — костыль с пересылкой дескрипторов нужен потому, что нет возможности «открыть» процесс и работать с ним напрямую (ptrace доступен только суперпользователю, который, кстати, является еще один костылем для того чтобы обойти ограничения классической юникс безопасности).
Одна из реализаций — в glibc и для каждого запроса создает новый поток. Но вторая реализация асинхронного ввода/вывода в ядре таки есть — в «block layer» (они вообще слышали хотя бы о DRY не говоря уже о более «продвинутых» принципах).
Вы даже примерно не представляете о чем говорите, да? IOCP можно сравнивать с epoll или, там, kqueue. При чем здесь AIO вообще и каким место оно удобнее?
Да, CreateProcess/CreateThread удобнее потому что РАБОТАЕТ, а fork только создает проблемы.
То есть если я правильно понимаю, Вы сейчас хотите «защищать» убожество select? Мдя. Позвольте Вас спросить, Вы вообще хотя бы примерно знаете как работает IOCP, чтобы обсуждать его?
С распространенностью я еще готов отчасти согласиться. Эмбед кругом и там частенько Линукс. В остальном — мимо. Инструментарий убог: для ядра — так вообще даже отладчика не было еще 5 лет назад — а все потому что Линус «не верит» в интерактивную отладку да и сейчас отладчик хромой и кривой. Статические/динамические анализаторы кода уровня driver verifier/static driver verifier? Да блин, автоматический поиск символов и чекаут соответствующих исходников есть хотя бы (symbol server/source server)?
Что же до подробной документированности, я давно ищу что-нибудь поновее этого. Да, я знаю о kernel-docs.txt и проблема как раз в том, что это лучший источник, который там приводится. И это не говоря уже о чем нибудь типа MSDN с подробными секциями описательными и референсными секциями.
Мдя, не в обиду, конечно, но именно ЛЮДИ, подобные Вам — основная проблема Линукса. Вы совершенно не знаете ничего ни о винде («средствах, инструментариях»), ни обо мне («мылях»), но при этом УВЕРЕНЫ, что противопоставить нечего.
fork — настолько плохая идея (он плохо совместим с потоками, он напрочь убивает нормальный аккаунтинг памяти, он смешивает понятия контейнера ресурсов и единицы исполнения и пр..), что POSIX (почитайте о некоторых проблемах прямо в стандарте секция rationale, ну или в этой попытке решить некоторые из проблем) говорит следующее:
Что забавно, в обоих случаях, fork менее эффективен, чем CreateThread и CreateProcess соответственно. Это один из немногих случаев, когда проблемы настолько существенны и очевидны, что их описание включено в текст стандарта (самым большим признанием проблем было исключение любого описания безопасности).
А что не так? Это просто симлинк на \Device\NamedPipe. Причем, если уж мы этого коснулись, скажите мне сами, что лучше для идентификации устройств — free-form строки или два БАЙТА (major/minor number — хотя позднее было введено расширение при помощи магического значения этих байт)? Ну и совсем мелочь, а неприятно: каналы в POSIX не поддерживают фрейминг (message oriented в терминах винды).
Странная претензия, а в POSIX нет LPC/ALPC. Давайте будем обсуждать задачи, а не конкретные способы их решения.
Не очень понимаю о чем Вы. ZwCreateSection/ZwMapViewOfSection дают возможность как мепить файлы, так и разделять память без какого либо файла («pagefile backed» — просто не совсем удачное НАЗВАНИЕ, ибо таким секциям абсолютно плевать на существование pagefile-а). Каким образом это существенно отличается от mmap?
Что же до hh и пр, раз уж Вы использовали это как аргумент, то давайте Вы сами посчитаете количество вакансий на одно и на другое, но только в одной и той же выборке (один город, один регион, одна страна и пр..). Прошу отметить, это не я начинал доказывать, что знание устройства одной конкретной ОС — совершенно не котируется на рынке. Постарайтесь доказать Ваше же утверждение. И да, еще раз повторюсь, к «фундаментальности» знаний наличие вакансий на рынке мало относится.
Насчет Самсунга, хоть это и ничего не означает, просто забавно, что Вы упомянули, потому как конкретно для них я разрабатывал НЕСКОЛЬКО драйверов. Под Windows.
Каким образом ReactOS оторван от жизни? Он дает общее представление об архитектуре NT (из-за того, что это реимплементация там, естественно, есть отличия от оригинала, но я сильно сомневаюсь, что в рамках одного курса дело дойдет до рассмотрения подобных нюансов). Да, кстати, почему Вы желаете ограничиться только эмбедом?
Насчет поста — пытаюсь, но по тому сколько времени я уже «пытаюсь» — не уверен, что я его закончу в обозримом будущем.
Mach/L4/Minix не имееют POSIX-а в ядре, а слои совместимости клепать — так это даже хорошо. Вон NT тоже POSIX совместимая (была, пока это еще требовалось для продажи в госучреждения США), при этом насколько я помню, ни одни Linux дистрибутив не получал сертификата POSIX-совместимости.
Да нет, это Вы из «этих». Одного факта, что человек «болеет за другую футбольную команду» уже достаточно, чтоб снисходительно сбрасывать со счетов любые аргументы.
Есть такая удобная штука, которая называется Open/Closed Principle (буква O вSOLID дизайне). Хороший дизайн должен предоставлять возможность расширения БЕЗ необходимости модификации оригинального кода.
В моем родном городе (Запорожье, Украина) я знаю как минимум ДВЕ конторы, которые занимаются низкоуровневой разработкой под Windows. Это крупный индустриальный центр и глубокая культурная/интеллектуальная провинция. В соседнем Днепропетровске я знаю/слышал о десятке подобных контор (при том, что я там не живу). Не видел ни одной которая бы занималась «изменением кода ядра линукс и портированием его под новые платформы» — может Вы подскажете?
Знание платформы (низкоуровневой или нет) нужно для того, чтобы писать ПОД платформу, а не обязательно заниматься разработкой самой платформы. Но даже это не важно, потому как курс должен быть ОБЩИМ, применимый к операционным системам вообще. И Линукс здесь — один из худших выборов.
О, на эту тему надо писать длинный пост, на который я не могу собраться уже лет 5. Вкратце — там абсолютно нет дизайна. Грязная заплатка на грязной заплатке и все это выливается в какую то невообразимую кашу. Начиная с того, что называется «scope»: имеет три функции Бесселя третьего порядка, но совершенно не имеет безопасности. Нет ее в POSIX (используется обтекаемый термин «appropriate persmissions»). Действительно, зачем интерфейсу операционной системы средства безопасности?
Целый раздел посвящен шелл-скриптингу — это вообще закопать, ибо оно не справляется даже с базовыми целями поставленными перед ним: декомпозиция системы на мелкие независимые модули, которые легко комбинируются друг с другом.
В остальном практически каждая существенная подсистема (деление на «подсистемы» чисто условное, ибо никакой подобной группировки POSIX/SUS не описывает) имеет огромные торчащие наружу изъяны: обработка исключительных ситуаций, ввод/вывод, управление памятью и т.д…
Я еще согласен с предложениями изучать на упрощенных ОС типа Minix-а, но если брать реальную ОС и преподавать ее дизайн, то лучше брать ОС, которая действительно была СПРОЕКТИРОВАНА и имеет этот самый дизайн.
Вообще, POSIX конечно преподавать надо, но дополнительным материалом в качестве примера того, как не надо делать. Посвящать ему отдельный курс или заменять им курс «Операционные системы» — неприемлемо.