LINUX.ORG.RU

Компания Open Source Security спонсирует разработку gccrs

 , gccrs, ,

Компания Open Source Security спонсирует разработку gccrs

2

5

12 января компания Open Source Security, известная разработкой grsecurity, объявила о спонсировании разработки фронтенда к компилятору GCC для поддержки языка программирования Rust — gccrs.

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

Open Source Security мотивируют своё участие возможным появлениям кода на Rust в ядре Linux и тем, что ядро собирается чаще всего компилятором gcc. Дополнительно к этому, программы на нескольких языках сразу могут иметь уязвимости, вызванные именно этим фактом (см. Exploiting Mixed Binaries), которых бы не было в программах на чистом C или C++.

На данный момент Open Source Security спонсируют работу одного разработчика, который будет работать над gccrs в течение следующего года, с возможностью выделения средств на увеличение штата. Так же в процессе участвует британская компания Embercosm, специализирующаяся на разработке GCC и LLVM и предоставившая оформление официального трудоустройства разработчиков для данной инициативы.

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

★★★★★

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

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

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

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

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

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

В си и с++ все такими же тролейбусами всю жизнь собирается.

Разницы не понимаешь?

C и C++ создавали мудрые и практичные люди. Компилятор, линковщик и система сборки там изначально раздельные сущности. Именно для того, чтоб пользователь смог себе выбрать любую систему сборки, от простой и минимальной до переусложнённой и нафиг никому не нужной. Хоть троллейбус хоть дирижабль.

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

Но сейчас набегут сектанты и начнут опять орать: а нафига!? cargo такой хороший, все им должны собирать! А вот тут и видна разница подходов. Ну не хотят все люди до единого ходить в одинаковых узких штанишках, носить идентичные бороды и неотличимые татуировки какой-то шхуны.

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

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

Не соглашусь. Комилятор работает как компилятор из коробки – см. man rustc. Все приседания там от того, что система сборки и система управления зависимостями объединены в одно cargo. В C/C++ этих приседаний нет потому что там системы управления зависимостей нет вообще, а системы сборки разнятся от проекта к проекту, и поэтому для каждого случая приходится писать свои костыли, которые, однако, обычно будут проще обобщенных костылей cargo. Какой из подходов лучше – судить не мне.

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

C и C++ создавали мудрые и практичные люди

Хотел тебя поддержать, но случился undefined reference.

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

И компилятор в нём намеренно срощен с системой сборки.

Все не так просто. Возьмём, например, Хаскель в виде (единственной реализации) GHC. Система сборки гвоздями прибита к реализации. Есть два разных интерфейса — да, но факта это не отменяет.

Долгие и долгие годы хаяли «архаичную» (по мнению обвинителей) систему независимых единиц трансляции в C и C++. ОК, завезли начальную реализацию в C++20. В результате, выяснилось что нужен некий менеджер, который будет управлять запуском экземпляров для сборки зависимостей. Который впилен … в компилятор!!!

Т.е. а) сломаем все существующие системы сборки; б) впилим малопонятную хрень в компилятор; в) PROFIT!!

А ведь модули в C++20 — это всего лишь «PCH на стеродиах», не боле того. А стандартная библиотека будет модулизирована только к C++23. Так что будет и у C++ свой аналог Cabal.

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

Страдать из-за того что долбоящеры из гнума не осилили сишку?

Ее никто не осилил. См. описание 100500 уязвимостей, обнаруживаемых каждый божий год.

anonymous
()

Как жеж ононизмусу припекло. Пойду от центрального отопления откажусь)0

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

Ее никто не осилил.

Странно, а полезные, критически важные проекты, как продолжались писаться на C, так и пишутся. А на Расте, что-то кроме форков /bin/true и /bin/false написали уже или так до сих пор с Миром и здороваетесь? Пример: если убрать прямо сейчас все проекты на C, то вся IT-инфраструктура мира рухнет, если убрать Раст – расплачутся два фанбоя, да Вертухай самозабанится, и собственно все.

Это называется так – Достоинства C Преобладают Над Недостатками. Поэтому этот язык и востребован до сих пор.

Пока у Раста такие бездарные фанаты, которые «программируют» только язычками на форуме, за глубину могилы Раста можно не беспокоиться.

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

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

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

он одобрил, он и закроет, все в лучших традициях Гоголя.

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

Linux и BSD не являются сертифицированными POSIX системами

Заходим https://www.opengroup.org/openbrand/register/

Читаем «Huawei Technology Co., Ltd: Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server» и признаем, что обгадились. EulerOS это сборка CentOS от Huawei для своих серверов

То есть у одного из дистрибутивов сертификация таки есть

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

В локальном оверлее уже давно ебилд для адвайты с версией 9999 не зависящий от gtk3 чтобы заткнуть зависимость. Раньше вручную в gtk убирал зависимость от неё, но так разумеется прввильнее. Это просто значки, им не нужен gtk
rsvg просто старый размаскировал пока что, остальные замаскировал. Но если будет форк надо на него будет перейти. Либо заглушку использующую другой рендерер svg.
А может и вообще отключить. Не сильно то мне этот svg нужен в gtk
Ещё есть зависимость polkit от mozjs/spidermonkey
Ну тут всё просто - достал ебилд для polkit 1.0.5 и udisks-2.1.8
С elogind и consolekit проблем нету, всё работает. Возможно ого решето, но в локальную систему обычно никого не пускаю, и по сравнению с rsvg разбором файлов присшедших извне они заниматься не должны.
Ну и у gcc отрубаю bootstrap если его не требуется собирать с pgo/lto.

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

И какие это уязвимости? От DoS ржавчина не спасёт. Ну вместо сегфолта повалится другим образом
ROPы с aslr осуществимы слишком сложно. Обойти aslr на 64битной системе маловероятно. Если злоумышленнику удалось узнать адрес загрузки, то уже скорее всего поздно бояться уязвимости, он уже и так получил ко всему доступ.

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

И какие это уязвимости?

RCE, очевидно же.

От DoS ржавчина не спасёт.

Спасет, если DoS результат дедлока или неправильной работы с памятью.

ROPы с aslr осуществимы слишком сложно

https://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html

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

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

Как сказал бы Царь: а вот и ещё один, поддавшийся пропаганде.

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

Брутфорс 3.5 байт данных + брутфорс оффсета либ (у меня же гента с кастомными флагами)
Релевантно разве что если атака будет с локалхоста вестись. Да, возмоюно стоит опасаться если возможно атаку из js провести, в остальных случаях нет.
Пользователям популярных дистров повезло меньше и без rust им будет туго

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

Погоди, я не понял зачем убирать зависимость адвайты от гтк? Это как раз правильно должно быть (гткшные иконки без тулкита смысла не имеют, хотя черт знает). А вот почему гтк зависит от адвайты мне не понятно. Можно ли другую тему иконок вместо нее подсунуть или они все такие идиотские? Мне плевать как они выглядят пусть хоть квадратиками будут, все равно ни одной полезной программы с иконками у меня нет.

И еще - ебилд адвайты зависит от rsvg, но написано что ей на самом деле нужен gtk-encode-symbolic-svg. Это отдельная утилита и собирается как часть гтк, но в исходниках гтк упоминаний об рсвж нет (тыц, тыц).

 ldd `which gtk-encode-symbolic-svg ` | grep svg

ничего не показывает. Там libdl есть конечно, но тогда rsvg был бы в исходниках упомянут. Может оно вообще не нужно? Глянул сейчас gtk+-2.24.32-r1.ebuild и там то же самое. Может это просто по инерции копипастят с лохматых версий? Не удивлюсь если да, в этой помойке поди разберись что к чему.

Ещё есть зависимость polkit

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

Алсо, в процессе гуглежа нашел полезный патч, который якобы выпиливает мудацкие неубиваемые процессы связанные с аксессибилити: https://git.busybox.net/buildroot/tree/package/libgtk3/0003-disable-atk-bridge.patch

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

Брутфорс 3.5 байт данных + брутфорс оффсета либ (у меня же гента с кастомными флагами) Релевантно разве что если атака будет с локалхоста вестись. Да, возмоюно стоит опасаться если возможно атаку из js провести, в остальных случаях нет. Пользователям популярных дистров повезло меньше и без rust им будет туго

Какой-то бред гентушника.

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

А, нет. К сожалению, все сложнее.

$ find /lib* /usr/lib* /bin /usr/bin -type f -executable | while read F; do ldd $F 2>/dev/null | grep -q rsvg && echo $F ; done
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
/usr/lib64/ImageMagick-7.0.7/modules-Q16/coders/svg.so
/usr/bin/rsvg-convert
$ equery belongs /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
 * Searching for /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so ... 
gnome-base/librsvg-2.40.18 (/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so)

Ищем гдкпиксбуфлоадер и понимаем что это отдельный пакет:

$ equery list '*gdk*'
 * Searching for *gdk* ...
[I--] [??] x11-libs/gdk-pixbuf-2.36.12:2

Смотрим что там унутре equery files x11-libs/gdk-pixbuf, в частности нас интересует

/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jasper.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.so
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

т.е. куча форматов которые гтк/гдк умеет искаропки и лежат они в том же месте куда рсвж напихал свою libpixbufloader-svg.so И еще там есть утилитка gdk-pixbuf-query-loaders если запустить которую покажет все эти форматы и svg среди них тоже:

"/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so"
"qtif" 4 "gdk-pixbuf" "QuickTime" "LGPL"
"image/x-quicktime" "image/qtif" ""
"qtif" "qif" ""
"abcdidsc" "xxxx    " 100
"abcdidat" "xxxx    " 100

"/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so"
"svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
"svg" "svgz" "svg.gz" ""
" <svg" "*    " 100
" <!DOCTYPE svg" "*             " 100

...

Т.е. он, видимо, действительно опирается на libdl но soшки ищет не по захардкоженому имени, а по пути + naming convention. Это, в принципе, «хорошие» новости - осталось теперь понять что такого особенного в этой адвайте и можно ли ее чем-то заменить.

Если встретишь рустера на дороге - плюнь ему в его скотскую рожу. Сколько раз встретишь столько раз и плюнь.

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

То есть поставить rust-bin и перестать ныть для трушного гентушника это уже слишком, да? :D

anonymous
()

gccrs разрабатывается на C/C++?

MOPKOBKA ★★★★
()

урра! наконец-то!

всё, теперь заживём!

anonymous
()

Имеет смысл добавить в новость ссылку на блог разработчика где он регулярно публикует отчёты: https://thephilbert.io/

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

Когда появился C, то говорили примерно то же самое -_-

А можно пожалуйста ссылочку на то, как говорили. Или может в какой книге написано. Или вы своими ушами слышали..

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

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

для такого разработчика с шилом в * (или как вы это называете, аджайл?) вообще никакой линукс не подходит. но вот федора хочет. от этого у ней проблемы.

crypt ★★★★★
()

Если это позволит собирать firefox без clang, то это очень круто. А то сейчас для сборки firefox нужно держать 3 компилятора в системе - gcc - основной компилятор, rust - для сборки частей, написанных на расте, и clang - не знаю для чего, но без него судя по всему, части написанные на rust’е не компонуются с частями, написанными на C++.

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

D и Go уже давно в gcc

D и Go надавно в gcc, а foltran уже давно.

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

У GCC география распространения по разным архитектурам шире, чем у LLVM, а значит к rust-у

Раст это вам не бежественный C, в Раста проблемы с поддержкой разных архитектур «байдезайн».

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

для такого разработчика с шилом в * (или как вы это называете, аджайл?) вообще никакой линукс не подходит. но вот федора хочет. от этого у ней проблемы.

Для такого – это какого? Который DLL Hell не хочет? Чувак, все эти проблемы возникают далеко не в первый раз. И только некоторые линуксоеды упорно продолжают есть кактус и молиться на мейнтейнеров.

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

Раст это вам не бежественный C, в Раста проблемы с поддержкой разных архитектур «байдезайн».

Еще одна жертва пропаганды. Нет в С никакой поддержки архитектур. Более того, на том С который в стандарте ничего толком и не написано. Все толковое и архитектурозависимое реализуется в конкретных тулчейнах, да еще и расширениями всякими.

Поэтому linux написан не на С, а на GCC, и далее по списку.

А сам по себе С, из стандарта, практически ни на что не годен, тем более если дело касается системщины и поддержки архитектур.

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

Для такого – это какого?

современный тип разработчика. пишет мелкую апликуху и каждый день подтягивает свежие модули из node.js репы. две сотни, потому что в каждом использует одну функцию. как его назвать?

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

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

ты упомянул о факте. я конкретизировал, с чем это связано.

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

современный тип разработчика. пишет мелкую апликуху и каждый день подтягивает свежие модули из node.js репы. две сотни, потому что в каждом использует одну функцию. как его назвать?

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

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

Жертвой пропаганды о безопасном языке есть пользователи Раста.

Раст очень тяжело пртируемый, портирование на другие архитектуры очень сложно и очень трудоемко.

С очень прост в портирование на разные архитектуры процессоров.

И самое главное, гарантии безопасности и отсутствие возможности эксплуатации «страшных дыр» может дать только проц с ядром OS. А вы пытаетесь дать гарантии с помощью компилятора прикладного ПО. Этим сделав его сложнопортируемым на другие архитектуры.

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

Есть два подхода в безопасности ПО:

  1. Гарантии безопасности дает проц с ядром OS. Компилятор предоставляет полную свободу и ответственность программисту. Если программист написал код не безопасеным и при исполнении прога делает запрещенные действие, то ядро OS с процом эту прогу убивают. (Медленный компилятор, быстрый бинарь, компилятор легко портируемый)

  2. Компилятором у программиста отбирается свобода, в том числе возможность делать ошибку. Компилятор следит и отвечает чтобы в полученном бинаре не было ошибок и он корректно работал. (Компиляторы быстрые, бинарь чуточку медление, компилятор сложнопортируемый)

Какой из этих подходов лучше?

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

Раст очень тяжело пртируемый, портирование на другие архитектуры очень сложно и очень трудоемко.

Это поэтому у него список архитектур больше чем у Go, да? Потому что портировать сложно?

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

А что плохого-то в том, чтобы подтягивать последние версии зависимостей?

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

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

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

И самое главное, гарантии безопасности и отсутствие возможности эксплуатации «страшных дыр» может дать только проц с ядром OS. А вы пытаетесь дать гарантии с помощью компилятора прикладного ПО. Этим сделав его сложнопортируемым на другие архитектуры.

Вообще забавно, как C людей в мозг изнасиловал. Чувак, вот правда, C это язык где неправильный индекс массива позволяет выполнить код. Понимаешь? В языке нет нормальных строк и Option, зато есть встроенное в error path метапрограммирование, единственное предназначение которого – стрелять себе в ногу. Это настолько дико выглядит, что я никак не могу понять, почему люди до сих пор считают это нормальным.

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

Это с первого взгляда лучше контролировать все одним компилятором.

А если необходимы гарантии безопасности? С прикладного ПО гарантий не получишь.

Для гарантий безопасности необходим аппаратно-программный контроль со стороны процессора и ядра OS. И гарантии безопасности будут одинаковы для С-шной проги и растовой. Потому что основные гарантии идут от проца и ядра OS, а не от компилятора. Проц с ядром OS выделяют память и следят за ее использованием во время работы любого бинаря!

Конечно компилятор и линковщик очень важен для безопасности и gcc с binutils предоставляют сегодня широчайший набор опций компиляции усиливающих безопасность бинаря. Жаль дистростроители ими не пользуются.

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

это как роллинг-дистрибутив

Да нет, это совсем разные вещи.

Кстати, я вот в упор не понимаю, почему линуксовые дистрибутивы обязательно должны контролировать ВООБЩЕ ВСЕ версии ВООБЩЕ ВСЕХ компонентов ВООБЩЕ ВСЕХ программ? Почему нельзя иметь стабильную базовую систему, а пользовательские приложения могут использовать те версии библиотек, которые нравятся разработчикам? Мне очень нравится тенденция вокруг flatpak и ostree именно этим подходом.

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

А как одно с другим связано? Потому что я видел, например, программы из 5 строк на C++, которые тянут за собой Boost и ещё всякого. Та же фигня выходит.

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

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

unC0Rr ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.