LINUX.ORG.RU

Fil-C — компилятор для языков C и C++, гарантирующий безопасную работу с памятью

 , , ,


1

5

Цель разработки компилятора – полная совместимость с синтаксисом языков Си и С++ при обеспечении полной безопасности работы с памятью. Заявляется, что для использования достаточно пересобрать существующий код, так уже компилируются и работают bzip2, zip, pcre и ncurses. С незначительными модификациями поддерживается сборка OpenSSH, OpenSSL, CPython, SQLite, Lua, Curl, Lynx, jpeg6b, zsh, xzutils и simdutf.

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

Заявляется отслеживание защитой: выделения и корректного освобождения памяти в стеке и куче, отслеживание неправильной обработки типов и состояние гонки при работе с указателям.

Компиляция занимает в 1,5-5 раз больше времени, чем у gcc. Скорость выполнения в 1.2 раза ниже, чем при работе аналогичных программ, скомпилированных gcc. Пока компилятор доступен только для linux-платформ, такое решение было принято разработчиками для того, чтобы не распылять усилия. Линковка с объектным кодом, созданным другими компиляторами, невозможна в силу разного ABI.

Задействованный в Fil-C механизм MonoCap основывается на применении 16-байтовых указателей, в которых помимо адреса в памяти, указывается ссылка на объект, включающий сведения о возможностях (capability), таких как верхняя и нижняя границы буфера, ассоциированного с указателем, а также массив, определяющий типы данных, хранимые в каждом блоке памяти (1 байт с информацией о типе (unset, int, ptr, free) для каждого 16-байтового блока памяти). При каждом обращении к памяти по указателю осуществляется проверка границ и типа (например, в память с типом «ptr» не могут быть записаны данные с типом «int» и наоборот).

Все операции выделения и освобождения памяти обрабатываются сборщиком мусора FUGC (Fil’s Unbelievable Garbage Collector), который при освобождении памяти переводит все связанные с освобождаемым буфером записи о типах в значение «free» и затем перенаправляет все указатели на освободившиеся объекты на отдельный объект, сигнализирующий о том, что память уже освобождена. Любое дальнейшее обращение к блоку данных с типом «free» или по указателю, связанному с освобождённым объектом, приводит к генерации исключения, что позволяет защититься от уязвимостей класса use-after-free. Сборщик мусора работает параллельно и не приостанавливает выполнение других потоков.

Использование комбинации из MonoCaps и FUGC позволяет сохранить возможность привычной работы с указателями и оставить неизменной семантику вызовов malloc и free, предоставив при этом гарантированную защиту. Код программы может содержать различные логические ошибки, такие как неправильное приведение типов, неверные арифметические операции с указателями, состояния гонки и несвоевременный вызов функции free(), но независимо от всего этого, Fil-C запомнит исходные границы и тип данных, и прервёт выполнение, если будет предпринята попытка доступа по указателю к области вне запомненных границ, обращения к освобождённому блоку памяти или чтения данных с типом «int» как указателя или наоборот.

Автор Fil-C, Филипп Пизло (Filip Pizlo), занимает в компании Epic Games пост директора, отвечающего за проекты, связанные с языками программирования. Филипп имеет богатый опыт работы над виртуальными машинами, языками программирования, компиляторами и сборщиками мусора, например, в IBM он развивал язык программирования X10, в Microsoft работал над сборщиками мусора Stopless, Clover и Chicken, в Apple занимался JIT-компилятором и оптимизациями браузерного движка WebKit, в Epic Games возглавляет команду разработчиков, развивающую язык программирования Verse и связанную с ним виртуальную машину. Филипп также является одним из ключевых разработчиков виртуальных машин Jikes RVM, Ovm и Fiji VM.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: unfo (всего исправлений: 7)
Ответ на: комментарий от MOPKOBKA

Microsoft такой уже сделала %)

Это-же C++/CLI - такая хрень, чтобы под дотнет писать на плюсах, и смешивать с нативным кодом. gcnew = это new в CLR.

her_s_gory
()
Ответ на: комментарий от X512

Rust тоже от утечек не защищает.

Вот именно. Почему-то все думают только о памяти, а есть ещё другие ресурсы, которые могут утекать - открытые файлы, мьютексы, и т.д. GC в принципе от такого защитить не может, а в Rust контроль можно вообще отключить.

her_s_gory
()
Ответ на: комментарий от her_s_gory

Да чем угодно! :) Адреса страниц были длинными целыми с первого дня существования Линукса и другими не будут. Инфа — 100%, спросите у Линуса Торвальдса :)

Он где-то писал, кстати, об этом.

gns ★★★★★
()
Ответ на: комментарий от ergo

«FUGC» по идее читается так же, как «fug», а это «сор». Сборщик мусора - сор, типичный юмор.

Virtuos86 ★★★★★
()
Ответ на: комментарий от her_s_gory

а в Rust контроль можно вообще отключить

Очередной блаженный, верующий, что с mut Rust превращается в хирургический скальпель, отсекающий неумехе кодеру всё драгоценное? Как только в коде возникает первая проблемка с владением, компилятор быстро отучает от идеи, будто расставив mut, можно его ублажить.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Никогда не встречал чтобы люди под подобным подразумевали mut. Обычно речь об unsafe. // Хотя и он, надо признать, не снимает абсолютно все ограничения Раста; но не суть важно.

iXuta
()
Последнее исправление: iXuta (всего исправлений: 5)
Ответ на: комментарий от alysnix

Это шутка юмора такая? Скормите ИИ программу на питоне и предложите написать другую программу, которая ответит на вопрос остановится ли первая. Вот мне очень интересно. что ВАм ответят?

gns ★★★★★
()
Ответ на: комментарий от gns

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

то есть даже связка - си + некий ИИ ментор, будет побивать любой самый защищенный язык по совокупности преимуществ.

то есть вся эта возня с защитой памяти на уровне языков(русты и все такое) - это попытка впрыгнуть в ушедший поезд.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

Ну, если серьезно, то проблема останова — это одна из уязвимостей. Пример: программа на некотором входе попадает в бесконечный цикл. У меня лично был такой косяк. Писал нестандартную функцию сопоставления файлового пути регулярке, ну и не учел один предельный случай. Ну бывает, чо! Алгоритмическая ошибка. А вылилось все в типичный DoS. И еще код в ядре в обработчике сисколла. Вот и оцените последствия. :)

И как ИИ будет искать «специально обученный» входной набор данных — для меня загадка.

то есть вся эта возня с защитой памяти на уровне языков(русты и все такое) - это попытка впрыгнуть в ушедший поезд.

Да это все хайп, порожденный амерканским правительством и прочим разведывтельным сообществом «на основе некоторой статистики» на тему того, что 80% уязвимостей обусловлены некорректным обращением с памятью. Вот и ищут «серебряную пулю». Забейте.

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 2)
Ответ на: комментарий от gns

там вообще-то разговор шел о защите памяти, и всяких извращениях с указателями.

и что от всех проблем поможет некий язык типа руста.

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

то есть руст не нужен. а нужны ИИ менторы.

alysnix ★★★
()
Ответ на: комментарий от iXuta

Честно признаюсь, я перепутал, т.к. давно не трогал Растишку. Старость не за горами :(

Virtuos86 ★★★★★
()
Ответ на: комментарий от alysnix

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

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

Ну, если ее доучивать на каждом запросе, на false positive, например, то не совсем.

gns ★★★★★
()
Ответ на: комментарий от X512

Rust тоже от утечек не защищает.

На святое замахнулись... Ща заклюют!

Somebody ★★
()
Ответ на: комментарий от I-Love-Microsoft

Так lib128/*.so очевидно же
че как не линуксойд.

uin ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.