Ну да, речь то всего лишь идет о компетентных (наверное самых компетентных, которых вообще можно найти в линукс мире) админах, mission critical серваке, на котором крутится минимум служб. Скукота.
Вот когда какой нибудь винлокер пользователи себе сами ставят (еще и лицензию принимают, которая подробно описывает что произойдет) — это да. Это стоит подробно обсудить.
Ну да, никогда. Ведь проще объявить ОС безопасной, чем действительно сделать ее такой. Вообще то против троянов на сервере уже давно есть средство. Да и SDL пора бы внедрять. С обязательным моделированием угроз, статическим и динамическим анализом кода, fuzz-тестированием, независимым секьюрити-ревью всех фич и пр… Всяко лучше, чем надеяться на ManyEyes™, которые даже существующие юниттесты иногда не могут запустить.
В смысле «что»? Достоверное известно, что у злоумышленников был root на Hera — это основном kernel.org сервере. Есть подозрения, что бекдоры есть и на других серверах.
А вообще подобного не должно быть вообще. Как вообще можно держать mission critical сервер без цепочки доверия (TPM + полноценный контроль целостности кода)?
Если им понадобилось три недели и счастливая случайность чтоб обнаружить тупой авторан троян (rc3.d демон) даже без руткит компоненты, то где гарантия того, что там не осталось полноценных руткитов?
Если немного углубиться в конспирологию, то будь я злоумышленником, я бы наверное оставил один-два простеньких трояна на поверхности, чтоб их нашли и успокоились, и закопал бы парочку крайне труднообнаружимых.
> И бесполезная
А вот ни фига. Я вообще смутно понимаю любовь к закату солнца вручную как самоцель. Ну вот low level разработчики гоняют байты для того, чтоб было быстрее/меньше по размеру. А зачем гонять вручную s-выражения в стиле define-macro/defmacro? Зачем ручная гигиена, если она нужна в подавляющем большинстве случаев и удобнее как раз ее вручную нарушать при необходимости? Какие преимущства это дает?
Как по мне, люди, предпочитающие defmacro-style макросы просто расписываются в своей неспособности понимать/создавать абстракции (в данном случае синтаксические).
С другой стороны, как же уже хочется нормальных макросов в мейнстриме (желательно нативном). Хотя бы и с ручным закатыванием солнца.
Что реально выделяет схему из большинства других языков, так это очень изящная макросистема и call/cc
А то что описано здесь — баловство, доступное первокурснику с LINQ. Никакого особенно «впечатления» не производит
> Не смог найти ничего конкретного по завершению сделки. 1:11:23:
Skype!.. Subject to regulatory approval.
Skype. I gotta be careful here because we are in the middle of the regulatory process…
--Steve Ballmer, July 11, 2011
Сделка еще не закрыта, но даже после того как (если) закроется, там еще месяцы и месяцы на интеграцию всего этого добра с майкрософтовскими процессами разработки.
Офсайт вообще ничего не говорит о финансовых деталях сделки (кроме того, что это позволит экономить полмиллиона в год).
Другие источники обычно говорят о «university will receive $250,000 in incentives from Microsoft». Incentives — это не cash, это чаще всего скидки на софт/сервисы. Фактически это обычная практика: «первый год со скидкой».
То есть, вы не считаете, что вызов функций 'в столбик', абзацы кода очень часто длиной всего в 3-4 строки, и прочее, в том числе и комментарии…
Не совсем понял, что такое «вызов функций 'в столбик'», но короткие абзацы и тщательное комментирование — это только плюс. В WRK этого комментария нет, но я тем не менее соглашусь, что бессмысленные комментарии вполне могут быть — просто их количество исчезающе мало.
Во-первых, известно, что для таймеров можно добиться сложности O(1) в худшем случае на всех операциях, кроме его создания.
Ну так здесь оно и есть. Не совсем понятно, что Вы имеете в виду под «созданием» — если просто выделение памяти то оно тоже может иметь (амортизированную) константную сложность. Если же вставку, то все зависит от ворклоада. В данном случае сложность зависит как от количества уже присутствующих таймеров, так и от того, сколько осталось времени до срабатывания, что на большинстве реальных ворклоадов даст сложность, близкую к константной для большинства таймеров (реальное распределение дать не могу)
Во-вторых, про таймеры, особенно KiInsertTimerTable… Не нашёл никаких упоминаний о указанных Вами таблицах.
Это из WRK (Server 2k3) — задолго не только до упомянутой Вами семерки, но и задолго до висты.
Но это список, и о каком логарифме идёт речь — не понятно. А для таймеров, вообще-то, стандартный примитив — это куча, а не списки или хэш-таблицы.
Для кучи опять таки имеем гарантированный логарифм на вставку (и, что еще хуже, на ИЗВЛЕЧЕНИЕ минимального элемента) при любом ворклоаде вместо гарантированной константы на извлечение и константы на вставку при реалистичном ворклоаде (и линейной сложности для худшего случая). Подобные компромиссы делаются кругом — вспомнить хотя бы очень популярный quick sort.
NTSTATUS'ы — это, насколько я понял, вообще никакие не цепочки…
Имелось в виду
if (!NT_SUCCESS(status)) {
// cleanup
return status;
}
И так во всех функциях по цепочке — полностью ручной менеджмент ресурсов — никаких исключений, только возврат/проверка статусов. Причина проста: обработка исключения — значительно более дорогая операция, чем возврат значения из функции.
Я действительно не понимаю, где происходит освобождение захватов в таких случаях (я так честно и написал — не понимаю, и это меня напрягает).
Блок finally гарантированно выполняется — хоть при исключении, хоть при обычном выходе из try блока. Все финализаторы (в том числе и освобождение блокировок) находятся там. Но, повторюсь, это крайне редкая штука (в Вашем же примере весь Ke модуль не содержит ни одного finally блока).
о что try-except редко или часто используются — это не важно (но вообще, 335 точек try-except — это солидно на 150 тысяч строк MS-кода. Во всём Half-Life 2 и то меньше.
А насколько часто «всему Half-Life 2» приходится проверять доступность блока памяти, переданной из untrusted источника? Основное применение, как я уже написал, это try {ProbeForRead/ProbeForWrite} except {return STATUS_ACCESS_VIOLATION;}
Более того, данная конструкция чаще всего завернута в if (PreviousMode != KernelMode) {} и лишняя работа не выполняется, если источник данных доверенный (ядро).
Важно то, как они используются… И я, сколько не копался, так и не нашёл мест освобождения захватов после исключений.
Можно хотя бы один пример? Я не смог найти примеров выбрасывания исключений с захваченными блокировками. Не потому, что такую ситуацию трудно обработать, а потому, что бросок/обработка исключения — относительно дорогая операция и совершенно необязательно удерживать блокировку в течение всего времени обработки. Аргументы чаще всего валидируются до того, как делается любая другая работа.
Вот пример освобождения ресурсов при броске исключения:
#if defined(_WIN64)
if (requestorMode != KernelMode) {
try {
//
// If this is a 32-bit asynchronous IO, then mark the Iosb being sent as so.
// Note: IopMarkApcRoutineIfAsyncronousIo32 must be called after probing
// the IoStatusBlock structure for write.
//
IopMarkApcRoutineIfAsyncronousIo32(IoStatusBlock,ApcRoutine,FALSE);
} except (EXCEPTION_EXECUTE_HANDLER) {
//
// An IRP could not be allocated. Cleanup and return an appropriate
// error status code.
//
IopAllocateIrpCleanup( fileObject, eventObject );
if (auxiliaryBuffer) {
ExFreePool( auxiliaryBuffer );
}
return GetExceptionCode ();
}
}
#endif
Если этот пример недостаточно показателен — дайте пример кода, в котором Вам непонятно где происходит освобождение ресурсов (в том числе захваченных блокировок, как одной из разновидностей ресурсов).
Ну, людей вообще-то на любую работу отбирают…
Но везде критерии отбора разные.
А вот Ваша уверенность в том, что Катлер — гений, интересна. Почему Вы так думаете?
По тому, насколько мало подвержен его дизайн гниению (design rot). На конец 80-х имеем: поддержку юникода в ядре, полностью асинхронный ввод/вывод, ACL-ы, поддерку SMP (полностью реентрабельное ядро с кучей воркеров), файловую систему с минимальным количеством различных сущностей и потрясающей расширяемостью (вот по качеству дизайна с этой ФС 20-летней давности могут соперничать разве что современный BTRFS/ZFS, а HFS+ и ext4 даже рядом не валялись).
Не говоря уже об очень изящном меморе менеджменте, отсутствии привязки к POSIX, даже при том, что POSIX-совместимость была в изначальных требованиях (забавно, что как раз Windows-совместимости в этих требованиях не было), отличной модульности (нет, речь не о загружаемых модулях) и куче прочих ништяков
Наткнулся на этот комментарий. Думал отвечать или нет, но все же отвечу.
Во-первых, люди старательно увеличивают количество строк кода везде, где это возможно
Нет там такого нигде. Все тщательно прокомментировано (но без идиотизма о котором Вы пишете). Код по возможности сделан как можно понятнее: надо завести временную переменную и дать ей длинное читаемое имя — заводим и предоставляем компилитору возможность ее соптимизировать. Вообще очень приятно читать код (в отличие от того же ядра линукса — да)
Во-вторых, очень часто используются сомнительные по эффективности алгоритмы. Например, почти везде понатыканы очереди, в которых почти везде осуществляется линейный поиск. При чём это даже в тех компонентах, которые заявлены как realtime. В таймерах, например
Вы, похоже, просто не разобрались в том, как релизованы эти самые таймеры. Списки используются в основном в очередях — там, где основная операция это вставка/удаление в/из хвост/голову. Там где нужен эффективный доступ по ключу используются Generic table-ы. Ну а таймеры реализованы как раз на хэш таблице (внимательно посмотрите на функцию KiInsertTimerTable). Вставка в сортированный список зависит от значения: более «близкие» таймеры будут вставляться быстрее, а выборка таймера, который сработал производится всегда за константное время. Собственно это наверное самый эффективный алгоритм, который можно придумать для таймеров. Вместо «всегда логарифм» в случае реализации на дереве имеем «константный поиск» и «практически всегда константная вставка».
В-третьих, лично меня напрягает то, что даже в самом ядре ядра (которое Ke) обработка ошибок сделана на исключениях. При этом, когда исключение возникает, стек разворачивается без освобождения захваченных ресурсов, просто передаётся управление на обработку исключения
Во-первых, исключения там как раз используются очень редко — в основном для отлова аппаратных исключений (проверка доступна ли память, переданная из юзермода, например) — для ошибок исполнения используются цепочки NTSTATUS-ов, ну а во-вторых это просто еще один механизм, в котором Вы, похоже, не разобрались. В подавляющем большинстве случаев исключение не пересекает границы функции: try {ProbeForXxx} except и выход. В редких случаях, когда исключение все таки выходит — очистка производится при помощи finally
Может, отвратительно — это и слишком резко сказано, но когда смотрю на этот код, мне его хочется править и править, чтобы он не вызывал такую степень отторжения у меня.
Ой не стоит. Перед тем как править какой нибудь код его стоит сначала понять.
Обычное ПО, написанное обычными людьми, со своими косяками и находками. Ничего особо гениального, горшки не боги обжигают.
Ну во первых не такие уж обычные — отбор все таки работает. А во вторых, изначальная команда Катлера — практически гении, а он сам — так точно гений.
Не знаю, что изображено у ВАС на графике, но вот:
Google Finance:
Bing Finance:
И, кстати, зачем сравнивать стоимость одной акции? Чтобы показать что у MSFT было больше сплитов, чем у AAPL (зелененькое на графиках внизу)? Ну так все, кто интересуется вопросом это и так знают. А может это было сделано для того, чтобы показать, что «Microsoft is doomed — all hail Apple»? Не вышло. Щасти наступного разу, ага.
MSFT:
AAPL:
PS: Ну и ко всему прочему, Ваша иконографика начинается с w3schools статистики. Очень точно отображает ГЛОБАЛЬНУЮ ситуацию, ага
> Занятно, что демонстратор явно сообщает о том, что будущее PC связано с ARM.
Еще более занятно, что он этого не говорит. И даже не говорит ничего, что можно было бы расценить как вышеприведенную фразу. Единственное место, где в данном ролике вообще упоминается будущее таково:
«It's really up to you what the next generation of PCs look like. You can build them virtually any size and shape all with the same experience, all being able to run new apps, all being able to run… to have control of the Windows desktop.»
Вот, кстати, полное видео с компьютекса: чуть более продолжительная демонстрация, но на самом деле ничего нового по сравнению с официальным видео «Building Windows 8».
Ни первый ни второй вариант не будет работать. То есть принципиально — с любым количеством «фиксов».
Что в сочетании с претенциозным заголовком и менторским тоном (присущим практически всем материалам Хэккира) вызывает крайне неприятные ощущения.
> Не надо гнать на журнал, обзывать его «хакиром», «ксакепом» и пр. Некрасиво.
Почему же некрасиво? Если этот журнал сам себя позиционировал как Космополитан для wannabe хэккиров.
> Или сделай лучше, найди 0-day уязвимость, напиши охренительную статью и стань героем.
Мдя. Вы серьезно? Может еще и Сони взломать и выложить в инет базу с информацией о юзерах? Одно дело блекхэты, которые, как и прочие преступники, просто зарабатывают бабки, а другое — всякая «воровская романтика», бригады и прочий шлак для инфантильных школьников.
На всякий случай повторю вопрос: Вы действительно считаете публичное раскрытие 0-day уязвимости героизмом?
Более того, даже если отключить Secure Desktop (второе положение снизу) — обычное приложение все еще не сможет посылать ввод elevated приложению.
Remarks:
This function is subject to UIPI. Applications are permitted to inject input only into applications that are at an equal or lesser integrity level.
Ну и второй суперметод — использование уязвимости, запатченной полгода назад? Seriously?
И это при том, что в дефолтной конфигурации UAC таки не является безопасным, но это же ксакеп — откуда им знать информацию, публично доступную уже более двух лет.
Интересно, зачем Вы упорствуете в своей ошибке. Microsoft — это не юзер, а «коллективный юзер», который является координатором всех майкрософтовских проектов. Этот «юзер» никогда ничего не коммитит — коммитят сотрудники этого «юзера» под собственными аккаунтами на codeplex. Оба остальных координатора pshyperv — сотрудники МС (у одного из них это прямо указано в профайле). Этот проект указан в списке
… И по умолчанию такого модуля в PowerShell конечно нет. Microsoft решила что писать командлеты для управления Hyper-V ни кто не будет (действительно дикая затея). С другой стороны этот мир полон людей умеющих и готовых упрощать жизнь себе и другим пользователям. Так на свет и появился PowerShell management Library for Hyper-V.
Ага, как замечательно, что есть такие люди, готовые исправлять недочеты глупого майкрософта. WAIT! Это и есть майкрософтовский проект.
Вот когда какой нибудь винлокер пользователи себе сами ставят (еще и лицензию принимают, которая подробно описывает что произойдет) — это да. Это стоит подробно обсудить.
Ну еще и Sony на своих серверах Linux держит.
Хотя в целом да — ничего экстраординарного.
> сразу догадались
[Шутка про эстонских разработчиков].
А вообще подобного не должно быть вообще. Как вообще можно держать mission critical сервер без цепочки доверия (TPM + полноценный контроль целостности кода)?
Если им понадобилось три недели и счастливая случайность чтоб обнаружить тупой авторан троян (rc3.d демон) даже без руткит компоненты, то где гарантия того, что там не осталось полноценных руткитов?
Если немного углубиться в конспирологию, то будь я злоумышленником, я бы наверное оставил один-два простеньких трояна на поверхности, чтоб их нашли и успокоились, и закопал бы парочку крайне труднообнаружимых.
А вот ни фига. Я вообще смутно понимаю любовь к закату солнца вручную как самоцель. Ну вот low level разработчики гоняют байты для того, чтоб было быстрее/меньше по размеру. А зачем гонять вручную s-выражения в стиле define-macro/defmacro? Зачем ручная гигиена, если она нужна в подавляющем большинстве случаев и удобнее как раз ее вручную нарушать при необходимости? Какие преимущства это дает?
Как по мне, люди, предпочитающие defmacro-style макросы просто расписываются в своей неспособности понимать/создавать абстракции (в данном случае синтаксические).
С другой стороны, как же уже хочется нормальных макросов в мейнстриме (желательно нативном). Хотя бы и с ручным закатыванием солнца.
А то что описано здесь — баловство, доступное первокурснику с LINQ. Никакого особенно «впечатления» не производит
1:11:23:
Сделка еще не закрыта, но даже после того как (если) закроется, там еще месяцы и месяцы на интеграцию всего этого добра с майкрософтовскими процессами разработки.
Другие источники обычно говорят о «university will receive $250,000 in incentives from Microsoft». Incentives — это не cash, это чаще всего скидки на софт/сервисы. Фактически это обычная практика: «первый год со скидкой».
Не совсем понял, что такое «вызов функций 'в столбик'», но короткие абзацы и тщательное комментирование — это только плюс. В WRK этого комментария нет, но я тем не менее соглашусь, что бессмысленные комментарии вполне могут быть — просто их количество исчезающе мало.
Ну так здесь оно и есть. Не совсем понятно, что Вы имеете в виду под «созданием» — если просто выделение памяти то оно тоже может иметь (амортизированную) константную сложность. Если же вставку, то все зависит от ворклоада. В данном случае сложность зависит как от количества уже присутствующих таймеров, так и от того, сколько осталось времени до срабатывания, что на большинстве реальных ворклоадов даст сложность, близкую к константной для большинства таймеров (реальное распределение дать не могу)
Это из WRK (Server 2k3) — задолго не только до упомянутой Вами семерки, но и задолго до висты.
Для кучи опять таки имеем гарантированный логарифм на вставку (и, что еще хуже, на ИЗВЛЕЧЕНИЕ минимального элемента) при любом ворклоаде вместо гарантированной константы на извлечение и константы на вставку при реалистичном ворклоаде (и линейной сложности для худшего случая). Подобные компромиссы делаются кругом — вспомнить хотя бы очень популярный quick sort.
Имелось в виду
И так во всех функциях по цепочке — полностью ручной менеджмент ресурсов — никаких исключений, только возврат/проверка статусов. Причина проста: обработка исключения — значительно более дорогая операция, чем возврат значения из функции.
Блок finally гарантированно выполняется — хоть при исключении, хоть при обычном выходе из try блока. Все финализаторы (в том числе и освобождение блокировок) находятся там. Но, повторюсь, это крайне редкая штука (в Вашем же примере весь Ke модуль не содержит ни одного finally блока).
А насколько часто «всему Half-Life 2» приходится проверять доступность блока памяти, переданной из untrusted источника? Основное применение, как я уже написал, это try {ProbeForRead/ProbeForWrite} except {return STATUS_ACCESS_VIOLATION;}
Более того, данная конструкция чаще всего завернута в if (PreviousMode != KernelMode) {} и лишняя работа не выполняется, если источник данных доверенный (ядро).
Можно хотя бы один пример? Я не смог найти примеров выбрасывания исключений с захваченными блокировками. Не потому, что такую ситуацию трудно обработать, а потому, что бросок/обработка исключения — относительно дорогая операция и совершенно необязательно удерживать блокировку в течение всего времени обработки. Аргументы чаще всего валидируются до того, как делается любая другая работа.
Вот пример освобождения ресурсов при броске исключения:
Если этот пример недостаточно показателен — дайте пример кода, в котором Вам непонятно где происходит освобождение ресурсов (в том числе захваченных блокировок, как одной из разновидностей ресурсов).
Но везде критерии отбора разные.
По тому, насколько мало подвержен его дизайн гниению (design rot). На конец 80-х имеем: поддержку юникода в ядре, полностью асинхронный ввод/вывод, ACL-ы, поддерку SMP (полностью реентрабельное ядро с кучей воркеров), файловую систему с минимальным количеством различных сущностей и потрясающей расширяемостью (вот по качеству дизайна с этой ФС 20-летней давности могут соперничать разве что современный BTRFS/ZFS, а HFS+ и ext4 даже рядом не валялись).
Не говоря уже об очень изящном меморе менеджменте, отсутствии привязки к POSIX, даже при том, что POSIX-совместимость была в изначальных требованиях (забавно, что как раз Windows-совместимости в этих требованиях не было), отличной модульности (нет, речь не о загружаемых модулях) и куче прочих ништяков
Нет там такого нигде. Все тщательно прокомментировано (но без идиотизма о котором Вы пишете). Код по возможности сделан как можно понятнее: надо завести временную переменную и дать ей длинное читаемое имя — заводим и предоставляем компилитору возможность ее соптимизировать. Вообще очень приятно читать код (в отличие от того же ядра линукса — да)
Вы, похоже, просто не разобрались в том, как релизованы эти самые таймеры. Списки используются в основном в очередях — там, где основная операция это вставка/удаление в/из хвост/голову. Там где нужен эффективный доступ по ключу используются Generic table-ы. Ну а таймеры реализованы как раз на хэш таблице (внимательно посмотрите на функцию KiInsertTimerTable). Вставка в сортированный список зависит от значения: более «близкие» таймеры будут вставляться быстрее, а выборка таймера, который сработал производится всегда за константное время. Собственно это наверное самый эффективный алгоритм, который можно придумать для таймеров. Вместо «всегда логарифм» в случае реализации на дереве имеем «константный поиск» и «практически всегда константная вставка».
Во-первых, исключения там как раз используются очень редко — в основном для отлова аппаратных исключений (проверка доступна ли память, переданная из юзермода, например) — для ошибок исполнения используются цепочки NTSTATUS-ов, ну а во-вторых это просто еще один механизм, в котором Вы, похоже, не разобрались. В подавляющем большинстве случаев исключение не пересекает границы функции: try {ProbeForXxx} except и выход. В редких случаях, когда исключение все таки выходит — очистка производится при помощи finally
Ой не стоит. Перед тем как править какой нибудь код его стоит сначала понять.
Ну во первых не такие уж обычные — отбор все таки работает. А во вторых, изначальная команда Катлера — практически гении, а он сам — так точно гений.
Google Finance:
Bing Finance:
И, кстати, зачем сравнивать стоимость одной акции? Чтобы показать что у MSFT было больше сплитов, чем у AAPL (зелененькое на графиках внизу)? Ну так все, кто интересуется вопросом это и так знают. А может это было сделано для того, чтобы показать, что «Microsoft is doomed — all hail Apple»? Не вышло. Щасти наступного разу, ага.
MSFT:
AAPL:
PS: Ну и ко всему прочему, Ваша иконографика начинается с w3schools статистики. Очень точно отображает ГЛОБАЛЬНУЮ ситуацию, ага
Еще более занятно, что он этого не говорит. И даже не говорит ничего, что можно было бы расценить как вышеприведенную фразу. Единственное место, где в данном ролике вообще упоминается будущее таково:
«It's really up to you what the next generation of PCs look like. You can build them virtually any size and shape all with the same experience, all being able to run new apps, all being able to run… to have control of the Windows desktop.»
Вот, кстати, полное видео с компьютекса: чуть более продолжительная демонстрация, но на самом деле ничего нового по сравнению с официальным видео «Building Windows 8».
Что в сочетании с претенциозным заголовком и менторским тоном (присущим практически всем материалам Хэккира) вызывает крайне неприятные ощущения.
> Не надо гнать на журнал, обзывать его «хакиром», «ксакепом» и пр. Некрасиво.
Почему же некрасиво? Если этот журнал сам себя позиционировал как Космополитан для wannabe хэккиров.
> Или сделай лучше, найди 0-day уязвимость, напиши охренительную статью и стань героем.
Мдя. Вы серьезно? Может еще и Сони взломать и выложить в инет базу с информацией о юзерах? Одно дело блекхэты, которые, как и прочие преступники, просто зарабатывают бабки, а другое — всякая «воровская романтика», бригады и прочий шлак для инфантильных школьников.
На всякий случай повторю вопрос: Вы действительно считаете публичное раскрытие 0-day уязвимости героизмом?
Remarks:
This function is subject to UIPI. Applications are permitted to inject input only into applications that are at an equal or lesser integrity level.
Ну и второй суперметод — использование уязвимости, запатченной полгода назад? Seriously?
И это при том, что в дефолтной конфигурации UAC таки не является безопасным, но это же ксакеп — откуда им знать информацию, публично доступную уже более двух лет.
Ага, как замечательно, что есть такие люди, готовые исправлять недочеты глупого майкрософта. WAIT! Это и есть майкрософтовский проект.