Comments 45
От Матфея 7:3
Мне кажется проще написать с нуля чем переписывать то что есть. Чисто психологически - в первом случае ты создаешь что-то новое, во втором - исправляшь старое багованое.
Только мне не понятно одно. Думаю что написание ОС будет сопровождаться так или иначе большим количеством unsafe раст кода. И в нем могут быть те же проблемы. Ну вектор атаки думаю всеравно меньше
Ну и что делать с огромным количеством написанного кода в виде приложений и утилит и сервисов. Голое ядро это конечно хорошо, но оно не крутится в вакууме
Unsafe код в Rust можно и нужно изолировать. А на C unsafe по-сути в каждой функции :)
Да и написание кода с нуля не гарантирует, что он будет без ошибок безопасности. Ведь вектора атаки не ограничиваются выходами за пределы массива и т.д. от чего обещает защитить Rust.
Да как бы никто и не против, пусть Google берет и переписывает, вот только похоже они хотят решать свои проблемы за чужой счет.
Они пишут свое ядро для Фуксии.
Только раста в Zircon'е нет, он написан на C++, и, ЕМНИП, использование раста (именно в Zircon'е) явно запрещено. С такими заходами рассуждения Кука "как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост завести раст в ядре Linux" (как минимум, в его текущем виде) выглядит, мягко говоря, неоднозначно.
И даже размер линуксового ядра крошечный по сравнению с какими-нибудь обвязками.
Те же кеды — десятки миллионов строк кода на плюсах, забагованные до нельзя.
Драйвера тоже бОльшая часть кода. Само ядро можно было сделать безопасным из-за малых размеров пусть и не безопасном языке, а поверх уже можно строить безопасные структуры.
Тем не менее, раст не рискуют использовать даже в таком небольшом ядре. Вообще мне все это напоминает известный армейский анекдот советских времен: чем отличается командир от комиссара? Командир говорит: "делай как я", а комиссар - "делай как я говорю". А забагованное говно пишется на любом языке на счёт раз.
не рискуют использовать даже в таком небольшом ядре
В 2016 расту был 1 год с первого релиза. Можно предположить, что зародилась она еще раньше, так что претензия не уместна.
А забагованное говно пишется на любом языке на счёт раз.
Да, только мы уже получили обширную статистику за эти годы.
И майки с гуглами и прочими фейсбуками свои выводы опубликовали.
Говорят ~70% косяков можно избежать, если использовать один язык вместо другого.
В 2016 расту был 1 год с первого релиза.
Сейчас вторая половина 2021, но стремления допустить раст в Zircon как в 2016 не было, так и до сих пор не наблюдается. Почему бы Куку не применить свои таланты сперва на домашнем поприще? А одни умозрительные советы в стиле "как нам обустроить Россию Linux" недорого стоят. Действительно, все это весьма смахивает на приглашение Линусу "пройтись по граблям" первым (под благовидными предлогами, разумеется - которыми вымощен путь известно куда). А Google посмотрит, что из этого выйдет.
Говорят ~70% косяков можно избежать, если использовать один язык вместо другого.
Говорить - не мешки ворочать.
Мне кажется проще написать с нуля чем переписывать то что есть.Чисто психологически - в первом случае ты создаешь что-то новое, во втором - исправляшь старое багованое.
Переписывать — это все хотят. Google тоже отметился. Только не работает.
Ядро — это не только тысячи багов, но и тысячи, десятки тысяч, человеко-лет опыта, в том числе получеамого только на весьма экзотическом железе, кодифицированного в программе на C.
Воспроизвести это фактически невозможно. Недаром Microsoft в WSL2 отказался от идеи эмулировать Linux и взял готовое ядро.
Думаю что написание ОС будет сопровождаться так или иначе большим количеством unsafe раст кода.
Пока неизвестно насколько много реально unsafe кода там потребуется. Часть ядра, делающая вещи, которые в безопасные абстракции не оборачиваются, на самом деле крошечная. Буквально 1-2%. Хотя там есть и довольно хитрые структуры данных, которые тоже в безопасный Rust не засунешь.
В любом случае даже если unsafe кода будет не 5%, а целых 10% — это сократит объём кода, где могут быть проблемы в 10 раз.
Не соглашусь. Сила за будущим которое уже наступило. Вон сколько golang разрабы наклепали сотен если не тысяч различных утилит для линукса которыми одно удовольствие пользоваться или читать код. Причём это переделки старых, даже наверное уместнее будет написать "древних" утилит с свойственной этим утилитам духом того времени. Времени гиков, технарей, и манов для таких же разрабов как и они были на момент написания архаики.
В любом случае нужны будут жертвы, что бы создать что-то хорошее с нуля. Ну и бюджеты. А сейчас старый мир никак не хочет сдохнуть и тянет новое на дно. Но благо в этом болоте проявляются свои герои которые делают мир лучше.
Простите за абстрактность и обобщение, но вы сами видите как сильно меняется все, кроме ядра. Последние внушительные изменения в ядре я видел в 3 ветке, когда жизнь и популярность ddos атак заставила существенно править код и наращивать скорость обслуживания tcp/ip UDP/ip
Вон сколько golang разрабы наклепали сотен если не тысяч различных утилит для линукса которыми одно удовольствие пользоваться или читать код.
А теперь — не расскажите, как попасть в альтернативную вселенную, где это произошло?
Причём это переделки старых, даже наверное уместнее будет написать "древних" утилит с свойственной этим утилитам духом того времени. Времени гиков, технарей, и манов для таких же разрабов как и они были на момент написания архаики.
Круто. А названия будут? Потому как я ни об одной такой “переделке” не знаю. И я, в общем, не один такой.
Но в случае с утилитами это не страшно: даже если “из коробки” вы получаете “старые древние” утилиты никто не мешает установить вам новые, свежие хоть на Go, хоть на C#. Вон, Windows сразу с кучей… добра поставляется, даже с PowerShell в качестве дополнения к CMD.
А вот с ядром такой номер не проходит: оно, знаете ли, у системы обычно одно.
Ну в случае с Windows может быть “полтора”: ядро Windows для всех и Linux — для гиков. Но там тоже получается как с вашими утилитами на Go: круто, но мало кому нужно (это не саркам, это просто констатация факта).
Простите за абстрактность и обобщение, но вы сами видите как сильно меняется все, кроме ядра. Последние внушительные изменения в ядре я видел в 3 ветке, когда жизнь и популярность ddos атак заставила существенно править код и наращивать скорость обслуживания tcp/ip UDP/ip
А может вы просто не туда смотрите? Потому как я, наоборот, вижу что в сдре появляется всю больше асинхронных API (через io_uring), BPF позволяет упралять политиками (и выполнять всё те же самые асинхронные запросы) и т.д. и т.п.
Да, возможно мы просто наблюдаем разные части слона, но вот конференция, посвящёюнная eBPF (а это, внезапно, всего лишь одна из подсистем ядра) имеется, а где подобная для прославляемых вами утилит?
С таким же успехом я могу вас послать на crates.io
Этот список интересен только “уверовавшим”.
Я же хочу пример ну хоть чего-то, что было интегрировано в уже существующую экосистему взамен бывших там ранее средств (дистрибутив какой-нибудь или ещё чего-нибудь в таком духе).
простите, но это бред. Вы сами придумываете проблему и её решение выдавая за "победу".
Я обожаю экосистему современных утилит для Linux серверов написанных на современных языках (golang например). И я очень благодарен разработчикам данных утилит за их труд.
Почему? Потому что написаны людьми для людей, а не гиками для гиков. В чем это проявляется? В простоте установки, эксплуатации, документации, аргументов человекочитаемых, в скорости работы, в решении той проблемы которая возложена на конкретную утилиту. И такие инструменты часто из себя представляют новую генерацию древних комплексных связок разных утилит. Где нужно почитать страниц 300 документации что бы найти нужный флаг написанный на иврите или диалекте майя.
Просто вы наверное не пользовались ничем современным, поэтому и не знаете. Попробуйте.
Понимаете, я человек простой. И в спорах обычно “воду”, эмоции, просто игнорирую. Потому что одному нравится арбуз, другому свиной хрящик.
Потому что написаны людьми для людей, а не гиками для гиков.
Ну вот сколько тут полезной информации?
В простоте установки
Вы всерёз считаете, что установка чего-то может быть проще чем отсуствие необходимости что-то устанавливать?
эксплуатации, документации, аргументов человекочитаемых, в скорости работы, в решении той проблемы которая возложена на конкретную утилиту.
Если вылить отсюда воду, то останется, пожалуй, только “скорость работы”, остальное — вкусовщина. Ну и о какой, конкретно, утилите идёт речь? Где бенчмарки?
Ну вот сравните, хотя бы, с ripgrep: там прямо на входе у вас написано что меряли и чего получили.
Вот в вашем случае чего-нибудь в этом духе есть?
Где нужно почитать страниц 300 документации что бы найти нужный флаг написанный на иврите или диалекте майя.
Ну если вы не отличаете английский от иврита, то тут я бессилен. А что касается 300 страниц документации — так по вашей ссылке хорошо если 3000 страниц документации на кучу всего-на-свете, а не 30000 страниц.
Просто вы наверное не пользовались ничем современным, поэтому и не знаете.
Разумеется.
Попробуйте.
Но… зачем? Если вы, попробовав и распробовав, не можете привести ни одного примера объективного преимущества этих самых современных тулов, но при этом страшно жалуетесь на то, что вы обнаружили у традиционных утилит что-то на диалекте майя, то я, скорее, предположу, что вы просто не умеете оными утилитами пользоваться и потому выбираете “новый, модный, молодёжный” подход… но мне-то это зачем?
В большинстве случаев “новый, модный, молодёжный” — это дикая трата ресурсов, когда ту же самую задачу решают медленнее и менее гибко, чем с более традиционными подходами.
Иногда бывают и исключения. Но вы пока меня аж никак не убедили, что “новые” утилиты для копирования файлов на golang чем-то круче чем cp.
Я ripgrep-то редко пользую ибо grep всегда под рукой, а ripgrep устанавливать нужно. Тем более я не собираюсь что-то пробовать если единственный довод “вы попробуйте — вдруг понравится”.
Более того, если я не сильно ошибаюсь, "современные" утилиты грешат отсутвующей плохой работой с pipe, а я допустим как то не представляю себе работу в командной строке без пайпа.
По разному бывает. И в некоторых случаях копия бывает лучше ориганала (недаром четверть века назад люди себе GNUтые утилиты ставили себе на Solaris).
Но когда тебя в ответ на простую просьбу объяснить чем, собственно, новая версия лучше, засыпают бесполезными ссылками на какие-то каталоги и баззвордами… сразу возникает вопрос: а вы с оригинальными утилитами вообще знакомы? У вас точно не эффект утёнка с этими “современными утилитами для Linux серверов”?
Потому что я, глядя на большинство этих утилит испытываю чувства, которые цензурными словами передать сложно.
Вот смотришь на что-нибудь подобное:
$ size /usr/local/bin/gqui
text data bss dec hex filename
583207760 16454736 11618072 611280568 246f66b8 /usr/local/bin/gqui
И думаешь: чего вообще можно столько засунуть в аналог mysqlclient? И зачем?
Мне кажется проще написать с нуля чем переписывать то что есть. Чисто психологически — в первом случае ты создаешь что-то новое, во втором — исправляшь старое багованое.
Это синдром молодого разработчика: «Да что тут делать-то, сейчас с нуля напишем, месяца за 3 управимся».
В имеющийся код вложены деньги, он работает и включает множество мелких моментов, выявленных в опытной эксплуатации. С новым кодом вы весь этот бег по граблям пройдете заново.
На мой взгляди имеет чистую попытку "отжать" ядро Линукс целиком.
отказ от рабочего процесса только по электронной почте
Это хоть какой то барьер, если человек сумел в мэйллисты, значит сумеет банально оформить патч. Иначе рискуем по примеру github, где любой будет заводить issue на свой вкус и цвет. Ах да еще забыл добавить что мэйл листы тоже под контролем версий, как туда заводить зоопарк "не только по электронной почте", как всегда за кадром.
сообщил, что проблемам в ядре уделяется недостаточно внимания
в настоящее время после выпуска версии происходит слишком много операций тестирования ядра
Ну да, ага.
Linux используется во многих самых прибыльных компаниях мира, в том числе и в самой Google.
Вот только польза для ядра несоразмерна, пользе для самих компаний. Многие компании не дают даже железа для поддержки своих платформ. Что касается самого Андроида, то большинство их собственных изменений это сомнительная работа, в том числе из-за специфиного железа уникального для каждого смартфона.
В обще выглядит как очередная попытка захватить Ядро — поломаем воркфлоу, нагоним толпу новых программистов на Расте, когда мантейнеры логично будут не справляется с этой вакханалией поднимем хай — "старики ни на что не годны, дорогу молодым".
Гнать поганой метлой всех корпоративщиков, пытающихся изменить процесс и административную структуру под себя.
И что им мешает этих 100 инженеров у себя внутри выделить, чтобы посылали патчи?
А разработчики ядра уже разберутся.
Вот чего я боюсь, так это очередного "наведения порядка."
Сейчас вся разработка понятна. И ориентирована она на самих разработчиков. В словах данного представителя гугла касаемо отказа от электронной почты я вижу очередную попытку "эффективного манагерства": меньше разработки, больше красивых отчётиков и святой имитации бурной деятельности. Видел я, к чему это приводит (
И действительно, не хватает 100 человек? Выделите их в помощь. Есть отличные механизмы разработки и поддержки, используйте их! Не надо выдумывать отсебятину, потому что вы так привыкли разрабатывать сайты.
RUST получил похвалу от Торвальдса, планируется добавление возможности разработки на rust в ядре. Ну и пишите новый код на нём, раз хочется. Никто не осудит. Но переписывание ради переписывания...нет, не надо так.
RUST получил похвалу от Торвальдса
Вроде Линус весьма сдержанно высказывался по поводу rust или его позиция изменилась?
Вроде Линус весьма сдержанно высказывался по поводу rust или его позиция изменилась?
Да не не поменялась, последний был в стиле "Молодцы, но что вы сделали для Ядра в последнее время", в общем захотел реальных примеров использования. Я думаю это просто, чтобы никого не сагрить, ведь речь в приципе не о Расте.
Они дошли до состояния, когда Линус аргументрированно высказывается на тему, что нужно поменять в Rust, чтобы его приняли.
При этом, что важно, ни одно из его требований не противоречит идеям разработчиков самого Rust: все они и так у них были в состоянии “а неплохо бы сделать такую шнягу”… просто рабочих рук не хватало.
Ясно, что если что-то лежит не в разделе “а было бы неплохо”, а в разделе “это нужно, чтобы Rust приняли в ядро”, то приоритет у таких фич повышается.
Так что… будем ждать.
Правда некоторые из нужных фичей весьма тяжёлые. Вот это вот, например.
С одной стороны решение принято: Rust поверх GCC одобрен. С другой… это ж сколько работы предстоит!
Они дошли до состояния, когда Линус аргументрированно высказывается на тему, что нужно поменять в Rust, чтобы его приняли
ссылку можно?
А хотя бы на его самое первое сообщение не пробовали смотреть? Там он обсуждает вопросы аллокации памяти и паник. И то и другое — обсуждалось в Rust-сообществе (хотя в стабильном Rust пока отсуствует). Есть #[no_panic] для функций и no-panic-whatsoever, есть RFC на работу с аллокаторами и прочее.
Сдержанно, да. Но для некоторых (даже многих) это прозвучало как:"О, нафиг С, сейчас как напишем на RUST, только геометрию доделаем, училка злая." Утрирую, но суть понятна.
Как я помню, Линус одобрял rust в перспективе под новые драйверы. И точка. Никаких "давайте перепишем".
Как я помню, Линус одобрял rust в перспективе под новые драйверы. И точка. Никаких "давайте перепишем".
А так оно работать не будет.
Если окажется, что Rust использовать удобно — так его использовнаие будет расти, и, в конце-концов, всё ядро окажется написанным на нём.
А если окажется, что неудобно — то сочтут эксперимент неудачным и выпилят Rust нафиг.
Это, как бы, обсуждать сейчас попросту бессмысленно. Посмотрите на Mozilla: они, собственно, изначально Rust и разработали — но даже там Servo таки свернули, но Oxidation идёт потихоньку.
Гугл, руки прочь от Линукса!
Этих товарищей точно нужно держать подальше. Зная культуру разработки в гугле, страшно представить, что они наворотят.
Вообще, претензии к Си справедливы. Это старый язык, и может быть, на нем можно писать безопасно, но сишники ничему не учатся и продолжают писать "опасный" код. Например, вместо использования класса для строк (или буферов памяти) они вручную возятся с указателями и этим создают риск уязвимости вроде переполнения буфера. Хотя такие уязвимости известны уже лет 40, сишники не хотят применить какой-то радикально новый подход, ликвидирующий эти уязвимости, и продолжают вручную возиться с указателями.
Потому я считаю, что Си безнадежно плох, если он не позволяет раз и навсегда закрыть такой класс уязвимостей. К примеру, в PHP или JS при работе со строками не возникает переполнения буфера, так как вся работа идет через абстракции, а не через прямую работу с указателями.
Также, в Линукс огромный объем кода работает в ядре — с наивысшим уровнем привилегий. Линукс содержит тысячи драйверов, и это расширяет поверхность атаки. Линукс не предпринимает мер для понижения привилегий и изоляции кода драйверов. Уязвимость в любом из драйверов позволяет получить максимальные привилегии в системе.
Понятно, что ошибку может сделать любой. Но один после этого примет меры, чтобы такой класс ошибок больше не возникал никогда, а другой просто "залатает" ошибку и продолжит писать в том же стиле.
Чтобы далеко не ходить, давайте возьмем пример недавней уязвимости в ядре линукса: преобразование size_t в int привело к возможности переполнения буфера и перезаписи памяти ядра.
В коде переменная типа size_t (беззнаковый тип) передавалась в функцию с аргументом типа int. И если size_t имел значение более 2 млрд, то переменная int становилась отрицательной. Что позволяло обойти проверку размера буфера.
Такая ошибка могла быть отловлена компилятором (но не была), и не была отловлена статическим анализатором. В качестве причин указывают то, что код ядра написан таким образом, что анализаторы выдают много ложных предупреждений и потому их не используют. Это уже, согласитесь, говорит о качестве кода не лучшим образом. Возможно, "опасный" код дает чуть большую производительность. Но нужен ли вам прирост производительности на несколько процентов, если с ним идет куча уязвимостей?
Замечу также, что в коде нет абстракций для работы с буферами: код вручную складывает указатели и копирует память через memcpy, вместо того, чтобы вызвать абстракцию вроде extend_buffer(buf).
Наконец, на аппаратном уровне уровень безопасности на PC ниже, чем на других платформах.
Сравним ядро Линукса на PC и ядро iOS на iPhone. В iPhone после загрузки ядра в память область кода ядра аппаратно необратимо блокируется на запись, и защиту можно снять только перезагрузкой. Код, управляющий таблицами страниц, также защищен от записи, и специальные аппаратные меры приняты, чтобы таблицами страниц нельзя было управлять из другого места. А что Линукс на PC? Память ядра не защищена аппаратно, доступ к таблицам страниц не защищен. Таким образом, взлом системы с Линукс на PC проще, чем системы с iOS.
Вы должно быть троллите?
К примеру, в PHP или JS при работе со строками не возникает переполнения буфера, так как вся работа идет через абстракции, а не через прямую работу с указателями.
Так ядро это как раз та штука которая порождает абстракции. Что делать если у вас внутри абстракции которая обрабатывает строки кончится память (физическая)? В текущий момент размер строки может быть задан статически, что исключает внезапное окончание памяти. Плюс есть гарантия скорости исполнения ядерного кода за счет миниизации внутренний абстракций (что как-бы критично).
Также, в Линукс огромный объем кода работает в ядре — с наивысшим уровнем привилегий. Линукс содержит тысячи драйверов, и это расширяет поверхность атаки. Линукс не предпринимает мер для понижения привилегий и изоляции кода драйверов. Уязвимость в любом из драйверов позволяет получить максимальные привилегии в системе.
Это как раз следствие простоты ядра. Вы предлагаете тащить туда какой-то хитрый контроль доступа? А зачем? Представляете насколько это замедлит скорость обработки для тех же десятигигабитных интерфейсов?
Опять таки в некоторых случаях есть всякие fuse, где вы можете писать драйвера ФС на уровне пользователя. Это медленно, но работает.
Возможно, "опасный" код дает чуть большую производительность. Но нужен ли вам прирост производительности на несколько процентов, если с ним идет куча уязвимостей?
Чуть большую? Опять троллите? Как пример патчи от spectre/melltdown дали нам 30% падения производительности. И это без изменения стиля программирования. Опасный код пишут не просто так. Если у вас будет "безопасный" код в коде планировщика задач, например - все может значительно замедлиться. Я бы сказал что там не несколько процентов, а процентов 30-60, потому что есть критичные куски кода.
В iPhone после загрузки ядра в память область кода ядра аппаратно необратимо блокируется на запись, и защиту можно снять только перезагрузкой. Код, управляющий таблицами страниц, также защищен от записи, и специальные аппаратные меры приняты, чтобы таблицами страниц нельзя было управлять из другого места. А что Линукс на PC? Память ядра не защищена аппаратно, доступ к таблицам страниц не защищен.
А в iPhone вы можете добавить модули ядра без перезагрузки? Может пропатчить от уязвимостей на лету? Для iphone критичен аптайм?
Безопасный код не идет даром. В том же rust мы расплачиваемся скоростью компиляции. И опять таки, для производительного кода приходится использовать unsafe.
А вообще рекомендую почитать книгу Робет Лав - Ядро Linux: Описание процесса разработки. Ядро реально простое. Хотя бы почитайте раздел: `Отличия от обычных приложений`
Это как раз следствие простоты ядра. Вы предлагаете тащить туда какой-то хитрый контроль доступа? А зачем? Представляете насколько это замедлит скорость обработки для тех же десятигигабитных интерфейсов?
справедливости ради, зачем-то в ядро тащат всё, что ни попадя. зачем в kernelspace какой-нибудь термодатчик на 1-wire я не понимаю. ИМХО добрую половину драйверов можно было бы вытащить в отдельные процессы без сколько-нибудь заметной потери производительности.
Это да, тут соглашусь. И на самом деле есть прогресс в этом направлении. Тот же драйвер сканера отпечатка пальца может работать от пользователя и вообще написан python (python-validity). Тут больше наверное вопрос в том, как предоставлять доступ для остальных программ. Т.е. сейчас, в основном, используется sysfs/procfs, но по идее можно же и как-то предоставить через другое место?
Что-то это все начинает походить на додо пиццу, только им надо 300 программистов, в этим - 100 специалистов по безопасности.
Google: команде безопасности ядра Linux не хватает примерно сотни инженеров