Ещё пару вопросов насчёт выбора языка программирования.
Есть ли язык программирования, в котором есть следующие фичи:
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. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
Все остальные кастомные состояния контролируются кодом публичных методов.
Здравствуйте, ·, Вы писали:
FDS>> Есть ли язык программирования, в котором есть следующие фичи: ·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули ·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции ·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
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 загрузится?
FDS>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода. FDS>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается. FDS>·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли? FDS>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией. FDS>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
Здравствуйте, 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 брать.
·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти.
Да. Верно. Либо сборщик мусора, либо счётчик ссылок, либо специализированная система выделения памяти.
> Ясное дело, что ценой будет падение производительности... поэтому так не делают, но думаю допилить сущетсвующий будет не сложно. Лучший компромисс это когда программист явно помечает секретные данные в коде чтобы они чистились явно. Если чистить всё и всегда — будет тормозить.
В данном случае все данные предполагаются секретными.
·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.
В данном случае предполагается гарантия при правильной работе программы, хотя бы.
При неправильной ничто никогда не гарантирует.
