Kiddie labor

[kika]

http://kika.livejournal.com/32433.html?thread=188849#t188849

Вопрос простой - а где у нас в ЗАО РФ нынче учат на программистов? В смысле учат, а не "учат", то есть не читают лекции про эльбарроуз, а откуда выходят неплохие хакеры, способные аргументированно обсуждать стиль написания ядра Линукса и BSD. Ну или еще что-либо такое же высокодуховное и бесполезное.

Comments

[flhack.livejournal.com]

Если откуда-то вдруг повалят готовые хакеры, надо как минимум насторожиться :) Преподают, кстати, не только CS.

А по поводу проектов - http://swsoft.mipt.ru/projects.shtml

[pzz.livejournal.com]

Дарю идею студенческого проекта.

Представим себе линуксный лабтоп. У него есть 2 сетевые карты: Ethernet и какой-нибудь WiFi. Машинка ведет очень хаотическую сетевую жизнь: в любой момент ее могит подключить/отключить к Ethernet'у, или она может подключиться/отключиться к беспроводной сети.

Типичный линух ведет себя в такой ситуации довольно плохо. А именно:
1. в качестве DNS-сервера будет использоваться последний, о котором машинка узнала по DHCP. Если последний не работает, машинка останется без DNS'а (предудущий она уже потерла).
2. Если есть 2 равнозначных default route, то линукс будет упорно использовать какой-то один из них, даже если он не работает, и никогда не попробует другой. Такое бывает, например, если линукс зацепился за Access Point, не подключенный к Интернету (а через Ethernet выход наружу есть).

Соотсветственно, предлагается написать софтварий, который все это исправит. Софтварий должен включать в себя:
1. Следилку за состоянием сетевых интерфейсов - мне кажется, проще написать свою, чем интегрироваться с ifplugd (http://0pointer.de/lennart/projects/ifplugd/)
2. DHCP клиент, или интеграцию к существующему
3. DNS-мультиплексор, который узнает от DHCP клиента список возможных DNS-серверов, и пытается сам выбирать из них работающий(ие) методом проб и ошибок, с учетом состояния сетевых интерфейсов.
4. Интеграцию с wpa_supplicant'ом, для управления WiFi roaming'ом. Кстати, надо не забыть, что DHCP клиент должен запускаться после окончания WPA handshake, а не до (нотификация о том, что интерфейс зацепился за медию приходит до WPA handshake)
5. Управление линуксным фаирволом в более простом виде, чем iptables
6. Систему конфигурирования всего этого хозяйства
7. Управляющую гуевую морду.

Неочевидные вопросы:
1. Как понять, что дефолтовый роутинг ведет в никуда?
2. В отличии от Ethernet'а, настройки WiFi в принципе могут на многопользовательской машинке принадлежать пользователю, а не системе (например, пароль для доступа в сеть). Как аккуратно поделить сетевую карту между пользователями?

Гм...

[ifp5.livejournal.com]

На неочевидный вопрос номер 1 ответ один: никак. В качестве универсального fuck-up может служить, например, авторизация через captive portal, губящая идею мегапроекта на корню.

Re: Гм...

[pzz.livejournal.com]

Но винда-то с этим справляется более-менее. Чем мы-то хуже? :-)

Винда, насколько я понимаю 1) при автиконфигурации (DHCP и т.п.) никогда не расставляет одинаковые метрики на default routes через разные интерфейсы 2) если она чует, что с интерфейсом что-то не так, она может поменать метрику соответствующего роута.

Как именно она чует, не очень понятно. Вероятно, учитывает неудачи при попытке установить TCP соединение.

Re: Гм...

[ifp5.livejournal.com]

Но винда-то с этим справляется более-менее. Чем мы-то хуже? :-)

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

А вот, например, при наличии Ethernet (технолан с выходом в инет) и GPRS (другая технологическая сеть без выхода в инет) без всякой матстатистики лучшим выбирается дефолт через GPRS, наверное потому что скорость в нем на три-четыре порядке меньше. :>

Как именно она чует, не очень понятно. Вероятно, учитывает неудачи при попытке установить TCP соединение.

Так как раз в том и прикол, то в случае captive portal все tcp-соединения будут (если так настроить) успешно устанавливаться, но заворачиваться на этот портал, который будет пытаться сказать юзеру по различным протоколам (чаще всего ограничиваются http): авторизуйся, а то никуда не пущу. А этот captive portal может быть как раз из случайно подцепленой wifi сетки, где авторизоваться при всем желании не получится.

Re: Гм...

[pzz.livejournal.com]

Ну с порталом-то ничего не поделаешь. Тут просто надо дать пользователю кнопку, позволяющую сказать "не ходи туда". Но тем не менее, это достаточно экзотическая ситуация.

Re: Гм...

[ifp5.livejournal.com]

А почему, собственно, и не ходить? Может как раз и надо ходить, только вот автоматически для общего случая понять это невозможно. Из более банальных примеров приходит в голову вариант когда сеть доступна через http или socks proxy (а как мегасофтина узнает в общем случае адрес и протокол прокси? опять никак).

На мой взгляд, решение вопроса возможно только частичное, типа какой-нить перловый модуль, где в одну строчку можно проверить arp, интерфейсы, раутинг, доступность узла N по протоколу M и пр., чтобы юзер, зная, куда он ходит, критерии работоспособности каждой конкретной сети и пр., мог бы написать мегаскрипт, который уже делает то что задумано.

Но тем не менее, это достаточно экзотическая ситуация.

Смотря где. В университетских сетях, наверное, дико экзотическая, а вообще не такая уж и редкая, Cisco и многие другие подобные решения активно впаривают, особенно для беспроводных и мобильных сетей (у Cisco см. SSG, ISG, CMX; у Huawei тоже SSG и еще не помню что).

[pzz.livejournal.com]

И еще одна.

Есть програмка fuse (http://fuse.sourceforge.net/), позволяющая реализовать файловую систему в user space.

Предлагается написать аналог для реализации в user space сетевого протокола (т.е., address family).

Назвать можно suse :-) (от слова socket).

[rblaze.livejournal.com]

Ну вообще-то bpf и sysvipc уже написаны, этого достаточно для user-space протоколов, если не морочиться безопасностью.

[pzz.livejournal.com]

Я имею ввиду именно address family. Т.е., возможность создать свои тип сокетов, существующий параллельно с AF_INET, AF_UNIX, AF_INET6, ...

В винде аналогичные вещи делаются с помощью layered service provider: http://en.wikipedia.org/wiki/Layered_Service_Provider

Но конечно, хотелось бы получить не столь замороченную конструкцию.

[rblaze.livejournal.com]

Пишем shared library, перекрывающую работу с сокетами. Для "системных" AF она дергает стандартный API, для "своих" работает самостоятельно.

Прием-передача пакетов -- через bpf, разделение ресурсов (аналог портов TCP/UDP) через shared memory.

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

[pzz.livejournal.com]

Ты не путай, пожалуйста, 2 вещи:
1. Перекрытие сокетного API
2. Собственно реализация протокола

Давай для начала ограничимся IP-based (или даже UDP-based) протоколами. Тогда возню с BDF'ом можно отложить на потом. Да и вообще, как послать/принять сырой пакет более-менее понятно.

Что касается перекрытия сокетного API, да, конечно, это можно сделать, подсунув библиотеку, перекрывающую socket(), close(), send(), recv(), read(), write(), ...

Некоторые так и делают

Однако есть определенные сложности:
1. В такой архитектуре очень сложно сделать select(), позволяющий смешивать наши сокеты с настоящими. Микрософту это не удалось :-)
2. Ненастоящесть наших сокетов будет вылезать из других интересных мест. Например, если я запускаю из себя процесс, перенаправив его ввод/вывод в такой сокет, но в этот процесс наша библиотека не загружена, то это работать не будет. То же самое, если я передам такой сокет другому процессу через sendmsg()

Ну и в конце концов, псевдотерминалы и файловые системы тоже можно было бы сделать в shared library. Но однако так не делают, потому что аккуратно это сделать сложно и неудобно.

[rblaze.livejournal.com]

Ну тут цели разные, видимо. Если для упрощения разработки протоколов делать, то надо лезть в ядро, регистрировать там нужные AF и выводить все callback'и наружу через /dev какой-нибудь. Возникнут интересные вопросы про асинхронность вызовов и т.п., но всё это в принципе решается.

Я-то на другое ориентировался: снижение общих накладных расходов на endnode, честная дележка между процессами и другие серверно-важные вещи. Тут можно вынести вообще все протоколы из ядра, оставить лишь продвинутый BPF и выделение уникальных ресурсов. Последнее можно и в shared memory держать, но в ядре будет безопаснее.

Не сам придумал, конечно, отсюда большую часть стянул: http://pdos.csail.mit.edu/~engler/dpf.html

[msh.livejournal.com]

У netfilter есть же модуль такой, queue или что-то типа того, который ворует пакеты из цепи и отдает их в user space, а потом из user space получает и обратно вбрасывает

Но я точно не знаю что он может, я его смотрел только на предмет изучения внутренностей netfilter

[msh.livejournal.com]

.. а в user space мы энкапсулируем либо в UDP либо в TCP, смотря что за протокол у нас, и забрасываем обратно. Теперь мы его можем использовать из обычного сокета - recvmsg и вот наш пакетик или read и получаем наш стрим

[pzz.livejournal.com]

Сокет это вовсе не обязательно что-то, что генерирует в конечном итоге UDP или TCP пакеты.

Переформулирую задачу другими словами. Я хочу иметь возможность создать вызовом socket() объект, который выглядит как нормальный сокет. Т.е. позволяет делать над собой все те же операции, которые позволяет делать обычный сокет. В частности, может быть использован вместе с другими файловыми хендлами в select'е (poll'е), может быть передан как файловый хендл другому процессу, и позволяет использовать protocol-specific опции в setsockopt/getsockopt, и auxiliary data в sendmsg/recvmsg.

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

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

[msh.livejournal.com]

Сокет это что-то, что в конечном счете передает либо пакеты либо поток байтов между двумя эндпойнтами. Эмулировать настоящий сокет на линаксе трудно, а может даже и невозможно. Поэтому я предлагаю ничего не эмулировать, а отдавать программе нормальный UDP, скажем, сокет, через который она может принимать и посылать пакеты, ждать его в poll и все такое. Вот только общаться она будет через враппер, который будет протокольные адреса преобразовывать в фэйковые IP, а потом эти фэйковые IP говорить другому куску вареза. Этот кусок подучит ipt_QUEUE или как там его нынче зовут доставать пакеты этого протокола и UDP с и на эти фэйковые адреса, отдавать и то и другое в юзер спэйс, где имплементация протокола будет его процессить и энкапсулировать (или декапсулировать и процессить)

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

[rblaze.livejournal.com]

А зачем UDP? Уровень сокетов во всех ядрах инкапсулирован достаточно хорошо, туда несложно добавить свои записи для любых AF и отдавать их программе совершенно честно.
Другой вопрос, что в BSD, например, эти таблицы статические, но это не непреодолимое препятствие, всё можно изменить.

[msh.livejournal.com]

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

[pzz.livejournal.com]

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

Почему у нас не видно такой практики? Для студента должно быть очень приятно написать опенсорсную программу, вошедшую в дистрибутивы линукса. Я думаю, для становления молодого специалиста это гораздо полезнее, чем (анонимно!) написать какую-нибудь маленькую запчасть от какого-нибудь Parallels Desktop.

Что это, отсутствие у нас толковых студенческих работ, или желание компаний на корню подгрести всех вменяемых студентив под себя?

[flhack.livejournal.com]

Не пишет там никто запчасти к реальным проектам, это ыообше не реально. Почему результаты не публикуют - надо бы спросить.

[krotoff.livejournal.com]

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

[pzz.livejournal.com]

У меня сложилось впечатление, что какой-нибудь линуксячий GNOME наполовину написан студентами. Я не прав?

[krotoff.livejournal.com]

Про FSF я совсем забыл ;-)

А gnome по-моему вообще никто не спосирует = создается энтузиастами. (Возможно совсем не прав).

[pzz.livejournal.com]

Его по-моему Новелл спонсирует.