Ржавчина Безопаснее, Но Безопасно Ли Мы Ее Используем

Rust, по — видимому, является большой надеждой на создание более безопасного языка программирования. Он обеспечивает сложные проверки того, что вы делаете, что затрудняет написание кода, который может скрыть ошибку или разрешить эксплойт. Вопрос, на который пытаются ответить новые исследования, заключается в следующем: безопасно ли мы пишем Rust?

Основной способ, которым языки обеспечивают безопасное кодирование, — это наложить ограничения на то, что вы можете делать. Иногда вы просто не можете жить с этими ограничениями, если хотите выполнить свою работу или, чаще всего, сделать ее эффективно. Таким образом, почти всегда есть пункт «убирайся». В случае Rust есть ключевое слово Unsafe, которое позволяет вам обойти надзор Rust за тем, что вы делаете. Например, он позволяет вам использовать указатели в стиле C, которые, как известно, небезопасны и являются источником большинства ошибок и уязвимостей, которые мы генерируем.

Даже код, помеченный как небезопасный, проверяется компилятором и генерируются предупреждения. Помимо предоставления программистам свободы быть эффективными или просто ленивыми, ключевое слово Unsafe также сигнализирует о частях кода, которые заслуживают особого внимания. Он говорит: «здесь будет тьма», которую остальная часть языка держит в страхе.

Дело в том, что небезопасный код, вероятно, небезопасен, а код Rust, заваленный кодом, аннотированным Небезопасным, ничем не лучше кода C, который, вероятно, легче писать.

Итак, сколько существует небезопасного кода и имеет ли он большой эффект?

Это вопрос, который Ана Нора Эванс, Брэдфорд Кэмпбелл и Мэри Лу Соффа, исследовательская группа из Университета Вирджинии, решили ответить на этот вопрос, изучив библиотеки Rust.

Короткая версия ответа заключается в том, что все не так плохо, как вы могли бы себе представить, но последствия сложны. Они обнаружили, что только 29% библиотек Rust содержат небезопасный код. Проблема в том, что зависимости превращают это в эффективные 50%, поскольку библиотеки, которые не используют небезопасный код, импортируют библиотеки, которые это делают. Еще хуже та статистика, что 60% наиболее часто используемых библиотек содержат небезопасный код. Как ни странно, они также обнаружили, что проект Servo, проект Mozilla по созданию движка рендеринга ржавчины, имел еще более высокий уровень небезопасности.

С другой стороны, большинство из этих применений небезопасных просто применяются к функциям, которые вызывают другие небезопасные функции, и 22% из них в конечном итоге вызывают внешние библиотеки C, которые по определению настолько небезопасны, насколько это возможно.

Лучшая новость заключается в том, что в 90% библиотек было менее десяти небезопасных блоков.

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

Исследователи спросили программистов, почему они использовали небезопасное, и действительно, 55% ответили, что это было сделано из соображений производительности. Однако 40% сказали, что ржавчина слишком ограничительна, а 25% сказали, что это слишком сложно.

Нам нужно разобраться в этом подробнее. Действительно ли безопасная ржавчина слишком ограничительна, и 25% просто ленивы и недостаточно хорошо изучают ржавчину.

Исследователи предполагают, что возможным решением является внедрение лучших инструментов, помогающих программистам:

Мы предлагаем внести следующие изменения в ящики.интерфейс ввода-вывода:

i) новая бирка или значок для ящиков, содержащих небезопасную ржавчину;

ii) дерево зависимостей для каждой библиотеки с четко обозначенными ящиками, использующими небезопасную ржавчину;

iii) список проверок кода для любой небезопасной ржавчины.

Я также думаю, что команде Rust необходимо решить вопрос о том, почему используется Unsafe, и найти способы убедить программистов в том, что все можно сделать без него.