Муки выбора

Windows лучше чем Linux! Чем? Ясно же написано — чем Linux!
Раздуй свой холивар сегодня, потому что завтра это может сделать уже кто-то другой!

Какой проц/платформу выбрать сейчас?

Intel Core i5-760 Lynnfield 2.8GHz 8MB L3 Cache LGA 1156
13
65%
AMD Phenom II X4 955 Black Edition Deneb 3.2GHz
5
25%
Подождать выхода Sandy Bridge
2
10%
 
Всего голосов : 20

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 10:46

Mikle писал(а):Возможно где-то удобнее иметь > 4гБ одним куском?

Это реже, чем много мелких буферов.

У flat-модели один большой недостаток. Допустим, нам надо выделить буфер размером 1 Гб. А суммарный объём свободного места в АП процесса — 1,99 Гб. Но выделить 1 Гб мы не сможем, потому что АП фрагментировано микроскопическими занятыми участками. И в оставшиеся свободные области этот гигабайтный кусок не вписать — никуда не влазит. И микроскопические области не передвинуть, потому что никто не знает, в скольки местах есть указатели на них.

Вот ещё раньше была крутая вещь (сейчас она признана устаревшей) — это Global-функции. Пока кто-то не вызвал GlobalLock — не важно, где лежит блок в памяти. Дефрагментация виртуального АП возможна.

Ну или другой, но всё тот же по сути, сценарий: всё-таки нам удалось выделить 1 Гб. Но оказалось, что 1 Гб мало, и надо сделать ReAlloc, и выделить 1,05 Гб. И тут облом: хоть у нас 99 % виртуального АП процесса свободно, процесс падает с «Out of memroy». Не потому, что нет нужного количества свободных страниц, а потому что нет диапазона (нужной длины) свободных страниц.

Горе в том, x64 эту проблему не решает. Да, теперь у нас просто гигантское адресное пространство, но теперь и разработчики (которые постоянно деградируют, с ходом времени делая всё больший по размеру плевок на то, как устроен компьютер, разрабатывая так, как будто работают на идеальном сферическом компьютере с бесконечными характеристиками) будут тратить память гораздо более неэкономно. Если нужно было работать с 3 Гб файлом, то горе-разработчик в принципе не мог прочитать его целиком в АП (он туда не влезет), и даже ту часть, что влезет — не мог (потому что съестся весь файл подкачки, скорее всего), он был вынужден применять технически идеальный вариант — маппить файл в АП кусками и работать с ним. В этом случае на диски не создавалось две копии одни и тех же данных (одна в самом файле, другая в файлах подкачки). Теперь разработчик спокоен — он может не то, что маппнуть, а даже загрузить весь этот файл целиком в виртуальное АП.

Кстати, я ещё об этом напишу какую-нибудь статью с рассуждениями, но по моему мнению, ОСи, исповедующие flat-модель для себя и своих процессов, практически полностью загубили идею защищённого режима, основанного на задачах.

Что такое процессорная задача в современных ОС? Это поток в составе процесса. У процессов изолированное АП, но для всех потоков оно общее. Защита, по сути, только одного процесса от чужих процессов. Потоки же в рамках одного процесса могут свободно мочить друг друга, что даёт повод устранивать Core Wars основанный на особенностях архитектуры ОС.

А что такое изначально задача? Это субъект действия защищённого режима. Это выполняющийся код со своими привилегиями и доступам к сегментам. И нужно было воспринимать задачу как асинхронную процедуру.

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

Так вот эта ситуация должна разрешать так: для обработки пришедшего запроса мы создаём новую задачу. Причём «создаём задачу» надо читать не как «создаём новый поток», а как «инициируем вызов асинхронной процедуры». Причём создавающая задача может заснуть на время выполнения созданной, но может и не засыпать (а обрабатывать, например, следующий запрос).

Фишка в том, что когда мы создали задачу для обработки пришедшего от клиента запроса, мы можем указать, чем будет владеть данная задача. И мы наделяем задачу доступом к трём крохотным сегментами:
1) Сегмент с кодом этой задачи.
2) Сегмент, содержащий данные пришедшего запроса.
3) Сегмент, куда нужно записать результаты обработки запроса.

Причём первому сегменту присвоены атрибуты R-E, второму R--, третьего RW-.

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

В текущей реализации есть замечательные фишки от подобных уязвимостей, вроде DEP. Они замечательны сами по себе, но мегаущербны по сравнению с той концепцией обеспечения безопасности, которая могла бы быть реализована. Которую x86 позволяет реализовать (причём уже очень давно).

Ну допустим, я, злобный хакер, записал код в буфер, предназначенный для данных. И перезаписал стек так, чтобы адрес возврата указывал на мой внедряемый хакерский код. Сработал DEP. И что? А ничего — DEP, это исключение, а механизм обработки исключений документирован и полностью доступен прикладному ПО. А значит он не может использоваться для защиты. И конечно его обходят. И кроме того, можно адресом возврата сделать VirtualProtect, которая сделает внедрённый хакерский код легальным (с точки зрения DEP), и дальше всё как по маслу.

Вот сейчас у процесса есть возможность обработки исключений. Если их не обрабатывать, запись или чтение туда/оттуда, куда/откуда нельзя вызывает печально известное сообщение с предложением «Отправить отчёт». Ну, хорошо, а если обрабатывать исключения самому? Хорошо, мы знаем, что наш поток стал писать туда, куда нельзя. Но мы ведь не писал ли перед этим наш вышедший из под контроля поток, туда, куда на деле нельзя, но технически (из-за атрибутов доступа страницы ВАП) вполне себе возможно? Такой гарантии нет, поэтому обычно если такое происходит, и исключение обрабатывается своим обработчиком (а не самым крайним в цепочке SEH-хендлеров, системным), процесс в конечном счёте всё равно завершается, разве что сообщение об ошибке выводится не системное, а кастомное.

Кроме того, вышедший из под контроля поток, записывающий что-то абы-куда может испортить сам код обработки исключения. Может испортить цепочку SEH-хендлеров. Это часто случается: видели, когда процесс, который должен крах-нуться обычным образом (с окном «Отправить отчёт») или вообще завершается безшумно (просто завершается), или не завершается вообще?

* * *

Сейчас модны идеи виртуализации, идеи песочницы во имя обеспечения безопасности. Это выглядит странно, потому что архитектура x86 уже давно несёт эту идею: задача — вот вам песочница. Но современные ОС используют процессорный объект «задача» самым невыгодным с точки зрения использования её потенциальных возможностей образом.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: Муки выбора

Сообщение ger_kar » 29.06.2011 (Ср) 12:18

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 12:20

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

Неиспользование сегментов и использование только двух уровней вызовано идеей сделать кроссплатформенную ОС.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: Муки выбора

Сообщение ger_kar » 29.06.2011 (Ср) 13:54

А если не брать в расчет идею кросс платформенности, то задействование всех четырех уровней дало бы какое-нибудь преимущество?
Хакер писал(а):У flat-модели один большой недостаток
Да про недостатки понятно, но наверняка есть и преимущества, не может же быть все так однобоко, хотелось бы и про положительную сторону узнать.
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 14:00

ger_kar писал(а):А если не брать в расчет идею кросс платформенности, то задействование всех четырех уровней дало бы какое-нибудь преимущество?

Какое-то может быть и дало бы, но вряд ли ощутимое. Смотря как распределить ядро по кольцам.

ger_kar писал(а):но наверняка есть и преимущества, не может же быть все так однобоко, хотелось бы и про положительную сторону узнать.

Простота восприятия программистом. Ненужность FAR-указателей.
Какие могут быть преимущества, это же не альтернатива, а частный случай сегментной модели: базы всех сегментов поставлены в ноль, лимиты всех сегментов поставлены в максимум.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Mikle
Изобретатель велосипедов
Изобретатель велосипедов
Аватара пользователя
 
Сообщения: 4147
Зарегистрирован: 25.03.2003 (Вт) 14:02
Откуда: Туапсе

Re: Муки выбора

Сообщение Mikle » 29.06.2011 (Ср) 15:27

ger_kar писал(а):хотелось бы и про положительную сторону узнать.

Простота и понятность, особенно для начинающих программистов. Могу по себе сказать - я когда-то, лет 15 назад, работая под ДОСом, увлёкся идеей дос-экстендера, писали вдвоём с другом, даже что-то получилось... а потом, как узнали, что в Win95 flat-модель, можно не париться с сегментами, сразу доступны огромные (по тем временам) пространства ОЗУ - ТОГДА нам это понравилось и послужило толчком к окончательному переходу на Винду.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 15:37

Mikle писал(а):Простота и понятность, особенно для начинающих программистов. Могу по себе сказать - я когда-то, лет 15 назад, работая под ДОСом, увлёкся идеей дос-экстендера, писали вдвоём с другом, даже что-то получилось... а потом, как узнали, что в Win95 flat-модель, можно не париться с сегментами, сразу доступны огромные (по тем временам) пространства ОЗУ - ТОГДА нам это понравилось и послужило толчком к окончательному переходу на Винду.

Между сегментами реального режима (которые в DOS) и сегментами в защищённом 32-разрядном режиме (которые в Windows, не считая 16-ые приложения) — ничего общего, кроме названия.

Я ещё раз говорю: не нужно противопоставлять flat-модель и сегментную организацию. flat — это самый тупой случай использования сегментов. Полноценное использование сегментов обеспечит куда большие объёмы памяти, чем даёт flat-модуль в Windows. Хотя бы потому, что верхняя половина сегмента отдана ядру и недоступна.

Кстати, ещё один интересный случай. В Windows для доступа к TEB создаётся сегмент, база которого ставится на начало TEB, а селектор которого записывается в регистр FS. Каждый поток обращается к FS:[X], но из-за того, что у каждого свой сегмент — каждый поток обращается к своему экземляру TEB.

Было бы неимоверно здорово иметь TLS, работающий по такой схеме. Но опять же из соображений кроссплатформенности реальная реализация TLS гораздо более унылая. Не только по красоте мысли, но и по своей производительности.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Mikle
Изобретатель велосипедов
Изобретатель велосипедов
Аватара пользователя
 
Сообщения: 4147
Зарегистрирован: 25.03.2003 (Вт) 14:02
Откуда: Туапсе

Re: Муки выбора

Сообщение Mikle » 29.06.2011 (Ср) 15:56

Хакер писал(а):Между сегментами реального режима (которые в DOS) и сегментами в защищённом 32-разрядном режиме (которые в Windows, не считая 16-ые приложения) — ничего общего, кроме названия.

Я же написал:
Mikle писал(а): увлёкся идеей дос-экстендера, писали вдвоём с другом, даже что-то получилось

То есть всю "прелесть" работы с сегментами в защищенном режиме успел ощутить.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 16:02

Mikle писал(а):То есть всю "прелесть" работы с сегментами в защищенном режиме успел ощутить.

Сегменты реального режима, сегменты защищённого режима в 16-битном режиме, сегменты защищённого режима в 32-битном режиме, сегменты защищённого режима в 32-битном режиме с включением страниченого режима (флаг-бит PG в регистре CR0 установлен).

Прелесть работы с чем именно из этого ты ощутил?
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Mikle
Изобретатель велосипедов
Изобретатель велосипедов
Аватара пользователя
 
Сообщения: 4147
Зарегистрирован: 25.03.2003 (Вт) 14:02
Откуда: Туапсе

Re: Муки выбора

Сообщение Mikle » 29.06.2011 (Ср) 16:24

Защищенный режим, 32 бита. А вот какую именно модель мы осуществили, с PG-флагом, или без, сейчас уже не помню.
Хакер писал(а):Прелесть работы с чем именно из этого ты ощутил?

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Муки выбора

Сообщение Хакер » 29.06.2011 (Ср) 16:38

Mikle писал(а):"Прелесть" я в кавычки взял. Для инициализации PM приходилось выполнять очень много действий, большую часть которых мы не понимали. А в Винде это всё уже готовое, да ещё и без сегментов, это привлекло.

Ключевое слово здесь — «мы не понимали». Если бы я не понимал, и меня бы кто-то заставил работать со всем этим, я бы застрелился. Но с тех пор, как я понял, работать со всеми этим мне наиболее приятно. То есть для меня это тоже прелесть, но абсолютно без кавычек.

Mikle писал(а):А в Винде это всё уже готовое, да ещё и без сегментов, это привлекло.

А в винде вся это работа сделана за вас. И все сегменты есть. Просто они уже сконфигурированны за вас (самым небезопасным образом), возможность конфигурировать их самостоятельно у вас изъяли. Как обычно, ради того, чтобы меньше предпринимать, программисты идут на ущемление их возможности делать всякие «эффективные штуки».
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Mikle
Изобретатель велосипедов
Изобретатель велосипедов
Аватара пользователя
 
Сообщения: 4147
Зарегистрирован: 25.03.2003 (Вт) 14:02
Откуда: Туапсе

Re: Муки выбора

Сообщение Mikle » 29.06.2011 (Ср) 17:08

Хакер писал(а):Ключевое слово здесь — «мы не понимали».

Именно. Мы пишем об одном и том же, разногласий не вижу. Мы тогда что-то в ДОС-е понимали, но в этом были полными нубами, и ПОЭТОМУ система в Винде нас привлекла.

Qwertiy
Доктор VB наук
Доктор VB наук
 
Сообщения: 2753
Зарегистрирован: 26.06.2011 (Вс) 21:26

Сообщение Qwertiy » 30.06.2011 (Чт) 14:30

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

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

Пред.

Вернуться в Holy Wars@VBStreets

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8

    TopList  
cron