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

Тем не менее, с появлением libclang, можно писать собственные анализаторы и генераторы кода прямо в compile time, устраняя достаточно большое множество проблем на ранних этапах работы. Сочетание инструментов статического анализа общего плана (coverity, clang-scan), инструментов анализа для конкретного проекта, а также дисциплины написания кода позволяет намного улучшить качество и безопасность кода, написанного на Си. Конечно, это не даст гарантий, каких дает haskell или даже rust, но позволяет существенно оптимизировать процесс разработки, особенно в случае, когда переписывать огромный проект на другом языке является нереальной задачей.

В данной статье я хотел бы поделиться опытом создания плагина статического анализа format argument для функций, похожих на printf. В ходе написания плагина, мне пришлось очень много рыться в исходниках и doxygen документации libclang, поэтому я счел полезным сделать некоторый обзор для тех, кто хочет ступить на этот тернистый путь, но пока еще не уверен в целесообразности траты времени на сбор информации. В статье не будет картинок, и даже картинок блюющих единорогов, простите.

Как и многие языки программирования, Rust призывает разработчика определенным способом обрабатывать ошибки. Вообще, существует два общих подхода обработки ошибок: с помощью исключений и через возвращаемые значения. И Rust предпочитает возвращаемые значения.

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

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

От переводчика: представляю вашему вниманию перевод статьи Майкла Штейла. Я давно хотел подготовить подобный обзор методов использования виртуализации для задач обеспечения совместимости. Я даже опубликовал некоторые заметки на эту тему: в учебнике по симуляции, глава 1, и на Хабре в посте про системные ВМ. Однако мне не удалось раскрыть вопрос так глубоко, как он представлен в этой работе. Поэтому я решил поделиться переводом с читателями.

---

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

Давайте рассмотрим, как это происходило в последние 30 лет, на примерах MS DOS/Windows, Apple Macintosh, Amiga OS и Palm OS.

Доброго времени суток!
Хочу представить вашему вниманию перевод статьи Джонатана Барлетта (Jonathan Bartlett), который является техническим директором в компании New Medio. Статья была опубликована 16 ноября 2004 года на сайте ibm.com и посвящена методам управления памятью. Хотя возраст статьи достаточно высок (по меркам IT), информация в ней является фундаментальной и описывает подходы к распределению памяти, их сильные и слабые стороны. Всё это сопровождается «самопальными» реализациями, для лучшего усвоения материала.

Аннотация от автора
Решения, компромиссы и реализации динамического распределения памяти
Получите представление о методах управления памятью, которые доступны Linux разработчикам. Данные методы не ограничиваются языком C, они также применяются и в других языках программирования. Эта статья даёт подробное описание как происходит управление памятью, на примерах ручного подхода (manually), полуавтоматического (semi-manually) с использованием подсчёта ссылок (referencing count) или пула (pooling) и автоматического при помощи сборщика мусора (garbage collection).

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

Вот о чем речь:

<VirtualHost *:80>
    ServerName host1.example.com
    ServerAdmin webmaster1@example.com
    ServerUserGroup user1 group1
    DocumentRoot /var/www/host1
</VirtualHost>
<VirtualHost *:80>
    ServerName host2.example.com
    ServerAdmin webmaster2@example.com
    ServerUserGroup user2 group2
    DocumentRoot /var/www/host2
</VirtualHost>

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

# ls -la /var/www
total 16
drwxr-xr-x   4 root  root   4096 Oct 26 16:10 .
drwxr-xr-x  21 root  root   4096 Oct 26 01:13 ..
drwxr-x---   2 user1 group1 4096 Oct 26 16:10 host1
drwxr-x---   2 user1 group2 4096 Oct 26 16:10 host2

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

Не так давно у меня появилась необходимость загружать конфигурацию приложения при очень ограниченных ресурсах. Не было доступа, практически, ни к каким стандартным функциям C. Очень повезло, что были стандартные функции по работе с памятью malloc()/free().

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

Из этого можно сделать вывод, что надо либо:

1. Писать свой редактор бинарного формата.
2. Использовать текстовый формат.

От переводчика. Представляю вашему вниманию перевод поста Майкла Штейла (Michael Steil) http://www.pagetable.com/?p=308. В нём затрагиваются вопросы сомнительной практики именования сущностей в спецификациях вычислительных архитектур.
Эта заметка очень хорошо отражает ситуацию с именами, возникающую в процессе длительной эволюции документации, и моё собственное недоумение, когда я впервые встретился с этими понятиями.
Комментарии к тексту размещены во всплывающих подсказках.

Имеется в виду выполнение записи по аппаратно защищённому от записи адресу памяти в архитектуре x86. И то, как это делается в операционной системе Linux. И, естественно, в режиме ядра Linux, потому как в пользовательском пространстве, такие трюки запрещены. Бывает, знаете ли, непреодолимое желание записать в защищённую область … когда садишься писать вирус или троян…

Описание проблемы

… а если серьёзно, то проблема записи в защищённые от записи страницы оперативной памяти возникает время от времени при программировании модулей ядра под Linux. Например, при модификации селекторной таблицы системных вызовов sys_call_table для модификации, встраивания, имплементации, подмены, перехвата системного вызова — в разных публикациях это действие называют по разному. Но не только для этих целей… В очень кратком изложении ситуация выглядит так:

• В архитектуре x86 существует защитный механизм, который при попытке записи в защищённые от записи страницы памяти приводит к возбуждению исключения.
• Права доступа к странице (разрешение или запрет записи) описываются битом _PAGE_BIT_RW (1-й) в соответствующей этой странице структуре типа pte_t. Сброс этого бита запрещает запись в страницу.
• Со стороны процессора контролем защитой записи управляет бит X86_CR0_WP (16-й) системного управляющего регистра CR0 — при установленном этом бите попытка записи в защищённую от записи страницу возбуждает исключение этого процессора.

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

Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.

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

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



Ниже под катом — расшифровка нашей беседы для тех, кто видео не очень.

Как синхронизировать параллельные шелл-процессы, используя named pipes (FIFO-файлы) в качестве условных переменных. Как выполнить параллельно зависимые задач в топологическом порядке с минимумом средств: POSIX shell, mkfifo, POSIX kernel. Как параллельный запуск ускоряет загрузку встраиваемых систем и *BSD (rc-этап FreeBSD с 27 до 7 секунд) или старт приложений в пользовательских контейнерах Docker, LXC и jail. Как это повышает аптайм в отказоустойчивых кластерах Jet9.

Я не буду соревноваться в мастерстве написания репортажей с dzeban, вместе с которым мне посчастливилось побывать на конференции линукс-разработчиков LinuxCon Europe. Поэтому постараюсь просто осветить то, что мне больше всего запомнилось, и таким образом дополнить картину.



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

Раз в год в Европе проходит событие, которое мечтают посетить все, кто хоть что-то знает про Linux. Событие, которое собирает вокруг себя самое большое сообщество, когда-либо существовавшее на этой планете. Сообщество энтузиастов, хакеров, инженеров, программистов, админов, корпоративных боссов, всех тех, кто имеет работу и хобби благодаря Linux и open source. Мы в НТЦ Метротек привыкли делиться знаниями и получать их, поэтому такое пропустить не могли. Дамы и господа, добро пожаловать в Дублин на тройную конференцию LinuxCon + CloudOpen + Embedded LinuxCon Europe 2015!

Уже в эту среду, 14 октября, в петербургском офисе компании Oracle состоится встреча JUG.ru c Фолькером Симонисом из SAP. Тема встречи — внутреннее устройство SAP JVM.


Наверняка многие из вас слышали про SAP — немецкого гиганта, который делает разные корпоративные системы — бухучёт, контроль за производством, финансы, HR, кадры, управление складом и прочий «Кровавый энтерпрайз», который с большой вероятностью стоит в вашей организации, если ее численность превышает тысячу человек.

Фокус в том, что многие (если не все) из перечисленных решений так или иначе работают на Java, и соответственно внутри них крутится JVM. Прикол в том, что это их собственная JVM. Ну как собственная — в свое время она была лицензирована у Sun вместе с исходниками, из которых и разрабатывалась. В данный момент — она лицензируется у Oracle. Соответственно, это некоторый форк Oracle JDK / JVM со своими косынкой и секретаршами, лицензированный, совместимый и т.д. и т.п.

Однако это не только форк, но и порт, поддерживающий 7 CPU-архитектур: x86, x86_64, SPARC, PowerPC, Itanium, z/Arch and PA-RISC на семи разных операционках: OS X, Windows, Solaris, Linux, AIX, as400 and HP/UX. По заявлению SAP, они поддерживают единую систему конфигурирования, единое поведение, одинаковые плюшки и расширения, инструменты анализа и поддержи на всей этой аццкой комбинации платформ.



Как видно из этой таблички, они до сих пор поддерживают Java с 1.4 до 8 на всех упомянутых платформах. Например, Oracle поддерживает нынче только Java 8, а Azul и Red Hat, как я понимаю, только 6, 7 и 8.

Так вот, у нас большое счастье. В эту среду на питерском JUG Volker Simonis, наш большой друг и разработчик SAP JVM, будет в стандартном двухчасовом формате рассказывать про все это щастье. Он будет выступать на Joker и планировал прилетать в четверг, но мы специально попросили прилететь его на день раньше, чтобы сделать с ним отдельный JVM-ный ивент.

                                                                                    - Что-то беспокоит меня Гондурас...
                                                                                    - Беспокоит? А ты его не чеши.

В предыдущих частях обсуждения (1-я, 2-я и 3-я) мы рассматривали как, используя возможность поменять содержимое sys_call_table, изменить поведение того или иного системного вызова Linux. Сейчас мы продолжим эксперименты в сторону того, можно ли (и как) динамически добавить новый системный вызов в целях вашего программного проекта.

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

Предыдущую часть обсуждения мы завершили на такой вот оптимистической ноте: «Подобным образом мы можем изменить поведение любого системного вызова Linux». И тут я слукавил — любого… да не любого. Исключение составляют (могут составлять) группа сетевых системных вызовов, работающих с BSD сокетами. Когда сталкиваешься с этим артефактом в первый раз — это изрядно озадачивает.

Сегодня я приготовил для вас большое интервью с Андреем Паньгиным aka apangin, ведущим инженером Одноклассников. Андрей больше 6 лет проработал JVM-инженером в Sun Microsystems, в том числе, в команде HotSpot, а последние 5 лет работает в Одноклассниках, решая там вопросы, связанные с JVM и производительностью. Так что Андрей по праву считается одним из сильнейших JVM-щиков в России.



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

Вот о чем мы поговорили с Андреем:

• чего стоит переезд с Java 7 на Java 8;
• что происходит с sun.misc.Unsafe;
• архитектура Одноклассников;
• инженерные компромиссы, шардинг и GC;
• системы хранения данных и Cassandra;
• в чем Одноклассники впереди планеты всей, а чему еще стоит поучиться у Google;
• как стать крутым системным программистом.

(Я знаю, что начало затянутое. Будем работать над тем, чтобы быстрее раскачиваться и входить в тему.)

Для тех, кому опять некогда смотреть видео, под катом расшифровка интервью.

Конференции бывают разные. Некоторые собирают огромные толпы зрителей, другие могут быть интересны лишь полутора специалистам.

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

На самом деле, пост не о том.

Так уж вышло, что мне довелось выступать на означенной конференции, где я на пальцах и с приплясываниями рассказывал, что такое LLVM, чем интересна нотация SSA, что такое IR код и, наконец, как так получается, что детерменированные на первый взгляд C++ программы, оказывается, провоцируют неопределенное поведение.

Кстати, этот доклад можно поставить пятым номером в серии статей про виртуальную машину Smalltalk. Многие просили подробнее рассказать о LLVM. В общем, убиваем всех зайцев сразу. Заинтересовавшимся, предлагаю «откинуться на спинку кресла», опционально налить чего-нибудь интересного и послушать. Обещаю, что больше часа времени я не отниму.

Ах да, под катом можно найти пояснения тех моментов, которым не было уделено должное внимание на конференции. Я постарался ответить на часто задаваемые вопросы и детально разобрать листинги LLVM IR. В принципе, текстовую часть статьи можно читать как самостоятельное произведение, тем не мене я рассчитывал на то, что читатель обратится к нему уже после просмотра видео.

После небольшого перерыва продолжаем разговор о безопасности UEFI. В этот раз речь пойдет о технологии SecureBoot, ее преимуществах и недостатках, об атаках на нее и защите от них.

Впервые о SecureBoot речь зашла в стандарте UEFI 2.2 в 2011 году, но окончательно все аспекты были реализованы в версии 2.3.1C в начале 2012 года. Основным разработчиком технологии была Microsoft, которая сразу же заявила, что для получения сертификата Windows 8 Ready для своей еще не выпущенной новой ОС требуется реализация и включение SecureBoot по умолчанию на всех новых ПК. Это заявление вызвало волну резкой критики со стороны сторонников свободного ПО, которая успешно докатилась и до Хабра.
Если вам интересно, чем именно закончилось противостояние MS и сообщества, как SecureBoot выглядит после почти 4 лет взросления, и какие атаки на него все еще возможны — добро пожаловать под кат.

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