Здравствуйте, FDSC, Вы писали:
FDS>Например FDS>>>2. Аналогичный запрет (операции ввода-вывода, иные вызовы определённых функций) для всех функций, которые вызываются из данной функции
Всё это в общем-то реализуется через модули, и через Subprogram Contracts
Здравствуйте, varenikAA, Вы писали:
DM>>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
AA>И нет, на днях, изучая кложу, заметил, что жвмоский вариант выполняет AA>
AA>;(reduce + (range 1 1000000))
AA>;
AA>Мгновенно, в отличии от, например CLR-кложи и C#. AA>Понятно, что там использована какая-то жесткая оптимизация, но это же доказывает AA>возможность получения высокопроизводительного кода на трушном языке.
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования. FDS>Есть ли язык программирования, в котором есть следующие фичи: FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>3. Помечать код как неизменяющий состояние программы FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить) FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние). FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Здравствуйте, ·, Вы писали:
FDS>> Есть ли язык программирования, в котором есть следующие фичи: ·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули ·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции ·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
FDS>> 3. Помечать код как неизменяющий состояние программы ·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. ·>А чем просто типы не устраивают? class RedString {private final String content;}
Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
То есть он должен все производные данные пометить также красной строкой.
Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции. ·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны. ·>Все остальные кастомные состояния контролируются кодом публичных методов.
А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
FDS>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода. FDS>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается. FDS>·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли? FDS>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией. FDS>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
Здравствуйте, varenikAA, Вы писали:
AA>А вообще, clojure. AA>Почему? Рич Хикки, автор, в прошлой жизни писал на C++. AA>Но почему-то выбрал JVM. Ибо работает быстро. На уровне мат. операций.
Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>>И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.
DM>Ниши их хорошо пересекаются (почти по всей площади области применения динам. ЯП), сравнивать можно. И когда начинаются такие речи, это признание того, что динамика тормозит, т.е. Рич таки загубил хваленую скорость JVM.
Да, динамика по определению полиморфна, и возможно, это важнее безопасной работы с памятью с точки зрения гибкости ПО и соблюдения DRY.
Сфера применения кложи достаточно четко определена — бизнес-приложения под веб. Аналогично javascript. Ведь никому не придет в голову использовать джс для сложных вычислений.
Его ниша — гибкая и быстрая разработка клиента.
Требуется правильный выбор инструментов. Еще важно, знание особенностей. Если чего-то не знаешь, кажется что это сложно. На деле все по другому.
Ещё пару вопросов насчёт выбора языка программирования.
Есть ли язык программирования, в котором есть следующие фичи:
1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
2. Аналогичный запрет для всех функций, которые вызываются из данной функции
3. Помечать код как неизменяющий состояние программы
4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить)
Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).
5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, FDSC, Вы писали:
FDS>>Ещё пару вопросов насчёт выбора языка программирования. _>Вам шашечки или ехать?
Посмотреть. Вряд ли что-то подобное найдётся в продакшене.
Здравствуйте, FDSC, Вы писали:
FDS>Посмотреть. Вряд ли что-то подобное найдётся в продакшене.
o_O ?
Вам он чтобы поисследовать или всё же что-то реализовывать?
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, FDSC, Вы писали:
FDS>>Посмотреть. Вряд ли что-то подобное найдётся в продакшене. _>o_O ? _>Вам он чтобы поисследовать или всё же что-то реализовывать?
Ну, вы сами видите, язык нормальный порекомендовать не смогли в другой теме.
Я же не на ассемблере должен писать?
Для F-star есть специальный проект Vale/Kremlin (или как-то так, по памяти вспоминаю), для проверки низкоуровневого кода.
Но, честно говоря, не очень его хочется. Плюс, на пробах я его не смог нормально запустить.
Есть UEFI. Вы как раз посоветовали.
Но для UEFI тоже нужен компилятор. Плюс, там сложно.
UEFI я попробовал на ассемблере, чисто строку кода вывести. Но не буду же я на асме всё писать? Очень нехорошо там писать на ассемблере.
На С# есть моя программа — она порядка 30 тыс. строк кода занимает.
Почему я Cosmos и смотрел: он позволяет унаследовать код на C#.
C и C++ для программирования не годятся.
Значит есть следующие варианты.
1. Любой язык использовать, который сможет сгенерировать образ. Но с функциями контроля.
2. Посмотреть на что-то чужое и попробовать написать свой язык, транслирующий всё это в ассемблер.
Опыт небольшой по этому делу есть (даже без ассемблера).
3. Оставить всё как есть и переработать существующий код на C# (но как-то лень)
Здравствуйте, FDSC, Вы писали:
FDS> Есть ли язык программирования, в котором есть следующие фичи:
Да любой интерпретируемый или managed, например java
FDS> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
java.lang.SecurityManager
FDS> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
Запрет на уровне класса.
FDS> 3. Помечать код как неизменяющий состояние программы
Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
FDS> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
А чем просто типы не устраивают? class RedString {private final String content;}
FDS> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
Все остальные кастомные состояния контролируются кодом публичных методов.
Здравствуйте, FDSC, Вы писали:
FDS>3. Помечать код как неизменяющий состояние программы
в dlang.org есть оператор pure.
И по остальному наверняка что-то есть, если в этом есть смысл.
А вообще, clojure.
Почему? Рич Хикки, автор, в прошлой жизни писал на C++.
Но почему-то выбрал JVM. Ибо работает быстро. На уровне мат. операций.
Единственный жирный минус JVM медленный старт. Но если рассматривать его как старт программы.
Но если вспомнить, что JVM виртуальная машина, то все ок. Ведь мы ждем пока Windows/Linux загрузится?
Здравствуйте, FDSC, Вы писали:
FDS>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.
Работая на картели ты можешь попасть под раздачу как от FBI, так и от самих картелей, учти.
Здравствуйте, velkin, Вы писали:
V>Пожалуй это всё, что нужно знать о данной теме.
Мда. Форум совсем скатился.
За совершенно бесполезный во всех отношениях ответ уже оценки ставят. Вы бы лучше в соседней теме поставили бы плюсики kov_serg , ему, почему-то, один я плюсики ставлю.
Хотя он постарался, и подобрал ссылки, которых у меня не было.
Вот скажите, сколько из вас, болтунов, о том, что там по ссылкам, вообще слышали?
А в коде пробовали?
Я — пробовал.
И благодаря его ссылкам у меня получилось то, что раньше я понять не мог нормально (написать хотя бы простейшее UEFI-приложение).
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, FDSC, Вы писали:
FDS>>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно. K>Работая на картели ты можешь попасть под раздачу как от FBI, так и от самих картелей, учти.
Здравствуйте, FDSC, Вы писали:
FDS>Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций. FDS>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода). FDS>Все остальные модули компилятор сам проверяет, что в них ничего такого нет. FDS>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода. FDS>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода. FDS>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается. FDS>Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода. FDS>Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий. FDS>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией. FDS>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых. FDS>Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить. FDS>То есть он должен все производные данные пометить также красной строкой. FDS>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
Много требований и довольно сложных. Насколько мне известно, языков, в достаточной мере им удовлетворяющих, на данный момент нет (мейнстримовых — 100 процентов нет). Здесь нужна какая-то гремучая смесь из effects, typestates и capability-based security. Плюс весьма строгая система типов и продвинутая иммутабельность. Еще надо отметить, что со взаимодействием с внешним кодом придется попрощаться (или пренебречь его корректностью), т.к. соблюсти все инварианты, не находясь в "защищенной области", не удастся. Рефлексия и кодогенерация из текста по тем же причинам тоже отпадают. Возможно, что-то можно изобразить на языках с _очень_ продвинутыми системами типов, но, чтобы писать на них код и разбираться в нем, надо иметь докторскую степень по матану.
В общем, ИМХО, все выглядит нереально. Надо снизить требования или довольствоваться анализом исходных текстов (простой текстовый поиск в самом банальном варианте или продвинутый вариант — компилятор, разбирающий текст и строящий синтаксическое дерево — как это делают IDE).
Здравствуйте, AlexRK, Вы писали:
ARK>Еще надо отметить, что со взаимодействием с внешним кодом придется попрощаться
Тут как раз смысл в том, что
1. Внешнего кода должно быть мало
2. Взаимодействие с ним как раз и должно ограничиваться первым
ARK>В общем, ИМХО, все выглядит нереально. Надо снизить требования или довольствоваться анализом исходных текстов (простой текстовый поиск в самом банальном варианте или продвинутый вариант — компилятор, разбирающий текст и строящий синтаксическое дерево — как это делают IDE).
Для меня тоже выглядит нереально. Поэтому и спросил, вдруг реально? Вдруг я сейчас буду мучится, а потом окажется, что уже есть всё, что надо.
Здравствуйте, FDSC, Вы писали:
FDS>>> Есть ли язык программирования, в котором есть следующие фичи: FDS>·>Да любой интерпретируемый или managed, например java FDS>>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>·>java.lang.SecurityManager FDS>Нет. Насколько я понимаю, это не то. FDS>Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
FDS>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода). FDS>Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
В каком файле? В .exe? Тогда компилятор тут непричём. Ибо .exe после компиляции можно пропатчить, например.
SecurityManager же гарантирует, что если код захочет обратиться к запрещённым операциям, то кинется исключение.
FDS>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
Такое решается управлением зависимостями. Т.е. "эти файлы завият от этих библиотек. Вот списочек библиотек". Тебе останется проверить, что среди этих библиотек нет таких, которые делают ввод-вывод.
FDS>>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>·>Запрет на уровне класса. FDS>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода. FDS>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Это происходит в runtime. Условно говоря, если Class1 (и любой код им используемый) пытается обратиться к java.io.File, то кастомизированный ClassLoader просто кинет ClassNotFound.
FDS>Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода. FDS>Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий. FDS>В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
Поиск по шаблону ясен пень не работает. Особенно в случае если кто-то явно захочет запиахать в код скрытую уязвимость.
Например, в С/С++ даже если в коде нет неправильных действий, можно (случайно или нарочно) запороть буфер и осуществить переход по не тому адресу и оказаться не в безвредной функции вычисления длины строки, а в функции записи файла. Процесс верификации байт-кода в java запрещает это.
FDS>·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли? FDS>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией. FDS>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
Самый простой подход — защитная копия. Ты делаешь копию этого массива и передаёшь в функцию вычисления хеша. Даже если она что-то там поменяет, то пофиг, а к оригинальному массиву у неё просто не будет доступа, т.к. нет его адреса.
Как вариант — делать read-only интерфейс доступа к тем же данным. Т.е. у тебя будет
public int getSize() и public byte getData(int index) — и всё. Функция может только получить размер и взять значение, а что-то поменять — тупо нечем.
FDS>>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>·>А чем просто типы не устраивают? class RedString {private final String content;} FDS>Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить. FDS>То есть он должен все производные данные пометить также красной строкой.
Сделать RedSymbol...
FDS>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
Не делать приведения типов. Делов-то.
FDS>·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны. FDS>·>Все остальные кастомные состояния контролируются кодом публичных методов. FDS>А если я ошибся или не написал контроль? FDS>В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Типы же. Есть и другие механизмы, такие как capabilities, но я не в курсе, если хоть один популярный живой ЯП так умеет.
FDS>Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
Это почему?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
FDS>>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода). FDS>>Все остальные модули компилятор сам проверяет, что в них ничего такого нет. ·>В каком файле? В .exe? Тогда компилятор тут непричём. Ибо .exe после компиляции можно пропатчить, например.
Причём тут exe?
·>SecurityManager же гарантирует, что если код захочет обратиться к запрещённым операциям, то кинется исключение.
К сожалению, Java, в любом случае, не подходит.
Хотя я не очень понял, как там запрещать доступ к любым методам. Там файлы, сокеты есть. Ну я не особо разбирался.
Но это, всё равно, во время выполнения делается. А не во время компиляции.
Но, вообще говоря, интересно.
Забавно, что это в Java нашлось
FDS>>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода. ·>Такое решается управлением зависимостями. Т.е. "эти файлы завият от этих библиотек. Вот списочек библиотек". Тебе останется проверить, что среди этих библиотек нет таких, которые делают ввод-вывод.
Ну кто этот списочек-то составит?
Файлы не зависят от библиотек. Они зависят от других файлов.
FDS>>>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>>·>Запрет на уровне класса. FDS>>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода. FDS>>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается. ·>Это происходит в runtime. Условно говоря, если Class1 (и любой код им используемый) пытается обратиться к java.io.File, то кастомизированный ClassLoader просто кинет ClassNotFound.
Забавно.
FDS>>·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли? FDS>>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией. FDS>>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых. ·>Самый простой подход — защитная копия. Ты делаешь копию этого массива и передаёшь в функцию вычисления хеша. Даже если она что-то там поменяет, то пофиг, а к оригинальному массиву у неё просто не будет доступа, т.к. нет его адреса.
Тут смысл в том, что я не должен об этом думать. И тем более, копировать что-то в runtime.
1. Это загрязняет код
2. Это требует кодирования
·>Как вариант — делать read-only интерфейс доступа к тем же данным. Т.е. у тебя будет ·>public int getSize() и public byte getData(int index) — и всё. Функция может только получить размер и взять значение, а что-то поменять — тупо нечем.
Я понимаю, что так можно сделать. Но мне нужна простая программа. Я же не буду каждые данные копировать и интерфейсы на них писать.
Это слишком сложно.
Кроме этого, функция хеширования должна работать как можно быстрее. А тут на каждый доступ куча проверок.
Как раз хотелось бы в статике проверять.
FDS>>>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>>·>А чем просто типы не устраивают? class RedString {private final String content;} FDS>>Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить. FDS>>То есть он должен все производные данные пометить также красной строкой. ·>Сделать RedSymbol...
Опять же, сделать вручную. Тогда проще сразу написать компилятор языка, который будет делать это автоматически.
FDS>>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать. ·>Не делать приведения типов. Делов-то.
Если я не буду делать приведений типов, то я никогда не смогу записать красную строку в зелёную.
А нужно смочь. И чтобы этих мест было как можно меньше.
FDS>>Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него. ·>Это почему?
Во-первых, мне придётся самому его писать, если я буду делать загрузку через UEFI
Во-вторых, если он уже будет под Windows/Linux, то он не будет обнулять память.
А мне нужно гарантированно обнулять память. Чтобы в оперативной памяти после использования не оставалось никаких данных, которые уже не нужны.
Сборщик мусора это делает только случайно. Без гарантии. Что, если он что-то не перезапишет?
Здравствуйте, FDSC, Вы писали:
FDS>>>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода). FDS>>>Все остальные модули компилятор сам проверяет, что в них ничего такого нет. FDS>·>В каком файле? В .exe? Тогда компилятор тут непричём. Ибо .exe после компиляции можно пропатчить, например. FDS>Причём тут exe?
Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.
FDS>Хотя я не очень понял, как там запрещать доступ к любым методам. Там файлы, сокеты есть. Ну я не особо разбирался.
Там как правило ограничения на уровне классов, а не методов.
FDS>Но это, всё равно, во время выполнения делается. А не во время компиляции. FDS>Но, вообще говоря, интересно. FDS>Забавно, что это в Java нашлось
Ну как бы java изначально проектировали под applets — произвольный код, запускаемый в песочнице браузера, поэтому нужно явно контролировать разрешенные действия.
FDS>>>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода. FDS>·>Такое решается управлением зависимостями. Т.е. "эти файлы завият от этих библиотек. Вот списочек библиотек". Тебе останется проверить, что среди этих библиотек нет таких, которые делают ввод-вывод. FDS>Ну кто этот списочек-то составит?
Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.
FDS>Файлы не зависят от библиотек. Они зависят от других файлов.
В данном случае разница только терминологическая.
FDS>·>Это происходит в runtime. Условно говоря, если Class1 (и любой код им используемый) пытается обратиться к java.io.File, то кастомизированный ClassLoader просто кинет ClassNotFound. FDS>Забавно.
Скриптовые движки тоже умеют. Там определяешь контекст и то что есть в контексте, то работает, остальное — недоступно.
FDS>·>Самый простой подход — защитная копия. Ты делаешь копию этого массива и передаёшь в функцию вычисления хеша. Даже если она что-то там поменяет, то пофиг, а к оригинальному массиву у неё просто не будет доступа, т.к. нет его адреса. FDS>Тут смысл в том, что я не должен об этом думать. И тем более, копировать что-то в runtime. FDS>1. Это загрязняет код FDS>2. Это требует кодирования
Ты должен думать в любом случае чтобы решить, должна ли некая функция менять данные или нет. В зависимости от этого передавать туда соответсвующий тип.
FDS>Как раз хотелось бы в статике проверять.
Это и делает система типов.
FDS>·>Сделать RedSymbol... FDS>Опять же, сделать вручную. Тогда проще сразу написать компилятор языка, который будет делать это автоматически.
Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.
FDS>>>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать. FDS>·>Не делать приведения типов. Делов-то. FDS>Если я не буду делать приведений типов, то я никогда не смогу записать красную строку в зелёную. FDS>А нужно смочь. И чтобы этих мест было как можно меньше.
Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.
FDS>>>Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него. FDS>·>Это почему? FDS>Во-первых, мне придётся самому его писать, если я буду делать загрузку через UEFI
Можно взять какой-нибудь существующий и допилить.
FDS>Во-вторых, если он уже будет под Windows/Linux, то он не будет обнулять память.
По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти. Ясное дело, что ценой будет падение производительности... поэтому так не делают, но думаю допилить сущетсвующий будет не сложно. Лучший компромисс это когда программист явно помечает секретные данные в коде чтобы они чистились явно. Если чистить всё и всегда — будет тормозить.
FDS>А мне нужно гарантированно обнулять память. Чтобы в оперативной памяти после использования не оставалось никаких данных, которые уже не нужны. FDS>Сборщик мусора это делает только случайно. Без гарантии. Что, если он что-то не перезапишет?
А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования.
FDS>Есть ли язык программирования, в котором есть следующие фичи:
FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции
FDS>3. Помечать код как неизменяющий состояние программы
FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить) FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).
FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Эмммм, звучит так, как будто на эти требования можно натянуть стандартное ООП с ФП на любом языке, где есть ООП.
1. Запретить статические функции вообще, "разрешенные" интерфейсы явно передавать в модуль при его инициализации
2. Аналогично. если все функции — методы, то без экземпляра ты их не вызовешь
3. Я знаю два способа — const в плюсах и вообще (по-возможности) не иметь методов, изменяющих состояние программы. Т.е. все структуры данных иммутабельные, все "неконстантные" методы возвращают копию структуры данных с изменениями. Это надо смотреть в сторону ФП языков с монадами.
4. Наследование? Либо отказаться от неявного приведения и всегда приводить явно через набор функций-конверторов.
5. Имхо, лучше просто писать код так, чтобы контролировать состояние объектов было не нужно. Умные указатели в плюсах, язык с GC, правильно реализованная идиома владения. Вручную контролировать жизненный цикл объектов сложно, проще изменить архитектуру.
И вообще — статический стейт, статические синглтоны — это зло. Лучше использовать DI и самому управлять инициализацией.
·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.
Это уже вопрос рантайма. Причём может решаться частично организационными методами.
>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.
Нет. Так дело не пойдёт.
Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.
Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может.
Важно то, чтобы можно было эти все функции отследить.
·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.
Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API.
Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
·>Можно взять какой-нибудь существующий и допилить.
Обычно проще написать самому. Слишком технологии разные. Ну или Cosmos брать.
·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти.
Да. Верно. Либо сборщик мусора, либо счётчик ссылок, либо специализированная система выделения памяти.
> Ясное дело, что ценой будет падение производительности... поэтому так не делают, но думаю допилить сущетсвующий будет не сложно. Лучший компромисс это когда программист явно помечает секретные данные в коде чтобы они чистились явно. Если чистить всё и всегда — будет тормозить.
В данном случае все данные предполагаются секретными.
·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
В данном случае предполагается гарантия при правильной работе программы, хотя бы.
При неправильной ничто никогда не гарантирует.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, FDSC, Вы писали:
FDS>>3. Помечать код как неизменяющий состояние программы
scf>3. Я знаю два способа — const в плюсах и вообще (по-возможности) не иметь методов, изменяющих состояние программы. Т.е. все структуры данных иммутабельные, все "неконстантные" методы возвращают копию структуры данных с изменениями. Это надо смотреть в сторону ФП языков с монадами.
const — не годится. Массив в плюсах const не пометишь.
ФП годятся. Но там тоже проблема будет с массивами. Ибо обработка идёт изменяющихся данных.
Здравствуйте, FDSC, Вы писали:
FDS>Ну, вы сами видите, язык нормальный порекомендовать не смогли в другой теме. FDS>Я же не на ассемблере должен писать?
Не ну если очень хочется то например вот https://github.com/swift-embedded/swift-embedded
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, FDSC, Вы писали:
FDS>>Ну, вы сами видите, язык нормальный порекомендовать не смогли в другой теме. FDS>>Я же не на ассемблере должен писать? _>Не ну если очень хочется то например вот https://github.com/swift-embedded/swift-embedded
Сколько всяких штук Жесть просто
Но там для конкретных микроконтроллеров, я так понял.
Это, по сути, надо флешку перепрограммировать... чего-то совсем страшное
Я даже боюсь начинать смотреть. У меня и аппаратуры такой нет
Здравствуйте, FDSC, Вы писали:
FDS>·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором. FDS>Это уже вопрос рантайма. Причём может решаться частично организационными методами.
Вряд ли... Хотя если проект из одного человека, то может и сработать.
>>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять. FDS>Нет. Так дело не пойдёт. FDS>Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?
FDS>·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту. FDS>Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может. FDS>Важно то, чтобы можно было эти все функции отследить.
Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.
FDS>·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП. FDS>Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API. FDS>Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило.
FDS>·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти. FDS>Да. Верно. Либо сборщик мусора, либо счётчик ссылок,
Счётчик ссылок это тривиальный вариант реализации сборщика мусора.
FDS>либо специализированная система выделения памяти.
Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.
FDS>·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь. FDS>В данном случае предполагается гарантия при правильной работе программы, хотя бы. FDS>При неправильной ничто никогда не гарантирует.
Ну тогда просто — при завершении процесса занулить всю память. Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?
Просмотрит все вызываемые функции. Они не вызывают функции, которые пишут в файл или в поток ввода-вывода, не вызывают прерываний и не пишут в порты ввода-вывода.
>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.
Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно.
·>Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило.
Может быть вызов через рефлекшн и непосредственно в коде с полной квалификацией (в C#, по крайней мере).
Ну, опять же, в Java может и не получится. В других языках это не так просто.
Ну и потом, там могут быть алиасы какие-нибудь и т.п.
·>Счётчик ссылок это тривиальный вариант реализации сборщика мусора.
Ну это не сборщик мусора, это немного другое. Но да.
FDS>>либо специализированная система выделения памяти. ·>Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.
Систем освобождения памяти не бывает Только выделения.
·>Ну тогда просто — при завершении процесса занулить всю память.
не, это слишком долго. Вдруг процесс, всё же, упадёт?
> Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.
О таким API мне неизвестно. И в файл подкачки вполне утекает всё.
Чтобы не утекало, есть функция VirtualLock в WinAPI
Здравствуйте, Слава, Вы писали:
FDS>>Есть ли язык программирования, в котором есть следующие фичи:
С>Ада, Ада/SPARK
Что-то я там такого не помню...
может плохо смотрел. Не подскажете часть операций?
Например FDS>>2. Аналогичный запрет (операции ввода-вывода, иные вызовы определённых функций) для всех функций, которые вызываются из данной функции
FDS>>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Здравствуйте, D. Mon, Вы писали:
FDS>>Ещё пару вопросов насчёт выбора языка программирования. FDS>>Есть ли язык программирования, в котором есть следующие фичи: FDS>>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>>2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>>3. Помечать код как неизменяющий состояние программы FDS>>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
DM>Pony уже смотрел? DM>https://www.ponylang.io/discover/#what-is-pony
Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
Здравствуйте, FDSC, Вы писали:
FDS>Сколько всяких штук Жесть просто
Без этого никак.
FDS>Но там для конкретных микроконтроллеров, я так понял. FDS>Это, по сути, надо флешку перепрограммировать... чего-то совсем страшное FDS>Я даже боюсь начинать смотреть. У меня и аппаратуры такой нет
Не тут всё от задачи зависит. Если что бы ехать C/C++ или доступные скриптовые языки
Если хочется странного то поле не паханное:
Swift компилируются при помощи LLVM так что можете при желании куда угодно компилировать
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, FDSC, Вы писали:
DM>>>https://www.ponylang.io/discover/#what-is-pony
FDS>>Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
DM>Не только, там как раз через capabilities можно хорошо управлять тем, чтобы какие-то функции не могли работать с файлами и пр.
Здравствуйте, FDSC, Вы писали:
DM>>>>https://www.ponylang.io/discover/#what-is-pony
FDS>>>Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
DM>>Не только, там как раз через capabilities можно хорошо управлять тем, чтобы какие-то функции не могли работать с файлами и пр.
FDS>Не нашёл
Здравствуйте, FDSC, Вы писали:
FDS>·>На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы? FDS>Просмотрит все вызываемые функции. Они не вызывают функции, которые пишут в файл или в поток ввода-вывода, не вызывают прерываний и не пишут в порты ввода-вывода.
Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл?
>>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё. FDS>Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно.
А если не все, а только 95% функций? А если 5%? Где границу-то ставить?
FDS>·>Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило. FDS>Может быть вызов через рефлекшн и непосредственно в коде с полной квалификацией (в C#, по крайней мере). FDS>Ну, опять же, в Java может и не получится. В других языках это не так просто.
В java это контролируется. Чтобы загрузить класс, тебе нужно сделать classLoader.forName("someClass") — а этот сам classLoader контролируется и может выдавать ClassNotFound. Т.е. коду просто не будет доступа к классам которые ему не дают.
FDS>Ну и потом, там могут быть алиасы какие-нибудь и т.п.
Нет никаких альясов. Есть только имена классов.
FDS>>>либо специализированная система выделения памяти. FDS>·>Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять. FDS>Систем освобождения памяти не бывает Только выделения.
Вот и я о том.
FDS>·>Ну тогда просто — при завершении процесса занулить всю память. FDS>не, это слишком долго.
Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе.
FDS>Вдруг процесс, всё же, упадёт?
Ты уж определись...
>> Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится. FDS>О таким API мне неизвестно. И в файл подкачки вполне утекает всё. FDS>Чтобы не утекало, есть функция VirtualLock в WinAPI
Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать.
И уже не говоря про всякие железные уязвимости типа row hammer.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл?
Программист явно укажет функции, которые могут писать в файл.
>>>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё. FDS>>Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно. ·>А если не все, а только 95% функций? А если 5%? Где границу-то ставить?
Допустим у нас проект на 20 000 строк кода. 1000 тысяча строк кода может делать всё что угодно. Согласись, есть разница, сколько проверять?
·>Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе.
Гарантированно быстрее вообще не делать.
Обнуление памяти при завершении процесса — это слишком рискованная операция. Обнулять всё должно очень и очень быстро.
FDS>>Вдруг процесс, всё же, упадёт? ·>Ты уж определись...
Одно дело при краше не очистится память и мы не могли очистить, а другое дело, когда при краше можно очистить память, а мы всё равно не очистили.
·>Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать.
Что-то такое
pwdAddress = VirtualAlloc(0, len, 0x1000 | 0x2000 | 0x00400000, 0x04);
·>И уже не говоря про всякие железные уязвимости типа row hammer.
Железные уязвимости оставим железу.
Защититься от всего программными способами невозможно
Здравствуйте, Слава, Вы писали:
С>Я не думаю, что вы найдёте более подходящий язык за исключением какой-нибудь экзотики вроде уже упомянутого F*
А как насчёт типизационных меток?
Не подскажете, что лучше почитать по Аде, чтобы было понятно и, желательно, на русском?
А то очень тяжело понимать, что там происходит в GNAT и в меню SPARK
Здравствуйте, FDSC, Вы писали:
FDS>·>Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл? FDS>Программист явно укажет функции, которые могут писать в файл.
А calculateHash берёт ссылку на функцию, скажем, для преобразования charset. Каким образом ты объяснишь, что этот преобразователь не должен использовать файловый API? А если вдруг таблицу charset придётся таки в некоторых случаях читать из файла?
FDS>·>А если не все, а только 95% функций? А если 5%? Где границу-то ставить? FDS>Допустим у нас проект на 20 000 строк кода. 1000 тысяча строк кода может делать всё что угодно. Согласись, есть разница, сколько проверять?
Разница слабо коррелирует с кол-вом строк в общем случае.
FDS>·>Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе. FDS>Гарантированно быстрее вообще не делать. FDS>Обнуление памяти при завершении процесса — это слишком рискованная операция. Обнулять всё должно очень и очень быстро.
Так это зависит от программы. Если прога держит большое кол-во в памяти в виде развесистой структуры, то может получиться гораздо быстрее занулить всё подряд, чем аккуратно вызывать деструкторы-занулители в правильном порядке.
FDS>>>Вдруг процесс, всё же, упадёт? FDS>·>Ты уж определись... FDS>Одно дело при краше не очистится память и мы не могли очистить, а другое дело, когда при краше можно очистить память, а мы всё равно не очистили.
С т.з. секьюрити невелика разница. Хакеры могут например специально убивать прогу в точно выбранные моменты времени.
FDS>·>Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать. FDS>Что-то такое FDS>pwdAddress = VirtualAlloc(0, len, 0x1000 | 0x2000 | 0x00400000, 0x04);
И что эти цифири значат? Ты цитаты из док давай.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, FDSC, Вы писали:
FDS>>·>Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл? FDS>>Программист явно укажет функции, которые могут писать в файл. ·>А calculateHash берёт ссылку на функцию, скажем, для преобразования charset. Каким образом ты объяснишь, что этот преобразователь не должен использовать файловый API? А если вдруг таблицу charset придётся таки в некоторых случаях читать из файла?
Ну вот компилятор должен уметь это делать.
Читать в некоторых случаях прийтись не должно. Если должно, таблица будет передаваться из другого места.
FDS>>·>А если не все, а только 95% функций? А если 5%? Где границу-то ставить? FDS>>Допустим у нас проект на 20 000 строк кода. 1000 тысяча строк кода может делать всё что угодно. Согласись, есть разница, сколько проверять? ·>Разница слабо коррелирует с кол-вом строк в общем случае.
Что значит слабо коррелирует?
Проверять 100% строк или только 95?
FDS>>·>Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе. FDS>>Гарантированно быстрее вообще не делать. FDS>>Обнуление памяти при завершении процесса — это слишком рискованная операция. Обнулять всё должно очень и очень быстро. ·>Так это зависит от программы. Если прога держит большое кол-во в памяти в виде развесистой структуры, то может получиться гораздо быстрее занулить всё подряд, чем аккуратно вызывать деструкторы-занулители в правильном порядке.
Неважно, как быстро вы сделаете это в плане времени зануления. Важно, как быстро вы сделаете это в плане времени существования объектов в памяти.
·>С т.з. секьюрити невелика разница. Хакеры могут например специально убивать прогу в точно выбранные моменты времени.
Могут. Но разница есть и, поверьте, она достаточно существенная.
FDS>>pwdAddress = VirtualAlloc(0, len, 0x1000 | 0x2000 | 0x00400000, 0x04); ·>И что эти цифири значат? Ты цитаты из док давай.
Да смысла нет. Просто она может блокировать страницу в физической памяти.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>>А вообще, clojure. AA>>Почему? Рич Хикки, автор, в прошлой жизни писал на C++. AA>>Но почему-то выбрал JVM. Ибо работает быстро. На уровне мат. операций.
DM>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>>А вообще, clojure. AA>>Почему? Рич Хикки, автор, в прошлой жизни писал на C++. AA>>Но почему-то выбрал JVM. Ибо работает быстро. На уровне мат. операций.
DM>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
И нет, на днях, изучая кложу, заметил, что жвмоский вариант выполняет
(reduce + (range 1 1000000))
Мгновенно, в отличии от, например CLR-кложи и C#.
Понятно, что там использована какая-то жесткая оптимизация, но это же доказывает
возможность получения высокопроизводительного кода на трушном языке.
Решающим фактором, конечно, является квалификация программиста, но все же.
FDS>За совершенно бесполезный во всех отношениях ответ FDS>Вот скажите, сколько из вас, болтунов, о том, что там по ссылкам, вообще слышали? FDS>А вам, болтунам, не спасибо.
И менно поэтому за абсолютно полезный во всех отношениях ответ и поставлены оценки. Троллей тут не любят.
Здравствуйте, Mamut, Вы писали:
FDS>>За совершенно бесполезный во всех отношениях ответ FDS>>Вот скажите, сколько из вас, болтунов, о том, что там по ссылкам, вообще слышали? FDS>>А вам, болтунам, не спасибо.
M>И менно поэтому за абсолютно полезный во всех отношениях ответ и поставлены оценки. Троллей тут не любят.
Я, вообще-то, с вполне серьёзной темой спрашиваю и для вполне конкретной вещи.
А то, что вам не хватает квалификации это понять — это ваши проблемы.
Тут пол форума троллинг. Как пришёл человек с практическим вопросом — два человека только понять могут, что человек хочет.
Дожили
FDS>И да, я не точно знаю чего хочу. Я же выбираю инструмент из существующих бесплатных. FDS>Разумеется, я не знаю, чего хочу. Если бы знал, не спрашивал бы.
Тогда это не выборы, а бесполезные хотелки на уровне троллинга. Что видно по уровню твоей реакции на любые предложения.
Здравствуйте, Mamut, Вы писали:
M>Тогда это не выборы, а бесполезные хотелки на уровне троллинга. Что видно по уровню твоей реакции на любые предложения.
Оба предложения, которые здесь в теме были озвучены (Pony и Ada), были мною посмотрены.
В другой теме для анализа предложенных ссылок по одной из них я написал почти 300 строк ассемблерного кода.
На какое из этих предложений я отреагировал не так?
FDS>>И что? Это не предложение. FDS>>Что Haskell умеет делать? Функции без побочных эффектов?
M>Он умеет делать все то, что я оставил в комментарии по ссылке
И?
Это умеет делать любой ФП.
И я вовсе не просил мне посоветовать ФП.
Я просил то, что указал в начальном сообщении.
А дальше спорил с совсем другим человеком по мотивам возможности к этому приблизится и тому, как это можно сделать в обычных языках.
Ничего дельного по тому, что я просил, ты не предложил.
Здесь было два предложения: Pony и Ada. Оба интересные. Они бьют хотя бы один из пунктов того, что я просил.
В общем, я не вижу смысла продолжать с тобой общение.
FDS>>Это не предложение. Это детский сад с выкрикиванием любимых слов без повода.
M>И ты еще удивляешься, что мы тебя несерьезно воспринимаем
???
Тебе не кажется, что логика в твоих словах полностью отсутствует?
M>>Он умеет делать все то, что я оставил в комментарии по ссылке
FDS>И? FDS>Это умеет делать любой ФП.
Нет, не любой
FDS>И я вовсе не просил мне посоветовать ФП.
Все, что тебе советуют, ты отметаешь, как капризный ребенок.
M>>И ты еще удивляешься, что мы тебя несерьезно воспринимаем FDS>???
Что тебе непонятно? Вот что ты пишешь:
FDS>Вот скажите, сколько из вас, болтунов, о том, что там по ссылкам, вообще слышали? FDS>Это не предложение. Это детский сад с выкрикиванием любимых слов без повода. FDS>Тебе не кажется, что логика в твоих словах полностью отсутствует?
Здравствуйте, Mamut, Вы писали:
M>>>Он умеет делать все то, что я оставил в комментарии по ссылке
FDS>>И? FDS>>Это умеет делать любой ФП.
M>Нет, не любой
ok. Тогда, пожалуйста, можете сказать, что именно конкретно из верхнего сообщения темы он может делать и какими методами.
Ещё лучше, если будет какая-то понятная документация.
По Haskell я её понятную не вижу.
Возможно, потому что плохо искал. Ну и потому, что мне этот язык всё равно не подходит — это чистый ФП (если, конечно, речь идёт о чистом Haskell). Для моих задач чистый ФП — это чуть меньшее самоубийство, чем чистый C++
Но если дадите более подробно, я посмотрю.
Когда-то я пробовал изучать этот язык, но не нашёл понятного руководства, где было бы хорошо расписаны его достоинства.
FDS>>И я вовсе не просил мне посоветовать ФП.
M>Все, что тебе советуют, ты отметаешь, как капризный ребенок.
Pony, Ada, UEFI. Что из этого я отмёл?
Это "всё, что мне посоветовали" из того, что я просил.
Я всё это не отмёл. Я всё это посмотрел. Установил GNAT, разобрался немного в синтаксисе и в модуле SPARK. Удивился возможностям верификации, которые, как я думал, есть только в F* .
Pony тоже посмотрел.
По UEFI попрограммировал. Собираюсь дальше это использовать.
Что именно и конкретно я отмёл?
M>>>И ты еще удивляешься, что мы тебя несерьезно воспринимаем FDS>>???
M>Что тебе непонятно? Вот что ты пишешь:
FDS>>Вот скажите, сколько из вас, болтунов, о том, что там по ссылкам, вообще слышали? FDS>>Это не предложение. Это детский сад с выкрикиванием любимых слов без повода. FDS>>Тебе не кажется, что логика в твоих словах полностью отсутствует?
M>Как к тебе еще относиться?
Как то, что процитировано, связано с тем, как ко мне относится.
FDS>Это "всё, что мне посоветовали" из того, что я просил.
«мне этот язык всё равно не подходит — это чистый ФП»
«Но для UEFI тоже нужен компилятор. Плюс, там сложно.»
«C и C++ для программирования не годятся.»
M>>Как к тебе еще относиться? FDS>Как то, что процитировано, связано с тем, как ко мне относится. FDS>Болтуны и есть болтуны.
Ага, ага «это не я такой, это вы такие». Советую перечитать правила поведения на этом форуме.
Здравствуйте, Mamut, Вы писали:
FDS>>Это "всё, что мне посоветовали" из того, что я просил.
M>«мне этот язык всё равно не подходит — это чистый ФП»
Ну да. И что?
Дак вы мне посоветуете что-нибудь почитать?
Или так и сбежите поджав хвост?
M>«Но для UEFI тоже нужен компилятор. Плюс, там сложно.»
Да, сложно. Но, как я уже сказал, я с ним уже поработал. И, видимо, буду работать именно по этому пути.
M>«C и C++ для программирования не годятся.» M>
Они и не годятся. И что?
Как C и C++ связаны с теми требованиями, которые я просил?
Это не предложения, удовлетворяющие заявленным требованиям. Это просто привычные для вас языки, но не удовлетворяющие ни требованиям из первой ветки, ни требованиям из второй ветки.
Я не просил мне посоветовать любой язык программирования. Я просил конкретных советов. И если вы не можете посоветовать, нет смысла обижаться, что ваши плохие советы отвергаются.
M>Ага, ага «это не я такой, это вы такие». Советую перечитать правила поведения на этом форуме.
Ну перечитайте. Флуд тут развели вы.
Причём ничего не посоветовав.
Специально для тебя. Пункт пятый обязательных правил
Не допускается проявление грубого или неуважительного отношения к другим участникам форума. Оскорблять и обзывать собеседника, ставить под сомнение его профессиональную квалификацию, придираться к его нику, указывать на орфографические и синтаксические ошибки и т. д. запрещается.
FDS>>Ну перечитайте.
M>Специально для тебя. Пункт пятый обязательных правил
M>
M>Не допускается проявление грубого или неуважительного отношения к другим участникам форума. Оскорблять и обзывать собеседника, ставить под сомнение его профессиональную квалификацию, придираться к его нику, указывать на орфографические и синтаксические ошибки и т. д. запрещается.
Ну вот именно это вы и нарушили. Точнее, нарушил некий другой человек, а вы его защищаете.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
DM>>>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
AA>>И нет, на днях, изучая кложу, заметил, что жвмоский вариант выполняет AA>>
AA>;>(reduce + (range 1 1000000))
AA>;>
AA>>Мгновенно, в отличии от, например CLR-кложи и C#. AA>>Понятно, что там использована какая-то жесткая оптимизация, но это же доказывает AA>>возможность получения высокопроизводительного кода на трушном языке.
DM>Ну возьми чуточку сложнее пример, даже не нужно сильно сложнее, и сравни с другими языками. См. срачи тут, например: DM>https://tonsky.livejournal.com/322036.html DM>https://tonsky.livejournal.com/322450.html
DM>(человек несколько лет профессионально на кложе писал, и зае устал)
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
DM>>>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
AA>>И нет, на днях, изучая кложу, заметил, что жвмоский вариант выполняет AA>>
AA>;>(reduce + (range 1 1000000))
AA>;>
AA>>Мгновенно, в отличии от, например CLR-кложи и C#. AA>>Понятно, что там использована какая-то жесткая оптимизация, но это же доказывает AA>>возможность получения высокопроизводительного кода на трушном языке.
DM>Ну возьми чуточку сложнее пример, даже не нужно сильно сложнее, и сравни с другими языками. См. срачи тут, например: DM>https://tonsky.livejournal.com/322036.html DM>https://tonsky.livejournal.com/322450.html
DM>(человек несколько лет профессионально на кложе писал, и зае устал)
И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.
Здравствуйте, varenikAA, Вы писали:
AA>И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.
Ниши их хорошо пересекаются (почти по всей площади области применения динам. ЯП), сравнивать можно. И когда начинаются такие речи, это признание того, что динамика тормозит, т.е. Рич таки загубил хваленую скорость JVM.
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования.
FDS>Есть ли язык программирования, в котором есть следующие фичи:
Что характерно, юольше всего анализаторв следано для C/C++ — вероятно, потому, что они там нужнее. На втором месте Java, полагаю потому, что легче делать благодаря четкой спецификации.
Так что возьмите любой язык, который вам симпатичен, и проверьте анализаторы для него — может, они уже умеют делать все, что вам нужно. А если нет, то попытайтесь доработать.
Здравствуйте, FDSC, Вы писали:
FDS>Тут пол форума троллинг. Как пришёл человек с практическим вопросом — два человека только понять могут, что человек хочет. FDS>Дожили
1. Вот это вот всё, про то, что тут троллинг, а что нет -- само по себе лютый офтопик, да и троллинг тоже
2. Вовсе и не два. Просто мало кто может дельный совет дать. Возможно есть какие-то хитрые DSL с такими свойствами, или на чём-то вроде ады или ограниченных чем-то плюсов можно такой слабать…
3. По поводу ограничения доступа к API. Я бы вообще разделил программу на два процесса : внешний и внутренний. И всё подозрительное API звать из внешнего, а 95% кода пусть во внутреннем крутятся, у которого можно и права задавить и средствами OS или анализа зависимостей, проверить, что ничего подозрительного из него не зовут.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>1. Вот это вот всё, про то, что тут троллинг, а что нет -- само по себе лютый офтопик, да и троллинг тоже
Согласен
E>3. По поводу ограничения доступа к API. Я бы вообще разделил программу на два процесса : внешний и внутренний. И всё подозрительное API звать из внешнего, а 95% кода пусть во внутреннем крутятся, у которого можно и права задавить и средствами OS или анализа зависимостей, проверить, что ничего подозрительного из него не зовут.
К сожалению, это только вариант подавления некоторых API типа файлового ввода-вывода.
Там всё гораздо сложнее, чем я ранее в этой теме сформулировал.
Я даже начал собственное расширение ассемблера писать. Но что-то сложновато, староват я, запала уже не хватает.
Похоже, не напишу я это .
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования.
Можно посмотреть на LUA.
FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
Есть.
FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции
Их тоже можно запретить.
FDS>3. Помечать код как неизменяющий состояние программы
Непонятно.
FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
Пометить можно, но в динамике.
FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).
Это можно.
FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Только если объект есть — объекта нет.
FDS>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.
LUA — классический встраиваемый язык, простой и надежный.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
FDS>К сожалению, это только вариант подавления некоторых API типа файлового ввода-вывода. FDS>Там всё гораздо сложнее, чем я ранее в этой теме сформулировал.
Ну так сформулируй подробнее...
FDS>Я даже начал собственное расширение ассемблера писать.
Зачем расширение ассемблера писать, когда есть аппаратная поддержка отладчиков?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
FDS>Есть ли язык программирования, в котором есть следующие фичи: FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>3. Помечать код как неизменяющий состояние программы
FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить) FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).
FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
А можете поподробнее, с примерами?
Ну невозможность вызова определенных функций примерно понятно. Но как это задавать? Список разрешенных функций, список запрещенных функций, еще как-то?
Помечать код как изменяющий тоже понятно.
А что за дополнительные метки (п.4)? Можете дать use case? По описанию интуитивно кажется что что-то весьма интересное, но описание уж больно расплывчатое
Пункт 5 это что-то вроде typestate, которое хотели сделать в Rust но не сложилось?
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования.
FDS>Есть ли язык программирования, в котором есть следующие фичи:
Помоему java подходит как нельзя лучше.
FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции
Каждой такой функии выдать свою permission, для вызываемого кода выдавать полномочи -> остальное заблокируется.
Можно сделать свой SecurityManager и в момент проверки доступа делать какие-нибудь хитрые вещи типа прверки стека функций, кто кого вызвал и прочее.
FDS>3. Помечать код как неизменяющий состояние программы
Я думаю это возможно сделать через анотации, если данные и те кто их изменяет помечены разными аннотациями.
что-то вроде этого: https://www.baeldung.com/checker-framework
FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
Аннотации + классы.
FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить)
наследование+агрегация
FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).
Аннотации.
FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
инициализирован-выполнились стати методы на классе и блоки кода до конструктора.
объект в работе — конструктор был вызван
объект завершил работу — объект попал в очередь на удаление тобишь в ReferenceQueue.
бъект подвергся деструкции — обхект пооностью не доступен и память его очищена GC
FDS>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.
Посмотри МультиОберон.
Люди как раз занимались реализацией ограничений в компиляторе.
Типа атрибутов. Например: не использовать динамическую память в данном модуле/проекте.
И любая попытка написать new приводит к ошибке компиляции.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
rfq>Нет такого языка программирования и не будет в обозримом будущем.
Я бы не был так категоричен. Есть люди, которые озабочены именно тем, чтобы разработать ограничительный компилятор.
Чтобы можно было в проекте запрещать использовать некоторые возможности языка.
Например, запретить использовать динамическую память.
Это не простые фантазии, а реальная потребность при разработке для разных микроконтроллеров.
Но писать новый компилятор для каждого нового — не хотят.
Сделали МультиОберон — с подкладкой LLVM на данный момент.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
