LINUX.ORG.RU
ФорумTalks

Безопасный код и современные ЯП

 ,


0

2

Посмотрел вот это «Руководство по эффективному программированию […]»:

http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf

Пишут, что разработан lcc, который поддерживает C99 и C++14, также есть lfortran. Вобщем-то, понятно, что раз в экосистема эльбруса использует опенсорс наработки вокруг Linux, то C и C++ здесь решающие ЯП. Но как же быть с остальным софтом, который, возможно, будет разработан с учетом повышенных требований к безопасности, корректности реализации, минимизации ошибок?

Ведь в 21м веке уже только ленивый не говорит об этом, и из каждого утюга доносится: C++ априори небезопасен, пора кончать его использовать для разработки современных приложений. Но что есть из более безопасных инструментов для разработки под Эльбрус? Или предполагается, что компиляторы и ВМ для остальных ЯП прикладники разработают сами при помощи lcc? Или считается, что программисты под Эльбрус ошибок делать не будут?

★★★★★

Или предполагается, что компиляторы и ВМ для остальных ЯП прикладники разработают сами при помощи lcc?

Разве lcc не компилирует тот же CPython?

Crocodoom ★★★★★
()

Или предполагается, что компиляторы и ВМ для остальных ЯП прикладники разработают сами при помощи lcc?

Я тебя очень сильно удивлю, но компиляторы, интерпретаторы и VM для остальных ЯП написаны как раз на C/C++.

Python – CPython с GIL на C
Java – JVM на C++
Perl – С
Ruby – C
JavaScript – C++
PHP – C
Rust – Rust/C++

Имея lcc большинство этих языков и технологий и были собраны под Elbrus.

EXL ★★★★★
()

C++ априори небезопасен

C++ самый безопасный язык из существующих.

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

Можешь кончать. Разрешаю.

fsb4000 ★★★★★
()

Вообще, да, ведь речь там про «эффективное», что не обязательно «безопасное».

seiken ★★★★★
() автор топика

Пилят (уже, как я понял, есть рабочий прототип) IR-транслятор llvm -> lcc, что соответственно даёт работающий llvm-backend и все работающие для него фронты (да и Rust тоже).

java - есть, скриптота вся есть. Я слышал, что пилят Go, но пруфы не найду.

SkyMaverick ★★★★★
()

Или считается, что программисты под Эльбрус ошибок делать не будут?

Считается, что ты перепишешь весь софт под Эльбрус на safe-подмножестве раста.

LamerOk ★★★★★
()

Здается мне, им не хватит ресурсов делать портирование и Java и JS и Python и всего отстального и обеспечивать адекватное реагирование на баги. Ведь в случае x86_64 софт пилят его разработчики и обеспечивают его сборку, а тут за сборку отвечают эльбрусовцы. Тем более lcc со стандартом аж C++14 в уже почти 2021 году - это отставание, уже C++20 почти полностью поддерживается основными компиляторами x86_64. Некоторое ПО уже для сборки требует С++14 и выше, а скоро уже будет С++17 и выше. И это при том, что в компиляторах постоянно вылавливают баги, которые нужно скоро закрывать, и тут тот же вопрос к разработчикам lcc - смогут ли они обеспечить оперативное реагирование? Или они будут ехать на древних версиях? И ксати, будет ли CMake нормально работать с компилятором эльбруса?

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

вопрос к разработчикам lcc - смогут ли они обеспечить оперативное реагирование? Или они будут ехать на древних версиях? И ксати, будет ли CMake нормально работать с компилятором эльбруса?

C C++ должно быть всё отлично, потому что у них покупной front-end C++ от Edison Design Group. И в lcc 1.25 уже есть частичная поддержка C++20, судя по новостям.

Смотри табличку: https://en.cppreference.com/w/cpp/compiler_support

EDG eccp в табличке это примерно lcc.

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

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

alexanius ★★
()

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

Тестирование, анализаторы, санитайзеры, фаззеры?

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

А что есть из более безопасных инструментов для разработки не под Эльбрус? Нужны не языки. Нужны гайды и инструменты. Как MISRA C.

mkam
()
Последнее исправление: mkam (всего исправлений: 3)

Программисты под Эльбрус не ошибаются

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

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

C++ априори небезопасен, пора кончать его использовать для разработки современных приложений

И переходить на нормальный C.

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

Тем более lcc со стандартом аж C++14 в уже почти 2021 году - это отставание, уже C++20 почти полностью поддерживается основными компиляторами x86_64.

AFAIK сегодня нет ни одного компилятора с поддержкой всех основных фич C++20 в релизной версии. Так что пока C++20 больше модный новодел. И в мире x86_64 тоже работающие системы, которые нужно поддерживать, экстенсивно наращивая фичи, никто не будет стремиться переводить кодовую базу на C++20, даже если появится релизный компилятор с его поддержкой, и даже если система соберётся им без ошибок и предупреждений. Никто не будет брать на себя ответственность за скрытые проблемы/регрессии из-за применения новой версии компилятора. И почему экосистема Эльбруса должна быть моднее и фичастее, чем оная в x86_64? ЕМНИП Эльбрус не для того создавался.

Вопрос тут в другом, а именно: сама сишка и совместимые с ней плюсы - источник багов, какими бы костылями их ни обмазывали. Т.е. основной смысл в развитие всего этого C++ хозяйства - в обеспечении инструментов разработки для создания более современных инструментов разработки. По типу того, как юникс изначально создавался на других системах, которые известны нам только в качестве музейных экспонатов. Только вот само юникс-наследие в виде ляликса и этого давно устаревшего позикса, - разрабатываемого для однопоточных последовательных систем 70х - что-то не спешит отъехать на кладбище.

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

Во первых я написал почти. Во вторых судя по этой таблице https://en.cppreference.com/w/cpp/compiler_support#cpp20 вроде как я не соврал. Далее я написал, что в будущем многие проекты будут для сборки требовать минимум C++17, а ты мне пишешь про перевод кодовой базы на C++20. Такое ощущение, что ты читал мое сообщение по диагонали. Далее тебя вообще занесло в сторону. А когда ждать по твоему C++17 от байкаловцев? К 2025? Основная моя мысль в том, что здесь будет постоянное отставание и тем большее, чем больше будет выходить стандартов и чем сложнее они будут. А портированный софт будет устаревших версий и кишеть проблемами из-за плохой степени отлаженности на не поддерживаемой изначальными разработчиками системы.

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

Глянул табличку. Оказывается, MS уже реализовала модули, о чем я не знал. Обгоняют опенсорс.

seiken ★★★★★
() автор топика

"Entia non sunt multiplicanda praeter necessitatem"(C)

Т.н.«бритва Оккама».

(На самом деле У.Гамильтона.)

C++ нужно только для того, чтобы создать JVM.

Java нужна, чтобы создать Scala.

Которая будет работать в среде JVM.

Которая создана на C++.

Зачем заморачиваться и усложнять себе жизнь всякими «лишними сущностями»(R)?

Мы же не малолетних «П-А»(ТМ) на «Джокере» окучиваем.

Или погроммисты на С++ это «илитка»?

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

о чем ты вообще шепчешь? Настоящий индастриал и прикладной интерпрайз кажется только-только С++11 освоил...

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

Да ежовый пылесос, ну ведь ты даже не потрудился погуглить. Ну вот PyTorch достаточно интерпрайзный?

https://github.com/pytorch/pytorch#from-source

From Source
If you are installing from source, you will need Python 3.6.2 or later and a C++14 compiler. Also, we highly recommend installing an Anaconda environment. You will get a high-quality BLAS library (MKL) and you get controlled dependency versions regardless of your Linux distro.
rumgot ★★★★★
()
Ответ на: комментарий от peregrine

Раст это альтернатива сишке

Тссс. Пока растоадепты не проснулись. :-)

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

https://en.wikipedia.org/wiki/PyTorch

A number of pieces of Deep Learning software are built on top of PyTorch, including Tesla Autopilot[11], Uber's Pyro,[12] HuggingFace's Transformers,[13] PyTorch Lightning[14][15], and Catalyst.[16][17]

Что же тогда должно быть интерпрайзным?

В нем столько же интерпрйзности сколько и в твоем коменте

А сходи-ка ты отлей.

rumgot ★★★★★
()

Давно ты видел рабочие, готовые к «продакшну» бинарные эксплойты на сетевые сервисы? 64-bit ASLR+PIE, fortify source, stack canaries, W^X - уже давно из коробки во всех дистрибутивах. При желании можно добавить shadow stack, SELinux/AppArmor политик, seccomp, 100500 статических анализаторов, fuzzing тесты и грамотное разделение на компоненты. И всё, искать и атаковать переполнения буфера тупо не выгодно экономически.

Сейчас основные вектора атак - недостаточные проверки в ABI/API, XSS в вебе, ошибки конфигурации, ошибки применения криптографии, иногда ядерный код уязвим, очень часто микроконтроллеры без MMU или загрузчики.

Так что безопасность на уровне CPU или ЯП уже особой погоды не делает.

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

Давно ты видел рабочие

тут же не только в уязвимостях дело. Сегфолты вижу постоянно, софт тупо падает в 21м веке.

При желании можно добавить shadow stack, SELinux/AppArmor политик, seccomp, 100500 статических анализаторов, fuzzing тесты и грамотное разделение на компоненты.

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

и грамотное разделение на компоненты

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

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

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

международные стандарты с тобой несогласны

http://docs.cntd.ru/document/1200103242

он же IEC 61508

Таблица C.1 - Рекомендации по конкретным языкам программирования

С/C++ с подмножеством и стандартом кодирования HR (высоко рекомендуемый) для всех уровней безопасности, а безопасная Java с подмножеством и стандартом кодирования - NR (не рекомендуется) для SIL3 и SIL4 (УПБ3 и УПБ4)

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