Comments 19
На картинке комбайн. Это они так с типами работают?
На выходе зачастую получается невообразимая каша которую невозможно поддерживать. Так хоть полтора Cobol-специалиста понимали что там написано, а после преобразования к Яве, никто уже вообще ничего не понимает.
Это такой лайфхак для(от) прижимистого хозяина. Когда старая вещь работает плохо, а заменить ее не дает жаба - разбираешь, с понтом "сейчас как починю", чуть поковырялся, спустя некоторое время идея заменить на новую уже не кажется такой плохой.
Я помню как лет 15 назад были конверторы из Java в C# и наоборот. И хотя эти языки на порядок более похожи между собой чем С и Rust, на выходе получалась абсолютная ерунда, которая даже если комплировалась, то была абсолютно не читабельна. Так что идея максимально сомнительная.
Наконец, он поставил под сомнение само понимание безопасности: критики фокусируются на безопасности памяти, оставляя без внимания многие другие места, где можно проколоться.
В точку! Стремление определенных людей любой ценой переписать все на якобы безопасный Раст напоминает утопическую идею вроде всемирного коммунизма или проекта Венера.
Тем временем, когда x86 со своим защищенным режимом (особенно 386+) предложила защиту на аппаратном уровне (которая поставила бы крест на атаках типа переполнения буфера, исполнения шелл-кода), никто толком не заценил технологию, не бросился имплементировать её и создавать новые ЯП под неё. В итоге развивать и оптимизировать эти плюшки Интел не стала, а в x86-64 они и вовсе попали под выпил.
смею заметить, что облажался тогда не Intel, а Microsoft. Они выпустили несколько версий своей ОС с дико глючным ядром. Эта платформа ia64 (Intel Itanium) люто глючила и тормозила. А сам проект процессора был неплохим. В процессоре было много реализовано из идей IBM и получилось бы круто, если бы не жадный дядя Билли. ))
Подождите, я не говорю об IA-64 aka Itanium.
Я говорю о i386 и его плюшках — плюшках его защищённого режима. И не Интел облажался, а мировое сообщество, которое не стало всё это использовать.
Удобная для программистов вещь, но абсолютное зло с точки зрения изначальной идеологии защищённого режима — так называемая flat-модель организации памяти. В рамках одного процесса операционной системы абсолютно все данные «видны» любому коду в рамках процесса. Большинство данных в адресном пространстве процесса доступно для перезаписи абсолютно кому угодно (то есть какому угодно коду, оказавшемуся в рамках процесса, даже шелл-коду, который хакер заботливо загнал в переполнившийся буфер). Некоторые данные защищены от перезаписи на уровне защиты страниц, но это защита чисто номинальная, потому что снять её не составляет никакого труда.
Между тем защищённый режим x86 предполагает возможность сделать так, что каждый отдельно взятый кусок программы имеет доступ только к тем данным, с которыми ему дозволено работать. И не только данным, но и другому коду. То есть можно программу нарезать на маленькие куски, эдакие микромодули и каждый поместить в песочницу, в которой доступен минимально необходимый набор данных (и кода). Так, что комар не пролетит. Каждый буфер может иметь аппаратную защиту от доступа за его границу.
Но это потребовало бы совершенно иного программирования и других ЯП.
Вы и сейчас можете PKRU использовать, pkey_mprotect из любого ЯП доступен.
Серьёзно?
Сравнивать концепцию, которая буквально вчера появилась в процессорах, с концепцией, которой уже сорок лет?
«Ваша» memory protection keys по сравнению с сегментами защищённого режима:
Page-level, а не byte-level защита. А вот сегенты защищённого режима могли (могут) иметь как страничную, так и байтовую гранулярность.
Работает только в 64-битном режиме (не проверял)
Ограничение на максимальное число ключей защиты, жестко заданное на уровне архитектуры процессора. Всего 16 ключей защиты на любой процесс. Шестнадцать, Карл! Это значит, можно создать 16 независимо защищаемых буферов или разделить все защищаемые страницы на 16 подмножеств.
Принципиально никак не защищает от ошибок переполнения буфера — если индекс/смещение адресуемого элемента больше величины буфера, мы получаем такое же исключение, как просто при доступе в «запрещённую для чтения» страницу, но если индекс/смещение на удачу достаточно большое, то можно чисто случайно попасть пальцем в следующий доступный и разрешённый для нас буфер и операция чтения/записи пройдёт вообще без сучка и без задоринки. То есть это технически решение такого же уровня надёжности, как в обычном x86 без этой новой технологии просто после буфера создать полосу из guard-страниц и надеяться, что когда кто-то по ошибке вылезет за пределы буфера, он наткнётся на guard-страницу и будет отловлен. Но если он перепрыгнет guard-gap, то никто тревогу не забьёт.
Вообще никак не распространяется на instruction fetchинг у процессора. То есть по прежнему в рамках одного процесса кто угодно может вызывать кого угодно. Любой код может сделать call или jmp в аюсолютно любое место адресного пространства, если базовые аттрибуты защиты страниц это позволяют.
По прежнему не позволяет реорганизовать написание программ и архитектуру приложения так, что приложение дробится на множества маленьких микро-песочниц, где прорыв безопасности и установление полного хаоса в одной из них никак не распространяется на соседние. Оно и не удивительно: это решение в духе «пришей кобыле хвост» — оно и не должно было бы революционным и не должно было бы требовать иных ЯП и иных архитектурных подходов.
Требует явного написания дополнительного кода программистом для того, чтобы получить какие-то бенефиты от новоявленной технологии.
Правильно, пусть всё течёт как есть, может до ящерки быстрее дойдем😀
а ну ладно, тогда можно не переводить. Пусть останутся баги в старом коде ¯\_(ツ)_/¯
Искренне желаю Минобороны США скорейшей трансляции всего кода написанного на небезопасных языках в Rust. Желательно с автоматическим и удаленным деплоем сразу из-под трактора.
Но можно, пожалуйста, им не лезть в базисные проекты с открытым исходным кодом с этими сомнительными экспериментами?
Вообще DARPA умеют в стратегические инициативы и регулярно устраивают что-то подобное. Технически, они формулируют актуальную проблему и приглашают всех желающих специалистов вместе подумать над решением. Этакий хакатон с гос. поддержкой длиной в несколько лет.
Что-то потом выстреливает и мы получаем, например, Internet. Что-то становится знанием и базой для новых идей. Что-то отбрасывается. Это как бы альтернатива новостям со старта: "нет аналогов в мире" и "через 10 лет".
Кажется нас ждёт колхозная реализация.
Присоединяйтесь к бесплатному курсу по Rust на платформе Stepik :)
Минобороны США готовит транслятор TRACTOR (Translating All C to Rust) для автопреобразования проектов на C в код на Rust