Лекция: Что такое критический момент времени (critical instant) в контексте анализа
Время завершения этой работы называется critical instant задачи Ti. Что бы определить все ли работы встречают свои дедлайны, нам необходимо проследить что бы работа в Ti завершилась в critical instant
планируемости задач по RMA и какую роль он играет в доказательстве возможности
планирования?
ЧМА Теорема 1A Для набора N независимых периодических задач, где Ci, Ti, и Bi, i = 1,2… N,, являются временем выполнения, периодом и временем блокировки в самом плохом случае, соответственно, а критический срок выполнения равняется периоду задачи, задачи диспетчируемы согласно ЧМА, если следующее условие выполняется:
Более простое достаточное условие можно получить из вышеупомянутого набора неравенств. Его преимущество состоит в том, что оно содержит только одно, а не N неравенств.
ЧМА Теорема 2A
Для набора N независимых периодических задач, где Ci, Ti, и Bi, i= 1,2,.... N, являются временем выполнения, периодом, и временем блокировки в наихудшем случае соответственно, а критический срок выполнения равняется периоду задачи, задачи диспетчируемы согласно ЧМА, если следующее условие выполняется:
,
где минимум рассчитан как (k, l) Wi, и
Обратите внимание, это только достаточное условие, потому что значения Bi представляют собой время блокировки в самом плохом случае. Практически, некоторые из этих неравенств не могут быть выполнены, а набор задач может быть все еще диспетчируем, потому что фактические времена блокирования короче. Эмпирическое правило, данное в секции “Необходимое и достаточное условие для диспетчеризации с помощью ЧМА ” может быть использовано, если включить в него Bi.
171. Как называется международный стандарт, которому соответствует ГОСТ Р 15408?
Национальный стандарт безопасности ГОСТ/ИСО МЭК 15408 «Общие критерии оценки безопасности информационных технологий»
В 1999 г. Международная Организация по Стандартизации (ISO) приняла международный стандарт ISO 15408 под названием Общие критерии оценки безопасности ИТ (Common Criteria for Information Technology Security Evaluation или сокращенно — Common Criteria). Внушительных размеров тома Common Criteria содержат обобщенное формализованное представление знаний и опыта, накопленного в области обеспечения информационной безопасности на протяжении десятилетий.
172. Какой семитомный стандарт определяет комплекс требований к разработке ПО программно-аппаратных систем, связанных с безопасностью?
ГОСТ Р 15408
Стандарты безопасности
В связи со стандартами для ОСРВ стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria – TCSEC) [DoD85]. Этот стандарт разработан Министерством обороны США и известен также под названием «Оранжевая книга» (Orange Book – из-за цвета обложки).
В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт “Общие критерии оценки безопасности информационных технологий” (далее просто – Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) [CC99].
В «Оранжевой книге» перечислены семь уровней защиты:
• А1 – верифицированная разработка. Этот уровень требует, чтобы защиту секретной и другой критичной информации средствами управления безопасностью гарантировали методы формальной верификации.
• В3 – домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов.
• В2 – структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров.
• В1 – мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям.
• С2 – дискреционный контроль доступа. Уровень С2 обеспечивает защиту процедур входа, позволяет производить контроль за событиями, имеющими отношение к безопасности, а также изолировать ресурсы.
• С1 – избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом.
• D – минимальная защита. Этот нижний уровень защиты оставлен для систем, которые проходили тестирование, но не смогли удовлетворить требованиям более высокого класса.
Что касается Общих критериев, то в них введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels – EAL). Их также семь:
• EAL7 – самый высокий уровень предполагает формальную верификацию модели объекта оценки. Он применим к системам очень высокого риска.
• EAL6 определяется, как полуформально верифицированный и протестированный. На уровне EAL6 реализация должна быть представлена в структурированном виде, анализ соответствия распространяется на проект нижнего уровня, проводится строгий анализ покрытия, анализ и тестирование небезопасных состояний.
• EAL5 определяется, как полуформально спроектированный и протестированный. Он предусматривает создание полуформальной функциональной спецификации и проекта высокого уровня с демонстрацией соответствия между ними, формальной модели политики безопасности, стандартизованной модели жизненного цикла, а также проведение анализа скрытых каналов.
• EAL4 определяется, как методически спроектированный, протестированный и пересмотренный. Он предполагает наличие автоматизации управления конфигурацией, полной спецификации интерфейсов, описательного проекта нижнего уровня, подмножества реализаций функций безопасности, неформальной модели политики безопасности, модели жизненного цикла, анализ валидации, независимый анализ уязвимостей. По всей вероятности, это самый высокий уровень, которого можно достичь на данном этапе развития технологии программирования с приемлемыми затратами.
• EAL3 определяется, как методически протестированный и проверенный. На уровне EAL3 осуществляется более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки.
• EAL2 определяется, как структурно протестированный. Он предусматривает создание описательного проекта верхнего уровня объекта оценки, описание процедур инсталляции и поставки, руководств администратора и пользователя, функциональное и независимое тестирование, оценку прочности функций безопасности, анализ уязвимостей разработчиками.
• EAL1 определяется, как функционально протестированный. Он обеспечивает анализ функций безопасности с использованием функциональной спецификации и спецификации интерфейсов, руководящей документации, а также независимое тестирование. На этом уровне угрозы не рассматриваются как серьезные.
173. Какие функции выполняет микроядро ОСРВ QNX Neutrino?
В QNX Микроядро выполняет две важнейшие функции:
• передача сообщений — Микроядро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе;
• диспетчеризация — планировщик — это часть Микроядра, и он получает управление всякий раз, когда процесс изменяет свое состояние в результате получения сообщения или прерывания.
В отличие от всех остальных процессов, ядро никогда не получает управления в результате диспетчеризации. Входящий в состав ядра код выполняется только в результате прямых вызовов из процесса или аппаратного прерывания.
174. В чём различие между процессом и потоком в ОСРВ QNX Neutrino?
Различие между процессами и потоками
С помощью процессов можно организовать параллельное выполнение программ. Для этого процессы клонируются вызовами fork() или exec(), а затем между ними организуется взаимодействие средствами IPC. Это довольно дорогостоящий в отношении ресурсов процесс.
С другой стороны, для организации параллельного выполнения и взаимодействия процессов можно использовать механизм многопоточности. Основной единицей здесь является поток.
Поток представляет собой облегченную версию процесса. Чтобы понять, в чем состоит его особенность, необходимо вспомнить основные характеристики процесса.
1. Процесс располагает определенными ресурсами. Он размещен в некотором виртуальном адресном пространстве, содержащем образ этого процесса. Кроме того, процесс управляет другими ресурсами (файлы, устройства ввода / вывода и т.д.).
2. Процесс подвержен диспетчеризации. Он определяет порядок выполнения одной или нескольких программ, при этом выполнение может перекрываться другими процессами. Каждый процесс имеет состояние выполнения и приоритет диспетчеризации.
Если рассматривать эти характеристики независимо друг от друга (как это принято в современной теории ОС), то:
• владельцу ресурса, обычно называемому процессом или задачей, присущи:
o виртуальное адресное пространство;
o индивидуальный доступ к процессору, другим процессам, файлам, и ресурсам ввода — вывода.
• Модулю для диспетчеризации, обычно называемому потоком или облегченным процессом, присущи:
o состояние выполнения (активное, готовность и т.д.);
o сохранение контекста потока в неактивном состоянии;
o стек выполнения и некоторая статическая память для локальных переменных;
o доступ к пространству памяти и ресурсам своего процесса.
Все потоки процесса разделяют общие ресурсы. Изменения, вызванные одним потоком, становятся немедленно доступны другим.
При корректной реализации потоки имеют определенные преимущества перед процессами. Им требуется:
• меньше времени для создания нового потока, поскольку создаваемый поток использует адресное пространство текущего процесса;
• меньше времени для завершения потока;
• меньше времени для переключения между двумя потоками в пределах процесса;
• меньше коммуникационных расходов, поскольку потоки разделяют все ресурсы, и в частности адресное пространство. Данные, продуцируемые одним из потоков, немедленно становятся доступными всем другим потокам.
175. Кто такой С. Зыль?
Сергей Зыль — автор следующих книг.
Книга «QNX Momentics. Основы применения» (Сергей Зыль)
Книга «Проектирование, разработка и анализ программного обеспечения систем реального времени» (Сергей Зыль)
Книга «ОС реального времени QNX: от теории к практике». 2-е издание. (Сергей Зыль)
176. Кто является автором переводной книги по программированию систем реального времени в среде QNX Neutrino?
Сергей Зыль ???
Кёртен, Р. Введение в QNX Neutrino 2: руководство по про-
граммированию приложений реального времени в QNX Realtime Platform/ Р. Кёртен – СПб.: Петрополис, 2001 — 480 с.
— СПб.: БХВ-Петербург, 2005 доп. тираж -400 с.