Зачем это нужно и как реализовать программно

Много рассуждений

В предыдущей статье про настройку док-станций, я упоминал как тяжко, в свое время, мне было пользоваться лаптопами «потребительского» сегмента. Отсутствие docking-port'a и необходимость каждый раз по приходу домой или на работу подключать кучу кабелей — все это неприятно и раздражало, но что действительно вызывало страдания, так это отсутствие трекпоинта: той самой «красной пимпочки», которую можно встретить на лаптопах от IBM/Lenovo (синяя или серая в случае HP и DELL). Подробней можно почитать на той же Википедии.

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

Вступление

В статье описывается способ проброса физических устройств из гипервизора KVM в гостевую ОС с помощью технологии VFIO, реализованной в linux kernel 3.9.*.
Материал не является руководством к действию (прим. туториалом). Все описанные инструкции вы производите на свой страх и риск.

Эксперимент выполняется под ОС Ubuntu 13.10:

• kernel: 3.11.0-15-generic
• qemu: 1.5.0
• seabios: 1.7.3

Аппаратная часть стенда:

• мат. плата: AMD990FX
• процессор: AMD FX-8120
• опер. память: DDR3 PC3-14900
• видеокарта: ATI RADEON HD 7750
• видеокарта (гость): NVIDIA GTX560-TI

Видеокарта для гостевой системы и хоста, может быть, предположительно, любая (NVIDIA, ATI RADEON).
Материнская плата должна иметь блок управления памятью ввода/вывода (IOMMU) — технология AMD-Vi или VT-d.
Если используется процессор Intel, то он также должен поддерживать VT-d.
Независимо от выбранной платформы в биосе материнской платы должны быть реализованы IVRS/DMAR таблицы.

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

Всем, доброго времени суток.

По сути, к реализации этой маленькой автоматизации меня сподвигла лень.

Собственно, с чего все началось.

У меня есть ноутбук с установленной gentoo, и i3wm оконным менеджером. Так же есть несколько мониторов(дома, на работе и т д). Разрешения на всех мониторах разные, способы подключения тоже (VGA, HDMI, DVI) разные. Активно, использую первые два.

Раньше, при подключении второго монитора, приходилось вызывать команды, которые инициализировали этот самый монитор. Запуск команды с автоматическим ключом, не всегда давал, желаемого результата(не угадывал разрешение).

xrandr --auto

Потому, приходилось запускать эту же команду, но с набором других ключей, разрешение например.

--mode

И хотя, в xrandr для каждого монитора у меня есть несколько вариантов разрешений, есть одно (максимальное для данного монитора, которое удовлетворяет), но на каждом мониторе оно разное(так как сами мониторы разные).

Потому пришлось искать решение…

В прошлой статье про SecureBoot мне очень не хватало возможности сделать снимок экрана при настройке UEFI через BIOS Setup, но тогда выручило перенаправление текстовой консоли в последовательный порт. Это отличное решение, но доступно оно на немногих серверных материнских платах, и через него можно получить только псевдографику, а хотелось бы получить настоящую — она и выглядит приятнее, и вырезать ее каждый раз из окна терминала не надо.
Вот именно этим мы и займемся в этой статье, а заодно я расскажу, что такое DXE-драйвер и как написать, собрать и протестировать такой самостоятельно, как работают ввод с клавиатуры и вывод на экран в UEFI, как найти среди подключенных устройств хранения такое, на которое можно записывать файлы, как сохранить что-нибудь в файл из UEFI и как адаптировать какой-то внешний код на С для работы в составе прошивки.
Если вам все еще интересно — жду вас под катом.

Intro

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

SystemC это библиотека для C++ позволяющая моделировать всевозможные аппаратные системы на различном уровне абстракции. Поддерживается как традиционное дискретно-событийное моделирование, привычное программистам на Verilog и VHDL, так и аналоговое моделирование в духе SPICE/Verilog AMS. В комплект также входит библиотека и методология для виртуального прототипирования, библиотеки для написания тестовых окружений и верификации с использованием рандомизированных тестов.

В этой я расскажу о синтезируемом подмножестве SystemC, сравнивая его с синтезируемым SystemVerilog. Сам я пользуюсь SystemC уже где-то 3 года, а до этого несколько лет писал на Verilog/SystemVerilog. Попытаюсь охватить предмет с разных сторон: начиная с философских рассуждений о причинах возникновения SystemC, краткого обзора экосистемы и инструментария и заканчивая практическими примерами синтаксиса и семантики.

Подразумевается, что читатели знакомы с Verilog и C++.

Для меня красота C++ заключается, в первую очередь, во вседозволенности и ужасающей мощи языка. Мы можем работать с памятью так же плотно, как и в C, и в то же время имеем такие средства абстракции, как шаблоны и STL, где параметризовать можно что угодно и чем угодно.
Плата за это соответствующая — не всегда вразумительные ошибки компилятора (попробуйте забыть поставить точку с запятой после определения класса), очень большой срок подготовки и обучения программистов, но самое главное — некоторые баги становятся заметными только во время исполнения программы.
Мы хотим больше полезных ворнингов до запуска наших программ. Одно из средств получения желаемого — статический анализ кода. Статический — значит, не запуская программу. Интересны не только вероятные ошибки, случаи undefined behaviour, утечки памяти, но и вещи вроде недоступности/неиспользуемости кода, рекомендации по повышению интуитивности стиля программирования.

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Лирика

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

Большую часть своего компьютерного стажа я пользуюсь лаптопами так называемой «бизнес серии»: IBM ThinkPad 600, HP-Compaq nc2400, Lenovo ThinkPad X61T, Lenovo ThinkPad X220.



Были кратковременные перерывы, когда приходилось перебиваться абы-чем, то бишь компьютерами потребительского сегмента: Apple ibook G4 и Acer aspire 5112 и именно в эти моменты приходило понимание того, как сильно не хватает таких очевидных и привычных вещей, как трекпоинт и док-станция.

В последнее время я вижу, как довольно большое количество людей применяет контейнерную виртуализацию только для того, чтобы запереть потенциально небезопасное приложение внутри контейнера. Как правило, используют для этого Docker из-за его распространенности, и не знают ничего лучше. Действительно, многие демоны первоначально запускаются от имени root, а далее либо понижают свои привилегии, либо master-процесс порождает обрабатывающие процессы с пониженными привилегиями. А есть и такие, которые работают исключительно от root. Если в демоне обнаружат уязвимость, которая позволяет получить доступ с максимальными привилегиями, будет не очень приятно обнаружить злоумышленников, уже успевших скачать все данные и оставить вирусов.
Контейнеризация, предоставляемая Docker и другим подобным ПО, действительно спасает от этой проблемы, но также и привносит новые: необходимо создавать контейнер для каждого демона, заботиться о сохранности измененных файлов, обновлять базовый образ, да и сами контейнеры часто основаны на разных ОС, которые необходимо хранить на диске, хотя они вам, в общем-то, и не особо нужны. Что делать, если вам не нужны контейнеры как таковые, в Docker Hub приложение собрано не так, как нужно вам, да и версия устарела, SELinux и AppArmor кажутся вам слишком сложными, а вам бы хотелось запускать его в вашем окружении, но используя такую же изоляцию, которую использует Docker?

Capabilities

В чем отличие обычного пользователя от root? Почему root может управлять сетью, загружать модули ядра, монтировать файловые системы, убивать процессы любых пользователей, а обычный пользователь лишен таких возможностей? Все дело в capabilities — средстве для управления привилегиями. Все эти привилегии даются пользователю с UID 0 (т.е. root) по умолчанию, а у обычного пользователя нет ни одного из них. Привилегии можно как дать, так и отобрать. Так, например, привычная команда ping требует создания RAW-сокета, что невозможно сделать от имени обычного пользователя. Исторически, на ping ставили SUID-флаг, который просто запускал программу от имени суперпользователя, но сейчас все современные дистрибутивы выставляют CAP_NET_RAW capability, которая позволяет запускать ping из-под любого аккаунта.
Получить список установленных capabilities файла можно командой getcap из состава libcap.

% getcap $(which ping)
/usr/bin/ping = cap_net_raw+ep

Флаг p здесь означает permitted, т.е. у приложения есть возможность использовать заданную capability, e значит effective — приложение будет ее использовать, и есть еще флаг i — inheritable, что дает возможность сохранять список capabilities при вызове функции execve().
Capabilities можно задать как на уровне ФС, так и просто у отдельного потока программы. Получить capability, которая не была доступна с момента запуска, нельзя, т.е. привилегии можно только понижать, но не повышать.
Также существуют биты безопасности (Secure Bits), их три: KEEP_CAPS позволяет сохранить capability при вызове setuid, NO_SETUID_FIXUP отключает перенастройку capability при вызове setuid, и NOROOT запрещает выдачу дополнительных привилегий при запуске suid-программ.

Не часто возникает необходимость создать свой итератор и хотелось бы иметь под рукой небольшой HowTo. В этой заметка хочу рассказать как создать простейший итератор, который можно использовать в стандартных алгоритмах типа std::copy, std::find. Какие методы и определения типов нужны в классе контейнере, чтобы его можно было обходить в циклах for из c++11 и BOOST_FOREACH.

И вновь в нашем блоге репортаж с выставки Металлообработка-2015 — самой крупной выставки, посвященной станками для различных видов обработки металла. 32 страны, более 900 экспонентов, из которых 400 — российские компании, тысячи станков, сотни тонн металла, литры эмульсии и килограммы стружки. Было весело!



В этот раз мы посетили все 7 павильонов, и поэтому одна часть вместе с гифками весит почти 50 мегабайт.
Товарищ! Будь осторожен с трафиком, заходя под кат!

Это первая часть статьи. Читайте вторую часть тут.

Перевод поста Виталия Каурова "Automating xkcd Diagrams: Transforming Serious to Funny".
Скачать файл, содержащий текст статьи, интерактивные модели и весь код, приведенный в статье, можно здесь.
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

---

Утром в понедельник я наткнулся на интересный вопрос, опубликованный в Mathematica Stack Exchange, с нехитрым заголовком — "создание графиков в xkcd-стиле". Из-за популярности веб-комиксов xkcd Рэндалла Манро (Randall Munroe), я ожидал, что люди добавят себе несколько закладок этой страницы и с десяток up-vote. Тогда я ещё не знал, как всё обернётся. Сложно предсказать вирусность какого-то мема, однако если удалось создать такой, то весьма здорово наблюдать, как растёт его популярность и как он распространяется в интернете. Через два дня этот пост имел уже более 100 тысяч просмотров, двести up-vote и 150 закладок; стали возникать ответы и схожие посты в других разделах Stack Exchange, в Twitter разразился небольшой ураган по этому поводу, появлялись обсуждения в Hacker News и reddit. Тут я приведу оригинал поста Amatya с примером изображения в xkcd-стиле:

«Я получил электронное письмо, на которое я захотел ответить с графиком в xkcd-стиле, но я не мог справиться с этим. Всё, что я рисовал, выглядело как надо, однако я не мог придумать такой команды для Plot Legends, чтобы сделать фрагменты текста плавающими. Может, есть какие-то идеи, как можно было бы создать графики в xkcd-стиле? Когда всё выглядит рисованным от руки и неточным. Думаю, рисование таких странных кривых в Mathematica должно быть трудным в реализации.»

В преддверии выставки Computex 2015 наша компания выпустила статью о новом, еще более мощном мини-компьютере. Но так ли легко было нам, разработчикам этого продукта? Сколько бессонных ночей стоила эта разработка инженерам, сколько проблем пришлось решить и подводных камней обойти? В этой статье нам хотелось бы рассказать о самом начале этого пути, это был 2009 год, «мы выживали как могли». Я думаю, дорогой читатель, Вам будет интересно почитать, какие грабли и с какой силой нас колошматили за время создания первой платы.

Суффиксное дерево – мощная структура, позволяющая неожиданно эффективно решать мириады сложных поисковых задач на неструктурированных массивах данных. К сожалению, известные алгоритмы построения суффиксного дерева (главным образом алгоритм, предложенный Эско Укконеном (Esko Ukkonen)) достаточно сложны для понимания и трудоёмки в реализации. Лишь относительно недавно, в 2011 году, стараниями Дэни Бреслауэра (Dany Breslauer) и Джузеппе Италиано (Giuseppe Italiano) был придуман сравнительно несложный метод построения, который фактически является упрощённым вариантом алгоритма Питера Вейнера (Peter Weiner) – человека, придумавшего суффиксные деревья в 1973 году. Если вы не знаете, что такое суффиксное дерево или всегда его боялись, то это ваш шанс изучить его и заодно овладеть относительно простым способом построения.

RAII – одна из наиболее важных и полезных идиом в C++. RAII освобождает программиста от ручного управления ресурсами, без неё крайне затруднено написание безопасного с точки зрения исключений кода. Возможно, самое популярное использование RAII – это управление динамически выделяемой памятью с помощью умных указателей, но она также может с успехом применяться и к другим ресурсам, особенно в мире низкоуровневых библиотек. Примеры включают в себя дескрипторы Windows API, файловые дескрипторы POSIX, примитивы OpenGL и тому подобное.

Данная статья посвящена описанию работы с пакетом PGFPlots, разработанного для популярной настольной издательской системы LaTeX. Однако, если вы даже не знакомы с последней, это не повод расстраиваться и бросать чтение этой статьи, ведь, возможно, те замечательные примеры, которые будут далее приведены, и необычайная мощность и удобство PGFPlots вдохновят вас на изучение LaTeX.

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

Собственно через регулярные выражения я к ним и пришёл.

Я работаю тестировщиком уже не первый год и хочу написать о некоторых бюрократических способах взаимодействия тестировщиков с разработчиками через баг-трекер.

1. Пинг-понг (малоэффективный способ, вызывает претензии руководства)

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

2. Недофикс

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

Если поверифаить оригинальный баг, возможна ситуация, когда в результате фикса второго бага кнопка пропадет в первом месте, а мы это пропустим.