Недавно попросили в двух словах рассказать серьезным людям о загрузке операционной системы на ARM и дать оценку угроз безопасности этого процесса. Вообще ARM-процессоров и вообще ОС. Вы понимаете, все ведь слышали про эти ARM, и что такое ОС тоже все знают. Желательно, на уровне квадратиков со стрелками.

Загрузка ARM в четырех прямоугольниках — под катом.

Здравствуйте! Я давно не появлялся здесь в качестве оратора, но в этот раз я решил поделится кое-чем, что сделал сам, а также узнать — нужно это, не нужно, как можно доработать и вообще услышать любые отзывы о моих деяниях.

Мотивация

Проблема сборки и запуска проекта на разных машинах преследовала меня всегда. Для того, чтобы реалистично смоделировать работу разрабатываемого сайта на локальной машине нужно установить Web-сервер, Application-сервер, возможно, к ним присоединится какой-нибудь ещё промежуточный сервер, установить базу данных, настроить базу данных. Для того, чтобы установить тестовый сайт на тестовый сервер, нужно проделать такую же работу. И позже тоже самое с рабочим сервером.

Кажется, что проблема решается легко — напиши все команды в файл и просто запускай его везде. Решение относительно хорошее, но не идеальное, и вот почему. К примеру, на одном из серверов уже установлены нужные пакеты и база данных там готова. Но не до конца, к ней не применены последние миграции. Придётся открывать файл с командами и вытаскивать оттуда нужные, дабы не получить ошибку или чтобы что-то не сломать.

Название статьи подсказала тема на одном из форумов. Несмотря на то, что с момента возникновения вопроса прошло шесть лет, в этом направлении мало что изменилось. А поскольку в последнее время у меня на слуху постоянно был OpenVPN, то было решено исправить данную ситуацию. Так родилась графическая утилита VpnGUI для создания, редактирования, запуска и контроля выполнения утилиты openvpn.

После запуска утилиты VpnGUI в трее появится иконка (квадрат разбитый на четыре сине-красных квадратика) утилиты:

Nuklear+ (читается как "Nuklear cross", значит "кроссплатформенный Nuklear") — это надстройка над GUI библиотекой Nuklear, которая позволяет абстрагироваться от драйвера вывода и взаимодействия с операционной системой. Нужно написать один простой код, а он потом уже сможет скомпилироваться под все поддерживаемые платформы.

Я уже писал на хабре статью "Nuklear — идеальный GUI для микро-проектов?". Тогда задача была простой — сделать маленькую кроссплатформенную утилиту с GUI, которая будет примерно одинаково выглядеть в Windows и Linux. Но с тех самых пор меня не отпускал вопрос, а можно ли на Nuklear сделать что-то более-менее сложное? Можно ли целиком на нём сделать какой-нибудь реальный проект, которым будут пользоваться?

Здравствуйте, дорогие хабрачитатели.

Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.

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

Это моя первая статья, пожалуйста не судите строго!

P.S

Получилось слишком много букв, поэтому я принял решение разделить статью на три части:

Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.

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

Итак, начнем.

В этом посте мы решили рассказать о доменной аутентификации в Linux, с использованием смарт-карт и USB-токенов JaCarta PKI в качестве второго фактора аутентификации. Если о локальной аутентификации через PAM-модуль информации существует довольно много, то вопрос доменной инфраструктуры и аутентификация по Kerberos-билетам в Linux рассмотрен слабо, особенно на русском языке. В качестве операционной системы возьмем Astra Linux и на примере Astra Linux Directory (ALD) это и покажем.

Выгода такого решения очевидна – оно позволяет отказаться от парольной аутентификации пользователя, что поможет кардинально снизить влияние «человеческого фактора» на безопасность системы. Плюс это даст ряд преимуществ от использования электронных ключей внутри операционной системы, после аутентификации в домене.

Помимо атомарных операций KMS для пользователей рабочей станции Linux недавно завезли еще одно полезное новшество — планировщик подсистемы ввода и вывода BFQ (Budget Fair Queue). Он является усовершенствованием дефолтного CFQ (Completely Fair Queue), дебютировал аж 9 лет назад, но только в версии 4.12 попал в основную ветку.

Прежде чем поговорить о принципах работы планировщика ознакомьтесь с демо-роликом разработчика Paolo Valente, это добавит вам мотивации продолжить. На снимке экрана показан замер старта проигрывателя с 10 фоновыми задачами читать файл с диска для двух планировщиков: CFQ и BFQ. Угадайте, который из них так и не стартовал при такой нагрузке?

В новом ядре linux-4.4 переписали механизм работы с deviceTree. Теперь они больше не компилируются вместе с ядром, а поставляются отдельным репозиторием. В прошлый раз, когда я пытался завести китайский 4х дюймовый дисплей WaveShare, никаких адекватных мануалов не было. Максимум, что я смог найти — это исходники модуля для старого ядра (linux-3.8.13). Провозившись неделю я всё-таки собрал своё ядро, с которым не расстаюсь.

Но время меняется, уже давно все перешли на Debian 8.7, но мануалов как подключить дисплей BB-VIEW на новом ядре я так и не нашёл.

Леность ли моя тому причиной или болезненная неприязнь к комбайнам, но у меня как-то не сложились отношения с большими толстыми довольными IDE. Довольствуюсь простым ламповым Geany и несколькими самописными скриптами, количество коих растёт по мере необходимости.

С одной стороны, минусы очевидны — все эти скрипты часто повторяют функционал больших сред разработки; велосипеды — в массы. Но с другой стороны, я получаю ровно то, что нужно и удобно мне. Да и, потом, юниксвейненько получается: понадобилось забить гвозь — берёшь молоток, а не нанимаешь строительный кран с бригадой рабочих и прорабом.

О некоторых таких скриптах решил попробовать писать сюда. Может, кому пригодятся (да и заточить под себя какой-нибудь из них всегда можно). Если нет — ругайтесь в комментариях, учту. Итак.

Проблемы legacy-кода знакомы подавляющему большинству разработчиков программного обеспечения. Процесс превращения кода в legacy неизбежен, ведь прогресс в программировании не стоит на месте. Проекты либо «умирают» навсегда, либо требуют постоянной поддержки и написания новых функций. Таким образом, в любом проекте на любом языке программирования legacy-код возникает и доставляет разные неудобства при дальнейшей разработке. На примере PVS-Studio, в этой статье я расскажу, как сразу начать использовать статический анализатор кода в своём проекте.

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.

С 4 по 8 августа в Нидерландах прошел крупный хакерский фестиваль SHA2017. Несмотря на интенсивную подготовку к своему выступлению (и сильное волнение перед ним), я посетил много интересных докладов. В этой заметке перечислю те из них, которые мне особенно понравились, и поделюсь впечатлениями.

Недавно я оказался в не совсем обычной для себя ситуации вынужденного безделья. Пару недель поваляв дурака, я стал чувствовать, что это не такое уж и веселое занятие, которое к тому же еще и стало переходить в скуку. И мне надо было себя занять чем-нибудь относительно полезным. Раньше мне периодически приходили в голову мысли о том, чтобы вернуть к жизни какую-нибудь старую игру из времен моей юности. Но я всегда гнал такие идеи прочь, так как понимал, что "никому это теперь не надо". Но сейчас у меня было свободное время и, главное, было желание. В результате для клонирования я выбрал один из вариантов игры Lode Runner, в который я когда-то играл на первом персональном компьютере времен позднего СССР, который назывался БК-0010. Не думаю, что многие о нем помнят, так как мир «железа» поменялся с тех времен очень сильно. Однако сам Lode Runner с этого БК-0010 был достаточно уникален своими правилами среди других одноименных Lode Runner-ов. Эта версия игры была моей самой любимой, как мне кажется, по объективным причинам, хотя… может быть тут дело просто в ностальгии. В результате я сумел себя мотивировать тем, что "лично мне", а, возможно, и "всему миру", эта игра может быть интересна, и на её восстановление стоит потратить время (ссылка на полученный результат).

Для начала взглянем на оригинал с БК-0010 (хвала Интернету, в котором можно найти почти всё):

Уникальная особенность опенсорсных проектов заключается в том, что жизнь их никогда по-настоящему не заканчивается. Образы дисков, по большей части, доступны для загрузки из интернета, их лицензии не истекают. Поэтому довольно просто совершить прыжок в прошлое, установив Linux из 90-х на виртуальной машине.

Как это было? Как воспринимаются сегодня древние дистрибутивы Linux? Что изменилось за годы развития? Выясним это. Первым пунктом нашего путешествия станет ОС Slackware 1.01, оправленная в группу новостей comp.os.linux.announce 20 лет назад.

Пакет Network Security Services (NSS) представляет собой набор библиотек, используемых при кроссплатформенной разработке защищенных клиентских и серверных приложений.

Начал изучать волшебный язык Python3 и решил испробовать его в действие на своем маленьком VPS.

На сервере стоит Mysql, Apache, nginx… во общем простой стандартный набор, там же хостятся с два десятка клиентских сайтов.

Каждый день делается резервная копия всех баз и файлов доменнов средствами приметного скрипта #!bin/bash

Я решил использовать Python 3… Вот непосредственно и сам код:

Продолжаем развивать тему использования компьютера с ubuntu server в качестве устройства для связи мира микроконтроллеров с миром персональных компьютеров.

Ссылка на часть 1

Напомню, что статья описывает практику применения описанной техники и не ставит целью охватить все глубины и возможности современной аппаратуры. Это один из вариантов решения поставленной задачи.

При решении задач электроники все методы хороши, если они устраивают ТЗ, бюджет и разработчика. Linux был мне неизвестен, но вместе с задачами, которые решаешь, растешь и сам. Этот пост расскажет о том, как применить компьютер с Ubuntu для связи большого компьютера с контроллером в соответствии со схемой:

Статья описывает практику применения описанной техники и не ставит целью охватить все глубины и возможности современной аппаратуры. Это один из вариантов решения поставленной задачи.

Мы, дети 90-х, любим добавить в задания NeoQUEST что-нибудь олдскульное. В этом году нам вспомнились гремлины, и мы добавили их в легенду одного из заданий соревнования «Очной ставки» NeoQUEST-2017.

Однако, под внешне забавной легендой скрывается вполне себе реальная практическая задача: а что, если привычные ELF-файлы — не просто исполняемые файлы, а контейнеры, открыть которые нам предстоит? Для этого придется испытать довольно-таки обширные возможности objcopy и освежить в памяти организацию ELF-файла.

Чтобы вычислить подозрительные секции, необходимо представлять секционный и сегментный состав типичного ELF. Помимо этого, конечно, пригодится и опыт — например, общение с firmware embedded-систем вполне может подсказать подходящие идеи!

Думаете, готовы на 100%? Уверены, что гремлинам удастся вас удивить спрятанными архивами, попорченными таблицами символов, а также аудиофайлами, которые зазвучат только в руках умелого мастера! Под катом — исходники к заданию и прохождение, чтобы каждый читатель Хабра мог собственноручно попробовать пройти задание!

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода). Мои рассуждения о том, что это сильно зависит от анализируемого проекта и настроек анализатора не выглядят как настоящий ответ. Я решил привести конкретные числа, проведя более тщательное исследование одного из проектов, входящих в состав Tizen. Поскольку в обсуждении статьи активное участие принимал Carsten Haitzler, я решил, что будет интересно взять для эксперимента EFL Core Libraries, в разработке которого он участвует. Надеюсь, эта статья поможет Carsten стать поклонником нашего анализатора :).