Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
за границей стека помещается область памяти минимально допустимого размера с защитой от доступа. Это самый совершенный способ контроля, так как при любом выходе за границу произойдет аппаратное прерываниеПри любом? Даже если перепрыгнуть защищённую область памяти?
В целом — Вы правы. К счастью, у нас сейчас не могут запускаться сторонние приложения. Приложения собираются вместе с ОС, так что зловредный код, который пытается «просочиться» — отсутствует. Стек растёт в сторону меньших адресов, так что вылет за пределы массива — тоже выскочит за защищаемую область только если нечаянно произошло отрицательное смещение.
Итого: Задача защиты стека от случайного типового случая переполнения — всё равно выполняется. Случайное грубое переполнение (вылет за пределы массива в отрицательную область) и зловредные действия — Вы верно заметили, отслежены не будут. Пожалуй, я подниму этот вопрос на обсуждение с архитекторами и разработчиками в плане, не будет ли вопросов при сертификации. Возможно, это просто придётся отразить в документах, ведь такое возможно и на PC под Windows. По крайней мере, было возможно — точно, указателю всё равно, указывает он на стек, на кучу или вообще на проецируемые на память регистры аппаратуры.
Но чисто формально — всё равно, метод — самый совершенный. Так как все остальные методы — хуже.
Итого: Задача защиты стека от случайного типового случая переполнения — всё равно выполняется. Случайное грубое переполнение (вылет за пределы массива в отрицательную область) и зловредные действия — Вы верно заметили, отслежены не будут. Пожалуй, я подниму этот вопрос на обсуждение с архитекторами и разработчиками в плане, не будет ли вопросов при сертификации. Возможно, это просто придётся отразить в документах, ведь такое возможно и на PC под Windows. По крайней мере, было возможно — точно, указателю всё равно, указывает он на стек, на кучу или вообще на проецируемые на память регистры аппаратуры.
Но чисто формально — всё равно, метод — самый совершенный. Так как все остальные методы — хуже.
Приложения собираются вместе с ОС, так что зловредный код, который пытается «просочиться» — отсутствует.Если потенциальные злоумышленники используют возвратно-ориентированное программирование, то зловредный код всё-таки может «просочиться». Да и не всегда нужно именно внедрять код. Иногда таким образом можно слить важные данные, или выполнить какое-то другое несанкционированное действие, которое может привести к нежелательным последствиям.
Для систем, обрабатывающих важные данные, используются аппаратные системы другого уровня с другими типами ОС. ОСРВ МАКС в текущем исполнении должна обеспечивать работу оборудования (станков, бытовых приборов, иных аппаратов) на микроконтроллерах с не самым мощным набором встроенной аппаратуры. В частности, в большинстве из них, всё исполняется во флэшке. Поэтому там уровень защиты определяется скорее производителем контроллера.
В частности, у контроллеров Cypress FX2LP (51-е ядро, не поддерживается нашей ОС, но уж больно пример показательный) есть Vendor команда USB, которую нельзя перекрыть. Через неё память пишется и читается. Но это уже разработчику аппаратуры виднее, если он захочет поставить контроллер, у которого есть такая то ли особенность, то ли дыра… Зависит от случая.
В общем, сейчас считаем, что собирается ОС и приложение, это дело как-то «шьётся», после чего — старается работать с максимальной производительностью, обеспечивая работу «железа». Защититься от проникновения средствами контроллера, типа как я описал для FX2LP — ОС бессильна. И её задача — обеспечить хорошую, производительную работу системы.
Если появится Заказчик с иными задачами — будем их решать.
В частности, у контроллеров Cypress FX2LP (51-е ядро, не поддерживается нашей ОС, но уж больно пример показательный) есть Vendor команда USB, которую нельзя перекрыть. Через неё память пишется и читается. Но это уже разработчику аппаратуры виднее, если он захочет поставить контроллер, у которого есть такая то ли особенность, то ли дыра… Зависит от случая.
В общем, сейчас считаем, что собирается ОС и приложение, это дело как-то «шьётся», после чего — старается работать с максимальной производительностью, обеспечивая работу «железа». Защититься от проникновения средствами контроллера, типа как я описал для FX2LP — ОС бессильна. И её задача — обеспечить хорошую, производительную работу системы.
Если появится Заказчик с иными задачами — будем их решать.
Прочитал по Вашей ссылке про защиту от этого возвратно-ориентированного программирования. По-моему, тут ядро не должно никак участвовать. Скорее протоколы взаимодействия должны всё учитывать, вот их пусть на сертификации и проверяют.
А если у злодея есть личный доступ к аппаратуре, то он и через JTAG вломится. Наверняка же программист за собой не подчистит, и этот порт не заблокирует. Опять же, блокировка JTAG, взведение битов защиты и прочее — это уже не задача ядра (о котором речь в этой статье), это уже задачи прикладника, так как после отключения будет невозможна отладка. То есть, делаться всё должно на финальной стадии, если это вообще требуется.
А защита стека — она чисто от случайного переполнения. Пришёл новый сотрудник, добавил локальных переменных, стек и переполнился. Вот такие вещи отследить. Они побольше бед, чем злодеи, натворить могут. Вспомним хотя бы «муху цэцэ» у накопителей Seagate. Она возникала от переполнения файла с логом событий. А сколько дисков в кирпичи превращалось. Хорошо, что нашли выход…
А если у злодея есть личный доступ к аппаратуре, то он и через JTAG вломится. Наверняка же программист за собой не подчистит, и этот порт не заблокирует. Опять же, блокировка JTAG, взведение битов защиты и прочее — это уже не задача ядра (о котором речь в этой статье), это уже задачи прикладника, так как после отключения будет невозможна отладка. То есть, делаться всё должно на финальной стадии, если это вообще требуется.
А защита стека — она чисто от случайного переполнения. Пришёл новый сотрудник, добавил локальных переменных, стек и переполнился. Вот такие вещи отследить. Они побольше бед, чем злодеи, натворить могут. Вспомним хотя бы «муху цэцэ» у накопителей Seagate. Она возникала от переполнения файла с логом событий. А сколько дисков в кирпичи превращалось. Хорошо, что нашли выход…
Решил добавить: От переполнения, так как произошло большое количество вложенных вызовов функций. Либо в функциях было слишком много локальных переменных. Вот от таких вещей защита в первую очередь работает.
Как прикидывать, не случится ли такое, «на глазок» — будет описано в следующей части, она отрезана от этой части, так как получалось слишком много PageDown-ов.
Как прикидывать, не случится ли такое, «на глазок» — будет описано в следующей части, она отрезана от этой части, так как получалось слишком много PageDown-ов.
А текст я переформулирую в понедельник. Немного пообщаюсь с товарищем, который писал соответствующий код, и изменю формулировки глобально. Слово «любом» уберу, но лучше сразу добавлю подробностей, как можно настраивать защиту под ситуацию. А для этого — лучше сначала запытаю автора кода, чтобы отразить не только, что сам вижу в коде, но и все его задумки. Большое спасибо за то, что обратили внимание!
Как я уже говорил, философия — не мой конёк. Но тем не менее. Ядро — имеется. Управление потоками (тут они называются задачами) — имеется. Средства синхронизации задач — имеются. Драйверы — имеются.
Железку вполне можно оживить и без этого набора. Причём не будем доходить до фанатизма. Простые железки лично я без ядра оживляю, хотя драйверы — мне так нравятся, что я только через них работаю. Ядро нужно, когда система взаимодействий становится сложной.
Если посмотреть на большинство RTOS для низших контроллеров — у них у всех есть этот минимальный джентельменский набор, после которого у нас уже не набор библиотек, а ОС.
А что у нас круче, чем у других — будет ближе к концу цикла. Ну, и объектный подход. Хотя, в комментариях к первой части на эту тему много философии было, а философия — не мой конёк. Я считаю, что это — преимущество…
Железку вполне можно оживить и без этого набора. Причём не будем доходить до фанатизма. Простые железки лично я без ядра оживляю, хотя драйверы — мне так нравятся, что я только через них работаю. Ядро нужно, когда система взаимодействий становится сложной.
Если посмотреть на большинство RTOS для низших контроллеров — у них у всех есть этот минимальный джентельменский набор, после которого у нас уже не набор библиотек, а ОС.
А что у нас круче, чем у других — будет ближе к концу цикла. Ну, и объектный подход. Хотя, в комментариях к первой части на эту тему много философии было, а философия — не мой конёк. Я считаю, что это — преимущество…
философия — не мой конёк. Я считаю, что это — преимуществоЭто зря. Ядро философии — логика. А я вижу в ваших рассуждениях об ОСРВ МАКС некоторые логически слабые места, ложные предпосылки, но спорить о них не видел смысла, потому что видно, что Вы их крепко держитесь. Но победить их — значит улучшить систему, которая не будет уводится не в лучшем направлении. Для данной системы уже поздно, но будут же и новые проекты.
В общем, рассуждения о ненужности философии — это приблизительно то же, что рассуждения о ненужности физики от человека, не желающего знать физику. И физика и философия будут в любом случае, но они либо будут отрицаемы и замутнены, либо признаваемы, очищаемы от шелухи и лучше служить делу.
И да, МАКС — это операционная система.
В общем, рассуждения о ненужности философии — это приблизительно то же, что рассуждения о ненужности физики от человека, не желающего знать физику.
Я просто хотел сказать, что меня в философских вопросах «завалить» — проще простого. Например, рассуждая о плюсах и минусах ООП применительно к ОС. В дебри же так просто сорваться.
Относительно этой ветки дискуссии — что такое ОС, а что — просто набор библиотек. Там можно долго спорить. И как людей в таком споре «уделывают» — я знаю. Вот и сразу сдаюсь :-).
Так что тут не нужность и ненужность философии, а просто философия — не мой конёк. Технические вопросы — ко мне. Философские — сразу сдаюсь, просто высказываю свои аргументы и всё. А жонглировать понятиями — не в состоянии.
Аааа! Я понял, что Вы имели в виду. Надо читать сразу три предложения. «Философствовать про преимущества ООП и процедурного подхода можно долго, лично я считаю, что ООП — это преимущество, но философия — не мой конёк, поэтому я так считаю, а спорить не буду.». Имелось в виду это в тех трёх предложениях. «Преимущество» относилось к слову «ООП», а не «не мой конёк».
А я категорически ПРОТИВ любого ПО (хоть импортного, хоть отечественного), которое не доведено до ума — при этом я совсем не имею в виду описываемую систему.
Чисто на всякий случай. Вдруг кто-то не прочтёт, что Вы не про нашу ОС. Поэтому я «прикрою» Ваш комментарий своим.
Мы несколько лет доводили ОС до минимально возможного ума. Мы прошли через ядро, которое работает, но делать на нём что-то страшно, так как то тут то там видны всякие мелкие утечки, а на имеющихся объёмах памяти это критично. Мы прошли через чистку этого ядра (полный рефакторинг внутренних механизмов с сохранением интерфейсов). Затем — пробная эксплуатация для внутренних задач. И уже потом — начали это дело как-то продвигать.
Не то, чтобы там уже больше нечего править. Команда всё время чем-то активно занята. Но продвигать мы начали уже не совершенно сырой продукт. Так редко, но бывает. И тут было именно так.
Мы несколько лет доводили ОС до минимально возможного ума. Мы прошли через ядро, которое работает, но делать на нём что-то страшно, так как то тут то там видны всякие мелкие утечки, а на имеющихся объёмах памяти это критично. Мы прошли через чистку этого ядра (полный рефакторинг внутренних механизмов с сохранением интерфейсов). Затем — пробная эксплуатация для внутренних задач. И уже потом — начали это дело как-то продвигать.
Не то, чтобы там уже больше нечего править. Команда всё время чем-то активно занята. Но продвигать мы начали уже не совершенно сырой продукт. Так редко, но бывает. И тут было именно так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор одной российской RTOS, часть 3. Структура простейшей программы