В состав ядра текущей экспериментальной ветки NetBSD, на базе которой формируется выпуск NetBSD 7, включен (http://mail-index.netbsd.org/source-changes/2013/10/16/msg04...) модуль с реализацией виртуальной машины Lua, добавляющий в ядро поддержку встраиваемого скриптового языка программирования, отличающегося эффективной работой с памятью, компактностью и высокой производительностью (применяется JIT-компиляция). Поддержка Lua в ядре позволит (https://archive.fosdem.org/2013/schedule/event/lua_in_the_ne...) разрабатывать динамически загружаемые расширения, изменяющие поведение существующих систем или создающие новые возможности.Использование расширений на языке Lua оправдано в ситуациях когда важна скорость создания готового решения и не требуется высокая производительность. Например, модуль будет полезен при необходимости быстро реализовать нужную функциональность, опробовать на практике запланированные к реализации идеи или подготовить скрипты для отладки подсистем ядра. В качестве примеров расширений упоминаются (http://netbsd-soc.sourceforge.net/projects/luakern/) скрипты для опробования разных алгоритмов работы планировщика задач, механизмов QoS, создание расширенных обработчиков сетевых пакетов и изощрённых сетевых фильтров, определение собственных правил управления энергопотреблением процессора, создание прототипов драйверов устройств.
<center><a href="https://archive.fosdem.org/2013/schedule/event/lua_in_the_ne... src="http://www.opennet.me/opennews/pics_base/0_1382123741.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Как и в случае запуска скриптов в пространстве пользователя, разработчик получает возможность запускать скрипт в пространстве ядра, оценивать результат его работы, быстро вносить изменения и повторно запускать скрипт, не тратя время на перекомпиляцию. Выполняемые в пространстве ядра скрипты не имеют прямого доступа к памяти ядра, изолированы в отдельной виртуальной машине Lua и взаимодействуют с подсистемами ядра через специальные биндинги. На стадии формирования байткода выполняется выявление и блокирование опасных конструкций, таких как бесконечное зацикливание.
Для запуска скриптов в пространстве ядра из окружения пользователя подготовлена специальная утилита luactl.
URL: https://news.ycombinator.com/item?id=6562611
Новость: http://www.opennet.me/opennews/art.shtml?num=38203
Я не вижу ни в этой новости, ни в оригинале: какую реализацию Lua они используют?
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/modul...
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/external/...Похоже что ваниллу.
Если это так, то в новости ошибка: ванильный Lua не поддерживает JIT.
> Если это так, то в новости ошибка: ванильный Lua не поддерживает JIT.Вы слишком шаблонно мыслите.
Людям, которые умеют встраивать интерпретатор в ядро ОС, ничто не мешает встроить JIT в интерпретатор, даже если его там отродясь раньше не было. А уж если есть образцы готовых реализаций, то тем более ничто не мешает.
Скорее всего взяли luajit с последней поддерживаемой реализацией lua там.
>Скорее всего взяли luajit с последней поддерживаемой реализацией lua там.Не возьмут они никогда luajit в ядро. Во-первых, он не поддерживает все архитектуры, на которых работает NetBSD, во-вторых, JIT-компиляция в ядре - это потенциальный источник огромных проблем со стабильностью и безопасностью
> JIT-компиляция в ядре - это потенциальный источник огромных проблем со стабильностью и безопасностьюА компиляция в байткод в ядре - это не источник проблем?
> А компиляция в байткод в ядре - это не источник проблем?При компиляции в байткод не происходит создание машинного кода, поэтому, даже зная адрес, в который этот байткод записывается, нельзя подсунуть туда машинный код (можно подсунуть другой байткод Lua, но обойти сэндбокс это не позволит). А с JIT можно попробовать, и ядро выполнит его, как будто это результат компиляции Lua.
Хотя я бы и компиляцию байткода делал в юзерспейсе, а в ядре оставил только интерпретатор байткода.
"На стадии формирования байткода выполняется выявление и блокирование опасных конструкций, таких как бесконечное зацикливание."
Мне одному показалось что открыта дорогая для новых бэкдоров уровня ядра без необходимости даже компиляции?
> Мне одному показалось что открыта дорогая для новых бэкдоров уровня ядра без необходимости даже компиляции?Ну правильно. Раньше бэкдоры в ядра ОС встраивали только АНБ и крутые хакеры, а теперь это доступно каждой блондинке. (Ну ладно, почти каждой)
Так поднимем же тост за лин^Wюникс с человеческим лицом!
Хорошо подмечено. Ибо еще мистер Тюринг доказал что силами одной программы невозможно определить завершится ли за конечное время другая произвольная программа или нет.Очень интересно, как они "выявляют" и "блокируют", если это невозможно даже чисто теоретически :).
> Очень интересно, как они "выявляют" и "блокируют"в исходники смотри
> в исходники смотриИ там будет опровержение выкладок Тюринга? Вот это как-то очень сомнительно.
Причем здесь опровержение Тюринга. Там не ставится задача "определить завершиться ли программа". Там ставится задача "заблокировать потенциально опасные инструкции", например цикл с условием, которое всегда истинно.
> Причем здесь опровержение Тюринга. Там не ставится задача "определить завершиться ли программа".
> Там ставится задача "заблокировать потенциально опасные инструкции", например цикл с условием,
> которое всегда истинно.Истинность можно сделать очень неочевидной.
for(;a>b;) { a = 0; a = rand(9000); a = b+1; }
Или цикл необязательно должен быть вечным, чтобы доставить проблем.
for(;a<100500;) { a = a + 1; sleep 1; }
Так что прорехи остаются.
Хорошо, что это только модуль ядра, который можно и не загружать.
> Так что прорехи остаются.прикинь, а модули на Си ВООБЩЕ НЕ ПРОВЕРЯЮТ ПЕРЕД ЗАГРУЗКОЙ! можешь паниковать.
> прикинь, а модули на Си ВООБЩЕ НЕ ПРОВЕРЯЮТ ПЕРЕД ЗАГРУЗКОЙ!Кто тебе сказал такую глупость? Там цифровые подписи можно юзать нынче. И даже два режима на выбор - совсем не грузить левак или загрузить но пометить ядро как tainted. Кроме того, их обычно пишут только ядерщики а не кто попало.
>> прикинь, а модули на Си ВООБЩЕ НЕ ПРОВЕРЯЮТ ПЕРЕД ЗАГРУЗКОЙ!
> Кто тебе сказал такую глупость? Там цифровые подписи можно юзать нынче. И
> даже два режима на выбор — совсем не грузить левак или
> загрузить но пометить ядро как tainted. Кроме того, их обычно пишут
> только ядерщики а не кто попало.ой, я всё проспал, цифровая подпись теперь — гарантия от ошибок и бесконечных циклов? круто!
> ой, я всё проспал, цифровая подпись теперь — гарантия от ошибок и
> бесконечных циклов? круто!Нет, но это какаая-никакая проверка что ядерный код - именно тот который должен быть, без довеков и изменений. А вот это для продакшновых систем хорошо. Лишняя колдобина на пути хаксоров и их бэкдоров. А вот фичи типа сабжа позволят таким господам тихой сапой отпедалить какие-то операции в ядре совершенно не очевидным админу образом. Да еще включить это по дефолту "а кому не нравится - может купить миноискатель и убрать наши мины" - прикольная логика :).
(умиляется) ты крепко выпил вчера, что ли?
Еще бы - он NetBSD в продакшне видит. Это покруче зеленых чертей...
> (умиляется) ты крепко выпил вчера, что ли?Ну ты тогда вообще с иглы не слазила.
Ибо на полном серьёзе бесконечные циклы собрался блочить.
Если бы ты не была домохозяйкой наверное бы знала насколько часто юзаютwhile TRUE { ....
Лучше про борщ рассуждай.
> ой, я всё проспал, цифровая подпись теперь — гарантия от ошибок и бесконечных циклов? круто!Это всего лишь способ поставить палки в колеса юному Васе, который при помощи метасплойта ломанул продакшен и теперь хочет закрепить результат.
А вот подгрузка Lua-скриптов в ядро в рантайме - это наоборот, Васе зеленая улица.
я тебе сейчас Очень Страшный Секрет открою: если уж у меня есть рутовый доступ, то все твои «подписи» мне до фонаря. вообще.
Так и скажи, что про Secure Boot не слышал.
> Так и скажи, что про Secure Boot не слышал.ну, если ты, получив рутовый доступ, первым делом перезагружаешь систему (а потом опять; и опять) — это твои личные проблемы.
равно как то, что ты пытаешься надувать щёки на тему, в которой ничего не понимаешь.
всё, abtreten!
> я тебе сейчас Очень Страшный Секрет открою: если уж у меня есть
> рутовый доступ, то все твои «подписи» мне до фонаря. вообще.А вот это уже как повезет.
1) Все права доступа энфорсятся кернелом. Рут - понятие относительное. Не захочет кернел выполнять твою запись в вон тот файл - и пойдешь ты лесом. А хотя-бы и с UID=0. А какая, собственно, разница кого завернуть? Исторически так было что UID=0 можно все. Но это в общем то на усмотрение кернела на самом деле.
2) Автоматические трояны и малоквалифицированные Пупкины с стандартными руткитами таки могут обломаться.
3) Кроме того можно не обламывать такую активность а лишь метить кернел как tainted, вывешивая админу флаг что возникли проблемы. Под это даже отдельный режим есть. Понятно что в теории имея доступ в кернелмод, флаги taint можно и почистить, но это уже кастомно и граблеопасно.
>> Так что прорехи остаются.
> прикинь, а модули на Си ВООБЩЕ НЕ ПРОВЕРЯЮТ ПЕРЕД ЗАГРУЗКОЙ! можешь паниковать.Я вот не понимаю, вам лишь бы ляпнуть чтоли?
>>> Так что прорехи остаются.
>> прикинь, а модули на Си ВООБЩЕ НЕ ПРОВЕРЯЮТ ПЕРЕД ЗАГРУЗКОЙ! можешь паниковать.
> Я вот не понимаю, вам лишь бы ляпнуть чтоли?вперёд, показывай, что это всегда не так. люблю, когда дураки публично и добровольно выставляют себя дураками. это как в цирке, только животных жаль, а дураков — нет.
> Там ставится задача "заблокировать потенциально опасные инструкции",Ну так я и говорю: ставится задача сделать невозможное. Невозможность этого деяния доказана Тюрингом. Wtf?!
Тьюринг нут ни при чём. Можно просто следить за ходом работы скрипта и прибивать его в случае необходимости, как потенциально зависший. При этом не пострадает ни один процесс, никакая память не затрётся.
> Тьюринг нут ни при чём. Можно просто следить за ходом работы скрипта
> и прибивать его в случае необходимости, как потенциально зависший. При этом
> не пострадает ни один процесс, никакая память не затрётся.разве что устройство раком встанет, но это ж фигня.
> разве что устройство раком встанет, но это ж фигня.Скучает народ по красивым BSOD'ам :)
> Скучает народ по красивым BSOD'ам :)Спасибо если бсодам, а не однострочникам на Lua которые вкатывают команду CHIP ERASE микросхеме с BIOS на мамке :).
>> Скучает народ по красивым BSOD'ам :)
> Спасибо если бсодам, а не однострочникам на Lua которые вкатывают команду CHIP
> ERASE микросхеме с BIOS на мамке :).да, на си такое никак написать нельзя. ну совсем.
кто ж человеку виноват, если он загружает ядерные модули не приходя в сознание?
> да, на си такое никак написать нельзя. ну совсем.Можно. Но зачем создавать не слишком очевидную, но достаточно деструктивную лазейку - малопонятно. А попытки мимикрировать под ветошь "ой, мы тут, типа, проверяем" (ага, опровергнув Тюринга) - вообще непонятно нафига.
С чего это? Из-за прибитого скрипта устройство должно встать.
> С чего это? Из-за прибитого скрипта устройство должно встать.с таким же успехом может войти в состояние «не подходи ко мне больше никогда!» мало ли, что за устройство, в каком важном месте угрохали скрипт и так далее. а рассматривать лучше случай похуже (в разумных пределах).
> Тьюринг нут ни при чём.Не понял, а блокирование "потенциально проблемных" инструкций - это что?
> Можно просто следить за ходом работы скрипта
> и прибивать его в случае необходимости, как потенциально зависший.ИМХО в юзермоде такие развлечения смотрятся безопаснее.
> При этом не пострадает ни один процесс, никакая память не затрётся.
Это в кернеле то? Я что-то не понимаю:
- Если оно не будет иметь возможность дергать функции ядра и работать с железом, накукуй это в кернеле тогда?
- А если будет - тут систему положить можно в 2 счета. На то оно и кернелмод, что там можно все.
> Не понял, а блокирование "потенциально проблемных" инструкций - это что?Ну как - если сегодня пятница блокируется всЁ, если курбан какой айт - то все операции +, ++ и т.д., если 14 июня на всех адресах по call ставится ret ну и т.д.
> На то оно и кернелмод, что там можно все.
Они жту фразу тоже читали, только видишь ли ... поняли по-своему. :)
> на всех адресах по call ставится ret ну и т.д.Ну так то да - хакиры, конечно, задолбаются. Но почему-то мне кажется что не только хакиры.
> Они жту фразу тоже читали, только видишь ли ... поняли по-своему. :)
А, вот оно что!
>> Тьюринг нут ни при чём.
>Не понял, а блокирование "потенциально проблемных" инструкций - это что?Это именно что "блокирование "потенциально проблемных" инструкций" на уровне виртуальной lua-машины. Где в этом месте тебе привиделся Тьюринг? Он что-то писал про "потенциально проблемных" инструкции? Про кернел- и юзермод?
>> При этом не пострадает ни один процесс, никакая память не затрётся.
>Это в кернеле то? Я что-то не понимаю:
>- Если оно не будет иметь возможность дергать функции ядра и работать с железом, накукуй это в кернеле тогда?
>- А если будет - тут систему положить можно в 2 счета. На то оно и кернелмод, что там можно все.Тут говорится о безопасности самого языка, возможности затереть память, вылезти за дозволенные ему границы - только его личная виртуальная песочница. Если что-то покажется не так - прибивают виртуальную машину. Откуда в этом случае могут возникнуть разнообразные бсоды мне не понятно.
Ты же говоришь совсем о другом: о том какие системные вызовы могут производиться из скриптов. Это проблема уже другого порядка, она была и есть не только в скриптах, её решать и не пытались. Это понятно?
> Это именно что "блокирование "потенциально проблемных" инструкций" на уровне виртуальной
> lua-машины. Где в этом месте тебе привиделся Тьюринг? Он что-то писал
> про "потенциально проблемных" инструкции? Про кернел- и юзермод?Он задвинул гораздо более могучую теорию - насчет того что одна программа не сможет полностью проанализировать другую произвольную программу и вынести определенный вердикт. В свете этого не понятно как можно позволить делать что-то полезное и потом не скушать последствия этого.
Ну если у вас есть рут на атакуемой системе - то пожалуйста, добавляйте.
Скрипты в режиме ядра???
> Скрипты в режиме ядра???HTML5 было лениво прикручивать. Решили по-быстрому слабать.
PS: Так-то забавно на самом деле. Если хуки на ядреный API будут достаточно развесистыми, то для прототайпинга - почему нет? Главное - это вовремя остановиться.
> Главное - это вовремя остановиться.С этим у прогеров обычно всегда проблема. Особенно при отсутствии дедлайнов и контроля проект-менеджера.
Так что не исключено, что лет через десять ядро NetBSD будет примерно наполовину состоять из Lua :)
> Так что не исключено, что лет через десять ядро NetBSD будет примерно наполовину состоять из Lua :)А вот когда оно будет состоять из Lua _полностью_ - адепты истинного юниксвея наконец-то смогут сказать своему главному противнику: "Шах и мат, Поттеринг!"
> А вот когда оно будет состоять из Lua _полностью_ - адепты истинного
> юниксвея наконец-то смогут сказать своему главному противнику: "Шах и мат, Поттеринг!"Останется всего ничего - заставить адептов юниксвэя потом сгрызть этот кактус и не подавиться.
>> А вот когда оно будет состоять из Lua _полностью_ - адепты истинного
>> юниксвея наконец-то смогут сказать своему главному противнику: "Шах и мат, Поттеринг!"
> Останется всего ничего - заставить адептов юниксвэя потом сгрызть этот кактус и
> не подавиться.Да нууу - щах ропцеринг тут эту новость прочтёт ... и в понедельник впилит эту ботву в системд :) (А так как он упоро^h ный и глюпый - то видимо впилит вместе с ядром нетки :)
не впилит. он дотянет свой системды до того, что там получится мегакорявый, меганеудобный и меганеочевидный язык, который после тщательного окостыливания будет turing-complete. зато никакого мерзкого sh!
> не впилит. он дотянет свой системды до того, что там получится мегакорявый,
> меганеудобный и меганеочевидный язык, который после тщательного окостыливания будет turing-complete.Неа. В ответ на предложение добавить циклы он послал лесом, быстро и решительно. Со словами "хотите ЯП - пишите что хотите на своем любимом языке, и вызывайте через ExecStart".
В конце концов, у него перед глазами уже есть пример мегакорявого, меганеудобного и меганеочевидного языка, который после тщательного окостыливания стал turing-complete - sh.
> Неа. В ответ на предложение добавить циклы он послал лесом, быстро и
> решительно. Со словами "хотите ЯП - пишите что хотите на своем
> любимом языке, и вызывайте через ExecStart".Ах да, разработчики upstart в своей презентации "Upstart Roadmap" на LPC 2013, кроме намерения сделать свой крон и поддержку cgroups (типа "у нас все будет как в системдэ, только еще больше!"), обещали впилить с свои конфиги while.
> Неа. В ответ на предложение добавить циклы он послал лесом, быстро и решительно.это всего лишь значит, что он пока занят запиливанием ftp-сервера, irc-cервера и адаптированием icecast. а как всё это добавит — так и…
> это всего лишь значит, что он пока занят запиливанием ftp-сервера, irc-cервера и
> адаптированием icecast. а как всё это добавит — так и…Не угадал. В новом systemd 209 будет свой прокси-сервер.
> Не угадал. В новом systemd 209 будет свой прокси-сервер.Кстати, от SNMP-сервера (точнее, агента), встроенного в инит, как в солярке, я бы не отказался. Очень удобная штука.
>> это всего лишь значит, что он пока занят запиливанием ftp-сервера, irc-cервера и
>> адаптированием icecast. а как всё это добавит — так и…
> Не угадал. В новом systemd 209 будет свой прокси-сервер.я не понял: icacast и irc не ждать, что ли? тьфу. бесполезная чушка этот системды.
> я не понял: icacast и irc не ждать, что ли? тьфу. бесполезная чушка этот системды.Не парься, сделай свой init с LAMP-стеком.
> я не понял: icacast и irc не ждать, что ли? тьфу.Не стоит отчаиваться раньше времени! Когда-нибудь обязательно будет!
> Не угадал. В новом systemd 209 будет свой прокси-сервер.А он будет уметь Tor? :)
Он им в ответ в systemd запихнет поддержку brainfuck
> Он им в ответ в systemd запихнет поддержку brainfuckbrainfuck там уже есть. системды — это изначально один большой brainfuck.
> Скрипты в режиме ядра???Да это самый что ни на есть юниксвей! Просто, прозрачно, доступно, легко отлаживать.
Не то, что линуксовые блобы.
> Не то, что линуксовые блобы.Ждем когда вы перепишете все ядро на Lua. И BIOS заодно. Правда тут мы на#$немся на необходимость в проце который бы напрямую выполнял Lua, но это уже мелочи...
Ну, Лисп-, Форт- и Java-процессоры уже были, теперь вот настал черёд и Lua-процессоров. Благо там регистровая ВМ.
> Ну, Лисп-, Форт- и Java-процессоры уже были, теперь...теперь будет еще одна очень всем необходимая академическая фигня? :)
>> Ну, Лисп-, Форт- и Java-процессоры уже были, теперь
> ...теперь будет еще одна очень всем необходимая академическая фигня? :)На Форте писан OBP в SPARC, да будет тебе известно. 25 лет в продакшенах.
> На Форте писан OBP в SPARC, да будет тебе известно. 25 лет в продакшенах.Да и флаг ему в руки. Кушайте, смотрите не обляпайтесь.
О-па как раз хотел на NetBSD что-то на Lus сваять! Какая радость.
Отличная идея!
у меня дежавю - я читал об этом несколько месяцев назад. даже на лоре была тема.
Да еще зимой повсюду мусолилось. Тогда был просто патчик выкачен на обозрение, а нонче М. Балмер комитнул в дерево проекта. Но народ в мейл-листе щас взбесновался, говорит зачем оно нам - или покажи, что оно реально нужно или выпиливай нафиг.
> М. БалмерКлассная у чувака фамилия.
> Классная у чувака фамилия.Злобный брат-близнец Стива Балмера.
> мейл-листе щас взбесновался, говорит зачем оно нам - или покажи, что
> оно реально нужно или выпиливай нафиг.Потому что редкостный @на@низм на самом деле. Вылавливают они, блин, конструкции с зависаниями. А Тюринг, который доказал что это невозможно - лох педальный, получается?
> Потому что редкостный @на@низм на самом деле. Вылавливают они, блин, конструкции с
> зависаниями. А Тюринг, который доказал что это невозможно — лох педальный,
> получается?а ты-то чего бесишься? нигде не сказано, что детект 100%. более того: это опеннет, так что вполне возможно, что в оригинале вообще всё совершенно о другом написано.
Анонимус читать тюринга первый курса
Анонимус не учить английский
Анонимус трахать всех свой краткий знание теориякак-то так
> а ты-то чего бесишься? нигде не сказано, что детект 100%.Потому что люди страдают фигней да еще заведомо нерабочие костыли прикручивают, чтобы не так паливно было. И выдают сие за "фичу".
Ну я еще понимаю зачем аверы всякие с эвристикой так поступают: у них там бабло побеждает зло. Это не сильно приятная, но по крайней мере понятная логика. А вот зачем втирать очки окружающим относительно свойств софта в открытых проектах и делать весьма декоративные костыли, которые работать и делать то что заявлено заведомо не смогут - вот это мне не совсем понятно уже.
> Но народ в мейл-листе щас взбесновался, говорит зачем оно нам - или покажи, что
> оно реально нужно или выпиливай нафиг.это вместо systemd, ничего привыкнут
> это вместо systemd, ничего привыкнутДа, на NetBSD он не работает.
Ждем, что предложат во FreeBSD.
Так уже выкатили идею, добавить Lua и в ядро FreeBSD, systemd там не будет
> Так уже выкатили идею, добавить Lua и в ядро FreeBSD, systemd там не будетНадо добавить в ядро фри Lua, и реализовать на нем systemd. Вот это будет юниксвейно!
Да, на 1е апреля упоминалось. Типа, разработчики OpenBSD, видя направление работ разработчиков NetBSD, решили встроить в ядро реализацию http://ru.wikipedia.org/wiki/LOLCODE
> у меня дежавю - я читал об этом несколько месяцев назад. даже на лоре была тема.Код был написан ещё в 2010 году. Каждый год на FOSDEM представители NetBSD выступают с докладом с рассказом об этом проекте, и каждый год после этого ресурс phoronix пишет, что теперь уж точно в ядро NetBSD 7 добавят Lua, а кучу разных сайтов копипастят эти домыслы и иногда желаемое принимают за действительное.
На этот раз коммит с модулем Lua действительно добавили в состав ядра. Но только некоторые разработчики взбунтовались и требуют откатить изменение.
какой херни только не сделаешь в условиях нехватки рабочих рук
> какой херни только не сделаешь в условиях нехватки рабочих рукПосле установки NetBSD на кофеварку (с которой, правда, пришлось сначала стереть прошитый на заводе линукс) такие приятные мелочи уже не удивляют :)
Пля, там был тостер! Тостер!
> Пля, там был тостер! Тостер!Какая разница, к чему на саморезах плату прикрутить? Я могу даже к тумбочке.
> тумбочке.Вам смешно, а холодильник с андроидом уже сделали...
смешно это роутер на андроидеи телефон на html5/js
Это уже не смешно, на самом деле - по факту это результат того, что адекватные времени интерфейсы породить не успели, и нишу занял гугл с совершенно безумными решениями. А мозиллы всякие - это уже следом.
даешь поддержку basic'a!! =))))
Мы всё ещё не хотим микроядро. :-)
> Мы всё ещё не хотим микроядро. :-)Вам что, микроядер мало? Берите и пользуйтесь, если оно вам надо. Сдается мне что они посоревнуются с нетбздой "у кого меньше пользователей" :).
А по-моему круто
Чем бы дитя не тешилось.
... лишь бы не явой:\
> ... лишь бы не явой:\...лишь бы бабок не просило.
Так вроде давно уже?
В общем-то, это продолжение направления, взятого PUFFS и RUMP. Размывание границ между ядерным кодом и кодом в пространстве пользователя. Если Lua будет поддерживаться ядром в виде подгружаемого модуля, то всё нормально. Кому не нравится - сможет просто выгрузить его (или не загружать).
> в виде подгружаемого модуляТолько так и планируется.
> Кому не нравится - сможет просто выгрузить его (или не загружать).
Разраб модуля так и сказал, но массы против - уберите свой хлам, нам оно, дескать, не нужно. А вы, два с половиной пользователя-разработчика можете и вне основного дерева со своим модулем играться.
Соус:
http://marc.info/?t=138108977300002&r=1&w=2
http://marc.info/?t=138202733100004&r=1&w=2
> В общем-то, это продолжение направления, взятого PUFFS и RUMP. Размывание границ между
> ядерным кодом и кодом в пространстве пользователя.А это зачем? Чтобы поиметь массу неочевидных но эффективных методов нагибания системы пользователем? Разделение на кернел и юзер придумано не для красоты. Ядро кроме всего прочего занимается дележом ресурсов, арбитрированием доступа и энфорсингом прав доступа. И вот что-что а юзермод и юзерей от этого всего надо держать на пушечный выстрел. По соображениям секурити системы и стабильности.
> прав доступа. И вот что-что а юзермод и юзерей от этого
> всего надо держать на пушечный выстрел. По соображениям секурити системы и
> стабильности.по соображениям стабильности и секурности как раз максимум фигни и надо выносить из ядра. чтобы один кривой модуль не поставил раком всю систему.
> по соображениям стабильности и секурности как раз максимум фигни и надо выносить
> из ядра. чтобы один кривой модуль не поставил раком всю систему.Ну а вот тут не только засунули добавочной фигни, но еще и скрипты смогут зачем-то в ядерных сущностях копаться.
А так - до некоторой степени ты прав. Ну вот например если мне скорость не критична то я могу в usb девайсу прицепиться через libusb, избежав нужды программить ядерный модуль. Но это все-таки нишевые конструкции, скорость работы которых не особо критична, etc.
> Ну а вот тут не только засунули добавочной фигни, но еще и
> скрипты смогут зачем-то в ядерных сущностях копаться.не вижу принципиальной разницы между сишным модулем и «скриптовым» модулем.
> Но это все-таки нишевые конструкции, скорость работы которых не особо критична, etc.
почти все, на самом деле: процессоры сейчас быстрые.
> не вижу принципиальной разницы между сишным модулем и «скриптовым» модулем.Уточним: я не понимаю накулкуа это должно быть ядерным модулем.
> почти все, на самом деле: процессоры сейчас быстрые.
Это не значит что их тормознуть нельзя. Интерфейсы тоже быстрые нынче. А дурная работа с оными может все посадить и вызвать конский жрац проца на раз-два-три. А чтобы отпрототипировать нечто - а чем юзермод для этого был плох? Прототипировать драйвера на Lua - мсье знают толк...
>> не вижу принципиальной разницы между сишным модулем и «скриптовым» модулем.
> Уточним: я не понимаю накулкуа это должно быть ядерным модулем.потому что иначе несколько сложно получить доступ к ядерному API. твой Кэп.
> Это не значит что их тормознуть нельзя.
можно. но зачем? имею сказать, что QNX, будучи микроядерной, была вполне себе RTOS. руки просто надо в верное место монтировать.
> Прототипировать драйвера на Lua — мсье знают толк…
а эти ребята, наверное, ещё хуже, да? http://www.eluaproject.net/
> потому что иначе несколько сложно получить доступ к ядерному API. твой Кэп.Нафига козе баян? Заявы про прототипирование драйверов на луа ... ну, впрочем, это бсдшники. Чтоб они дрова на Lua юзали, для них самое оно.
> можно. но зачем? имею сказать, что QNX, будучи микроядерной, была вполне себе
> RTOS. руки просто надо в верное место монтировать.Реалтаймность ничего не говорит о скорости работы. Она о времени реакции на событие и гарантиях на этот счет. А какая там скорость выполнения в целом - отдельный вопрос.
Например 1-задачная фирмварина в 10МГц атмелке, коммутирующая в реальном времени обмотки мотора и срубающая за 1-2 цикла коммутации мотор если ток возврос (==препятствие или хомячок сунул лапку в пропеллер, etc) - вполне приличный по требованиям реалтайм, где совсем нельзя продалбываться: реалтаймный физический процесс не может ждать. Но какая общая производительность у 8-битника на 10 МГц? А поди ж ты, реалтайм, круче только яйца, QNXу до такого счастья как оперирование юнитами типа N*100 наносекунд - как пешком до пекина на х86 будет.
>> Прототипировать драйвера на Lua — мсье знают толк…
> а эти ребята, наверное, ещё хуже, да? http://www.eluaproject.net/Абсолютно. Ну то-есть каждый др^W по своему. Но почему-то все виденные мной фирмвари микроконтроллеров по жизни были написаны без всяких Lua. На сях, а иной раз и на асме. На асме проще "крутой" реалтайм делать (с потактовой разблюдовкой). На сях - забодаешься листинги читать. Но на асме геморнее все остальное и 100% хана портабельности. Единственное место где мне луа попадался в эмбедовке - вебморда openwrt. Ок, там он даже разумно смотрится. Наверное бывает и что-то еще. Но мне не попадалось за столько лет. Узкоспециализированная нишевая хрень.
>> можно. но зачем? имею сказать, что QNX, будучи микроядерной, была вполне себе
>> RTOS. руки просто надо в верное место монтировать.
> Реалтаймность ничего не говорит о скорости работы. Она о времени реакции на
> событие и гарантиях на этот счет. А какая там скорость выполнения
> в целом — отдельный вопрос.сильно подозреваю, что «управлятор» атомной станцией вряд ли будет хорошо работать при гарантированом времени реакции «не больше часа».
> Например 1-задачная фирмварина в 10МГц атмелке
похмелись. а то ты нить разговора теряешь.
>> а эти ребята, наверное, ещё хуже, да? http://www.eluaproject.net/
> Абсолютно.(вздыхает) и что ж они тебя-то не спросили перед тем, как делать…
> фирмвари микроконтроллеров по жизни были написаны без всяких Lua
а ядра ОС вообще когда-то на ассемблере фигачили. да-да, я знаю: что было хорошо для наших дедов и отцов, завсегда хорошо и для нас, а всё новое — зло.
> сильно подозреваю, что «управлятор» атомной станцией вряд ли будет хорошо работать
> при гарантированом времени реакции «не больше часа».Ну так я тебе привел пример как 10МГц проц оперирует юнитами по 100 наносекунд (такт у него столько занимает, все команды занимают 1 или несколько тактов, растактовка известна поштучно если это становится надо).
>> Например 1-задачная фирмварина в 10МГц атмелке
> похмелись. а то ты нить разговора теряешь.Вполне себе пример убер-реалтаймной фигни в софте. С жесткими требованиями к времени реакции и ... и на дохлом как комар процике (а только такие и предсказуемы с точностью до единиц тактов, кстати).
Более того - некоторые tradeoff'ы явно меняют предсказуемость времени на скорость выполнения. Всякие там кэши, конвееры, предсказания ветвлений и прочая - могут нехило ускорить выполнение кода и ... и сделать время реакции гораздо менее предсказуемой величиной. Если так - то столько, а если эдак - в 10 раз меньше. Jitter улетает в небеса.
> (вздыхает) и что ж они тебя-то не спросили перед тем, как делать…
Да мало ли кто и чего на этой планете делает. Чудаков много.
> было хорошо для наших дедов и отцов, завсегда хорошо и для
> нас, а всё новое — зло.Смотря что. Если нечто выглядит как раздача обезьянам гранат - я лучше отойду в сторонку, извини.
ещё раз настоятельно прошу тебя похмелиться.никак тебя понять не могу: иногда ты нормально пишешь, а иногда такую хрень не по теме несёшь, что у меня даже мат в ответ не получается.
> никак тебя понять не могу: иногда ты нормально пишешь, а иногда такую хрень не по теме несёшь, что у меня даже мат в ответ не получается.даю подсказку: под именем Аноним пишут разные люди.
>> никак тебя понять не могу: иногда ты нормально пишешь, а иногда такую хрень не по теме несёшь, что у меня даже мат в ответ не получается.
> даю подсказку: под именем Аноним пишут разные люди.А вот ты предсказуем, как башмак.
>> никак тебя понять не могу: иногда ты нормально пишешь, а иногда такую хрень не по теме несёшь, что у меня даже мат в ответ не получается.
> даю подсказку: под именем Аноним пишут разные люди.даю намёк: я, видимо, знал, к какому конкретному анониму обращался, когда это писал.
> имею сказать, что QNX, будучи микроядерной, была вполне себе RTOS. руки просто надо в верное место монтировать.Почему это была? Она и сейчас RTOS.
>> имею сказать, что QNX, будучи микроядерной, была вполне себе RTOS. руки просто надо в верное место монтировать.
> Почему это была? Она и сейчас RTOS.потому что с тех пор, когда я на неё смотрел, прошло довольно много времени. про её теперешнее состояние я не в курсе. а про что я не в курсе — про то я стараюсь не писать.
>потому что иначе несколько сложно получить доступ к ядерному API. твой Кэп.В NetBSD не так уж и сложно, видимо, т.к. там есть уже упомянутый RUMP, позволяющий писать драйверы устройств, работающие в режиме пользователя.
> выполняется выявление и блокирование опасных конструкций, таких как бесконечное зацикливаниеАй, молодцы ребята! Проблему остановки решили!
> Ай, молодцы ребята! Проблему остановки решили!Говорю же - Тюринг лох.
скажите привет новым видам сплоитов и прочим видам аттак
опыт жавы с ее выходами из песочницы никого не учит видимо
> опыт жавы с ее выходами из песочницы никого не учит видимоА тут сразу в кернел. Удобно, гули.
ждем от тебя сплоитов спацалист, иди и пиши бегом, нам тестеров не хватает
Почему именно Lua??? Там пишут про обоснование выбора языка? Почему не педон? Не жаба? Не жабоскрепт? А то и вовсе просто некоего байт-кода, без привязки к языку?
> Почему именно Lua??? Там пишут про обоснование выбора языка? Почему не педон?
> Не жаба? Не жабоскрепт? А то и вовсе просто некоего байт-кода,
> без привязки к языку?потому что Lua шустрая, маленькая, удобная и имеет отличный jit-компилятор.
> потому что Lua шустрая, маленькая, удобная и имеет отличный jit-компилятор.Вот только накулкуа все это в кернеле? :)
>> потому что Lua шустрая, маленькая, удобная и имеет отличный jit-компилятор.
> Вот только накулкуа все это в кернеле? :)вот чем мешает, а? ну, есть себе. не нравится — не используй, кто-то заставляет, что ли?
> вот чем мешает, а?На первый взгляд смотрится как мина замедленного действия. Чтобы писать драйвера - надо иметь доступ к работе с оборудованием. И это активировано по дефолту, насколько я понял. Далеко не самый очевидный для админа вектор поимения системы, на уровне при котором выпилить BIOS из флехи или там чего еще интересного - как два байта переслать, не говоря уж о рут- и буткитах.
> ну, есть себе. не нравится — не используй,
> кто-то заставляет, что ли?Так я и не собираюсь, тьфу-тьфу. В моем понимании - чем меньше хапаешь кернелмод на работающей машине - тем лучше здоровье (и системы и юзера). Кернелмод довольно деликатная хрень, малейшая лажа ведет к невкусным последствиям. Иногда - достаточно деструктивным. По поводу чего данная инициатива смахивает на массовую раздачу обезьянам гранат :).
> По поводу чего данная инициатива смахивает
> на массовую раздачу обезьянам гранат :).да-да. надо вообще ядерные модули запретить. и какие бы то ни было изменения в ядре вообще. а то мало ли…
можно, я дам тебе маленький совет? не загружай ядерные модули, будучи в бессознательном состоянии. очень помогает от всякой злой ерунды. потому что язык написания модуля никак не гарантирует того, что этот модуль тебе не нагадит.
Ну а нафига в кернел тогда суют BPF? Может всё-таки Lua получше этого велосипеда будет? Поуниверсальнее как-то.
Луа в скомпилированном виде, вместе с виртуальной машиной, компилятором и базовыми библиотеками занимает ~200К. Не знаю, какой бидон или жабаскрипт на такое способны. А байткод у него и собственный есть.А вот зачем его понадобилось прикручивать к ядру - другой вопрос :)
> быстро вносить изменения и повторно запускать скрипт, не тратя время на перекомпиляцию.Вообще-то "тратить время на перекомпиляцию" таки придётся - Луа сначала компилирует исходник в байткод и только затем выполняет его :)
Сборка NetBSD с Awesome в качестве wm и с подготовленной средой для работы с love2d… В этом определённо что-то есть.
