Pull to refresh

Comments 9

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

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

И да, где тут реверс-инжиниринг (если взять код из SVN — реверс-инжиниринг, то я — трамвай) и C++?
Заголовок авторский, статья — перевод, автор с удовольствием ознакомится с Вашей обратной связью по электронной почте.

баянную ошибку

Кому-то баян, а кому-то в новинку. Туториал же.
Я лингвист никудышный, но заголовок:
How do security issues happen?

В данном контексте означает «Как [здесь просится вписать „у нас“] возникли проблемы с безопасностью», что лучше соответствует содержанию статьи.
Это же мода такая: дать громкий заголовок, наделать кучу левых тегов, в начало темы воткнуть интригующую картинку и налить воды в содержание.
Наиболее распространенный вид тем на БХ.
Да уж. Правда, после того, как продемонстрировали OpenSSH Heartbleed, нас уже ничем не удивить…
Интересно, почему до сих пор SVN, почему не git.

И еще интересна была бы статья или хотя бы описание того, как именно работают эти «перехватчики исключений» на уровне ассемблера. А то магия какая-то.
Про git отвечу анекдотом:
Сидит папа-программист за компьютером. Подходит сынишка и спрашивет:
— Папа, почему солнышко утром всходит, а вечером заходит?
Папа нехотно отрывается от монитора…
— А ты проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день?
— Да, каждый день.
— Тебя устраивает?
— Да, устраивает.
— Тогда ради бога, сынок, ничего не трогай и ничего не меняй!!!


Просто потому, что SVN работает, и это не сбоку примочка, а компонент, глубоко интегрированный в нашу инфраструктуру. А если ну очень хочется, то рид-онли зеркало кода на гите у нас есть.

На гит мы возможно перейдем, но позже. К примеру, смена билдсистемы с rbuild на cmake у нас заняла не менее года, оказалось очень много скрытых нюансов.
Сорри коллеги. Мне не нравится код ни до ни после исправления (

Конечно я может быть не понимаю всех нюансов кодирования на уровне ядра, но все же… функция очень длинная, я бы разделили ее на три по одной для каждого из поддерживаемых значений ThreadInformationClass и вызывал их из NtUserSetInformationThread.

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

ThreadHandle используется не во всех кейсах switch-а, я бы делал вызов ObReferenceObjectByHandle(ThreadHandle, ...) только по необходимости и только для тех ThreadInformationClass для которых он действительно нужен, и опять же после проверки аргументов.
Зачем захватывать ресурсы которые не нужны?

Сообщение ERR(«Shutdown initiated\n») на самом деле не всегда будет говорить правду. Потому что если аргументы не пройдут проверку UserInitiateShutdown() не будет вызван и соотвественно сообщение Shutdown initiated в логах будет говорить не правду.

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

И эта функция не единственная где есть похожие проблемы (

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

Как то так… Может быть я и не прав.
Sign up to leave a comment.