ПО, ЭВМ и АСУ из Таможенного Союза

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



seL4

Сообщений 1 страница 13 из 13

1

https://habr.com/ru/post/437406/

"Разработка дизайна и кода seL4 заняла два человеко-года."

Отредактировано Лис (2019-03-25 22:32:03)

0

2

Хорошо бы вкратце давать пояснения что расположено по ссылке, в частности неясно что такое "seL4".

0

3

atzx написал(а):

что такое "seL4".

[html]<a href="https://ru.wikipedia.org/wiki/L4_(микроядро)">https://ru.wikipedia.org/wiki/L4_(микроядро)</a>[/html]

0

4

seL4: В 2006 году началась разработка микроядра третьего поколения, получившего название «seL4»

L4: Во время работы над микроядром L3 Йохен Лидтке обнаружил недостатки микроядра Mach. Желая повысить производительность, Лидтке стал составлять код нового микроядра на языке ассемблера с использованием особенностей архитектуры процессоров Intel i386. Новое микроядро получило название «L4» (от «4‑я работа Liedtke»).

В 1993 году реализация микроядра L4 была закончена. Компонент IPC оказался в 20 раз быстрее IPC из микроядра Mach.

В начале 2012 года было продано более 1.5 миллиарда устройств, оснащённых реализацией микроядра L4. Большинство из этих устройств содержали микросхемы, реализующие беспроводные модемы (англ. wireless modem) и выпущенные фирмой «Qualcomm».

Отредактировано atzx (2019-06-22 19:23:18)

0

5

БудДену ответ на его вопрос:
https://sel4.systems/Info/FAQ/proof.pml

тебе нужен кусок со слов "What the proof implies", там написано:
формальное доказательство корректности кода гарантирует отсутствие следующих классов проблем... (и т.д.)

Отредактировано Лис (2019-07-10 15:55:08)

0

6

Там перечислено:

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

Ну, это в общем-то достаточно негусто и не гарантирует неуязвимость данной системы. При этом переполнения буфера можно исключить полностью за счёт выбора другого ЯП, разыменование нулевых указателей - это один из возможных способов сигнализировать об ошибке. Если мы сигнализируем об ошибке иным способом, то это не делает нашу программу абсолютно надёжной. Например, можно вместо простого a = *some_pointer писать

Код:
if (!some_pointer) {
  exit(1)
};
a = *some_pointer;

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

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

Отсутствие числовых переполнений - это действительно круто. Неопределённое поведение - может быть, имеет смысл, хотя я не знаю. Тут для начала нужно понять, какие варианты неопределённого поведения возникли из исторических причин, а какие объективно нужны. Например, состояние гонки - это объективная проблема. А вот использование неинициализированной переменной - это исключительно особенность Си, которая есть не во всех языках.

Соответственно, половина или больше классов ошибок, отсутствие которых они доказали, вообще исчезает при выборе более нормального ЯП.

Отредактировано БудДен (2019-07-10 16:11:08)

0

7

А что полезного умеет делать эта система, где её можно применять?

0

8

тебе википедию процитировать?
"В начале 2012 года было продано более 1.5 миллиарда устройств, оснащённых реализацией микроядра L4"

0

9

БудДен написал(а):

Например, можно вместо простого a = *some_pointer писать

Код:
if (!some_pointer) {
  exit(1)
};
a = *some_pointer;

Нельзя у вас будет неопределённое поведение.

0

10

Куда можно "выйти" из ядра - тоже ещё тот вопрос. В синий экран?

Но это, конечно, если к словам придираться. Так-то понятно, что там return должно быть написано, ну или, страшно сказать, goto.

Отредактировано Лис (2019-07-10 18:32:37)

0

11

Лис написал(а):

Куда можно "выйти" из ядра - тоже ещё тот вопрос. В синий экран?

Это зависит от требований к ядру. Одни никуда не выходят. Другие корректно выключают аппаратуру.

0

12

БудДен написал(а):

Ну, это в общем-то достаточно негусто и не гарантирует неуязвимость данной системы.

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

Основные проблемы ядра это DeadLock при переключении задач и их планировании.
Есть ещё проблема с передачи параметров в ядро там тоже DeadLock может быть.
И переполнение стека.
Переполнение хендлов и утечка ресурсов.

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

0

13

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

Какие именно?

0