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

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

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

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

Продолжаем говорить о безопасности UEFI, на этот раз речь пойдет об атаках на NVRAM и защите от них.
Неплохая, казалось бы, идея о том, что на микросхеме SPI можно хранить настройки практически вечно, не полагаясь на ненадежную и зависящую от батарейного питания CMOS SRAM, сыграла с разработчиками UEFI весьма злую шутку, теперь NVRAM с каждой новой версией стандарта обрастает все большим количеством костылей и подпорок, и конца этому процессу не видно. Если вам интересно, что именно пытаются подпереть костылем — эта статья для вас.
По традиции, всех, кто еще по каким-то причинам не читал первые три части — рекомендую начать с них, остальных с нетерпением жду под катом.

Продолжаем разговор о безопасности UEFI.
На этот раз речь пойдет об опубликованной в конце 2014 года серьезной уязвимости в реализации ACPI S3 (Sleep Mode), ее эксплуатации и последствиях. Основная «фишка» этой уязвимости в том, что она вскрыла целый класс проблем безопасности UEFI, вообще не считавшихся до этого проблемами, и потому и заслуживает отдельной статьи.
Тем, кто не читал предыдущие статьи цикла — раз и два, предлагаю прочесть сначала их, остальных жду под катом.

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

Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.

В попытках подмонтировать MS Onedrive в линуксе возникла мысль — а какие вообще бывают облака, которые нормально монтируются в папку и при этом предлагают максимальный объем? Ниже — небольшой список сервисов и впечатления от попыток примонтировать их.
Сразу скажу — это все делалось только для удовлетворения любопытства, а не для последующего использования — потому не могу сказать, как себя поведут предложенные решения в долговременном плане. Но, возможно, кому-то будет полезно.
Облака выбирались по двум параметрам — максимальный бесплатный объем (желательно получаемый без нескольких десятков регистраций по вашей реферральной ссылке) и возможность монтирования в папку под линуксом.

Процесс тестирования состоял из
1) Регистрация или вспоминание пароля (если я уже был зарегистрирован на этом сервисе)
2) Попытка добавить свободное место по реферральной ссылке — чтобы проверить, как выглядит процесс и насколько просто самостоятельно «накрутить» себе место.
3) Попытка подключить облако в папку под линуксом (там, где работает WebDAV — использовал davfs2, где не работает — другие доступные варианты).
4) Если попытка удачная, то несколько попыток загрузить разные файлы — какая-нибудь мелочь в пределах мегабайта, 50-70 мегабайт и 1,6 гигабайта.
Эксперименты производились на hetzner'овском VPS с одним ядром и гигабайтом оперативки (debian stable).

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

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

Жизнь мальчиков с математическими способностями в атомных городах была предопределена — школа с пятерками по алгебре и геометрии, мех-мат столичного университета, возвращение в систему, квартира через год, кандидатская степень в 40 лет, ВАЗ 2103 к пятидесяти годам, звание доктора, гараж, шесть соток, четыре квадратных метра.

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



Далее я проваливаюсь в историю компьютерной игры.
Под тегом личные воспоминания ветерана без ссылок, рекламы, картинок и кода.
Спасибо за чудесные комментарии, парни.

С каждым днем слово java все больше и больше воспринимается уже не как язык, а как платформа благодаря небезызвестному invokeDynamic. Именно поэтому сегодня я бы хотел поговорить про виртуальную java машину, а именно — об так называемых Performance опциях в Oracle HotSpot JVM версии 1.6 и выше (server). Потому что сегодня почти не встретить людей, которые знают что-то больше чем -Xmx, -Xms и -Xss. В свое время, когда я начал углубляться в тему, то обнаружил огромное количество интересной информации, которой и хочу поделится. Отправной точкой, понятное дело, послужила официальная документация от Oracle. А дальше — гугл, эксперименты и общение:

-XX:+DoEscapeAnalysis

Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Как многие из Вас знают, примитивы и ссылки на объекты создаются не в куче, а выделяются на стеке потока (256КБ по умолчанию для Hotspot). Вполне очевидно, что язык java не позволяет создавать объекты на стеке на прямую. Но это вполне себе может проделывать Ваша JVM 1.6 начиная с 14 апдейта.

Про то, как работает сам алгоритм можно прочитать тут (PDF). Если коротко, то:

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

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

• GlobalEscape — объект доступен из других потоков и из других методов, например статическое поле.
• ArgEscape — объект был передан как аргумент или на него есть ссылка из объекта аргумента, но сам он не выходит из области видимости потока в котором был создан.
• NoEscape — объект не покидает область видимости метода и его создание может быть вынесено на стек.

После этапа анализа, уже сама JVM проводит возможную оптимизацию: в случае если объект NoEscape, то он может быть создан на стеке; если объект NoEscape или ArgEscape, то операции синхронизации над ним могут быть удалены.

Следует уточнить, что на стеке создается не сам объект а его поля. Так как JVM заменяет цельный объект на совокупность его полей (спасибо Walrus за уточнение).

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

    for (int i = 0; i < 1000*1000*1000; i++) {
        Foo foo = new Foo();
    }

скорость выполнения может увеличится в 8-15 раз. Хотя, на казалось бы, очевидных случаях из практики о которых недавно писалось (тут и тут) EscapeAnalys не работает. Подозреваю, что это связано с размером стека.

Кстати, EscapeAnalysis как раз частично ответственен за известный спор про StringBuilder и StringBuffer. То есть, если Вы вдруг в методе использовали StringBuffer вместо StringBuilder, то EscapeAnalysis (в случае срабатывания) устранит блокировки для StringBuffer'а, после чего StringBuffer вполне превращается в StringBuilder.

Приветствуем тебя, хабрасообщество.

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



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

У многих администраторов voip-сетей, сталкивающихся с sip-серверами слова ser, openser, kamailio, opensips вызывают по меньшей мере головокружение. Почему их так много? Почему так похожи? Какие активно развиваются, а какие уже нет? Какой в конце-концов выбрать?

Привет, %username%!

В процессе администрирования Asterisk PBX рано или поздно возникает необходимость маршрутизации звонков по направлениям и чаще всего это: город, МН, внутризоновая связь, МГ. С первыми двумя все ясно. А вот последние два… Ну и что здесь сложного скажете Вы? Уже написан вагон и маленькая тележка статей и скриптов по поводу составления регулярных выражений по DEF и ABC кодам, но периодически приходится обновлять все эти регулярки. И тут возникла мысль, а можно ли это автоматизировать. К сожалению чего-то готового, а главное подходящего найти не удалось. Значит будем изобретать свой велосипед.