pavia писал(а):
Суть в том что в срыве стека меняют указатель данные. Тем самым получают возможность писать данные по нужному адресу, не обязательно через срыв стека стек.
Русски не русски трава хорошо срыв стека?
Очень сложно было распарсить зацитированное. Тем не менее, озадачившись вопросом, я поискал и нашёл. Вот замечательная
статья мыщъха, детально освещающая этот вопрос. Осеписателям и процессоростроителям обязательно надо её прочитать. Я думаю так: да, DEP в теории повышает защищённость системы, однако, это надо делать не
через ж... так, как всё делается у Майкрософт, а с другой стороны, лазейка всё равно остаётся. И, да, самое главное - действительно, раздельный стек в комбинации с DEP, похоже, полностью закрывает эту уязвимость. Наконец удалось найти реальное преимущество и уяснить, что да, Эльбрус более защищён и на x86 от этой атаки полностью защититься невозможно, т.к. утратится архитектурная совместимость. Эльбрус approved!!!
pavia писал(а):
Выбирают адрес к примеру в какой нибудь мало используемой DLL, т.е. в участке с заведомо разрешенным доступом. Туда по байтно загоняется зло.код А потом меняется адрес возврата на адрес зло.кода.
Не, так не получится. Чтобы
загнать вредоносный код в какой-то участок памяти, нужно чтобы процессор
уже выполнял другой вредоносный код. Точка атаки всё равно должна как-то пролегать через стек и манипуляции адресами возврата.
pavia писал(а):
Про эльбрус. Я бы купил.
Продаётся. 50 тыр за ноутбук. Дороговато.
pavia писал(а):
Во-вторых Эльбрус-4С только завершил этап ОКР, т.е нет серийного производства. А покупать 10 летний процессор неохото. Не говоря уже о том что СПО надо будет адаптировать под него.
Так ведь речь как раз о том, что он выпускается серийно, хотя и лихорадочно (крышек не тех понаделали, с количеством ядер определились в последний момент
). И СПО они уже сами адаптировали.
pavia писал(а):
Инициализация данных может осуществляться только программно. Так как только программист знает какую константу можно забить.
Речь в данном случае о другом - предотвращение доступа к чужим данным через аллокированную, но не очищенную память. Я к тому, что не вижу в данном случае преимуществ специфической аппаратной реализации перед софтовой, т.к. узкое место - канал обмена данными с памятью, а отнюдь не выполняющийся код.
pavia писал(а):
Энерго эффективность зависит от числа переключений. В VLIW если не распарсел, то как следствии не задействует блоки и как следствие экономит на электричестве.
Да, но энергия всё равно тратится на подкачку пустых команд из памяти, прокидывание их через кэши всех уровней, а также через декодирование инструкции (instruction prefetch and decode) даже несмотря на то, что выполнять нечего. И эти расходы могут оказаться немаленькими, - к примеру если из шести заложенных инструкций работает только одна. Вот о чём я.
pavia писал(а):
По поводу того что быстрее. Ну сравнение не корректное, они не пишат на каких задачах.
Почему же? Как раз пиш
ут, - на третьей странице третьей части. И по прочтении
слегка отвисает челюсть возникают странные мысли. Так, по цифровой фильтрации сигнала, которая ну ОООЧЕНЬ хорошо кладётся во VLIW, Эльбрусы сливают. Но по шифрованию ГОСТ, которое не имеет явных преимуществ с точки зрения архитектуры VLIW перед фильтрацией, имеют двукратный перевес. Либо шифрование ГОСТ поддержано аппаратно, либо оптимизировано вручную. Ни то, ни другое мне откровенно не нравится (с позиции оценки производительности). И почему тестировали менее распространённый ГОСТ, а не AES? Вероятно, по тем же причинам.
pavia писал(а):
Суть в том что VLIW как и потоковые процессоры достигают высокой производительности за счёт своей энергоэффективности. Добиваются они это тем что не тратят энергию на декодирование команд и смены состояний АЛУ, на доступ к памяти.
Ну всё же не за счёт энергоэффективности. Очень упрощённо, VLIW можно представить себе как RISC с одновременным выполнением инструкций. Т.е. несколько (в случае Эльбруса, надо понимать, 6) тесно связанных и частично специализированных исполнительных устройств (RISC-ядер с общим банком регистров) одновременно получают несколько (6) потоков инструкций. Но это всё же не поток микрокода, как некоторые считают, хотя и декодировать его, конечно, существенно проще, в лучших традициях RISC. Таким образом, для грубой оценки энергоэффективности следует брать несколько RISC-ядер и считать, что какая-то доля ядер постоянно выполняет поток NOP-ов. Доля меняется в зависимости от алгоритма и от того, насколько эффективно компилятор справился с трансляцией.
pavia писал(а):
Поэтому GPU выигрывают у CPU в более 10 раз.
Стоит сказать что x86 тоже ориентирован на общие задачи. А Эльбрус что раньше с DSP что и сейчас без DSP позиционирует себя как число дробилка.
Ну GPU выигрывают не только потому что они VLIW.
По поводу "числодробилок"... Обычно это из категории универсальных терминов, которые "всё сразу проясняют", но на самом деле ровным счётом ничего не объясняют. "
XXX порвал в клочья YYY? А, ну так это же просто числодробилка!". Почему же тогда до сих пор никто не сделал "просто универсальную числодробилку", которая рвёт в клочья всех остальных? Ведь это же так просто - сделаем на кристалле стопитсот умножителей и все дела.
Эльбрус - это просто процессор общего назначения, т.е. неспециализированный. Хорошо, есть определённые узкие классы задач, обладающие свойствами регулярности, внутренне присущего параллелизма и большого кол-ва арифметических операций (собс-но, то, что неформально обычно и подразумевают под числодробизмом). Но вот загадка... если Эльбрус - VLIW и числодробилка, почему же он тогда просирает не только GPU, но даже и классическим CISC на САМОЙ приятной для числодробизма задаче - цифровой фильтрации сигнала???