LINUX.ORG.RU

Новые уязвимости в lighttpd


0

0

На сайте Secunia, который специализируется на обзорах безопасности ПО, недавно было заявлено о нахождении 6-ти новых уязвимостях в сервере lighttpd. В частности злоумышленник может произвести DoS атаку.

>>> Подробности

Ответ на: комментарий от ero-sennin

> У тебя двойка по чтению? Несколькими постами выше я интересовался бенчмарками, исследующими прирост производительности от замены strncmp на сысоевские хаки. Если прирост есть и он больше одного процента, я публично признаю себя некомпетентным ослом и больше не вякаю. Так что, ссылка будет?

Признавай. Разница на порядок:

t.c:
#include <string.h>

int main()
{
	char s[]="POST hfsadgjfgasdjkghfjkasdghjkfgasdjkgfjkasdhgfjgasdjkgf";
	int i;

	int a;

	for (i=0;i<10000000;i++)
	{
		if(!strncmp(s,"POST",4)) a=1;
	}
	return a;
}

t2.c:
#include <string.h>

int main()
{
	char s[]="POST hfsadgjfgasdjkghfjkasdghjkfgasdjkgfjkasdhgfjgasdjkgf";
	int i;

	int a;

	for (i=0;i<10000000;i++)
	{
		if(s[0]=='P' && s[2]=='S' && s[3]=='T') a=1;
	}
	return a;
}

(1143) darkman@support-p:~/tmp> gcc -o t t.c  
(1144) darkman@support-p:~/tmp> time ./t    
./t  0,54s user 0,00s system 88% cpu 0,612 total
(1145) darkman@support-p:~/tmp> gcc -o t2 t2.c
(1146) darkman@support-p:~/tmp> time ./t2     
./t2  0,03s user 0,00s system 68% cpu 0,053 total

Darkman ★★★
()
Ответ на: комментарий от Darkman

Darkman,

ты нерусский?

Я в третий раз спрашиваю, на сколько сотых процента увеличивается производительность nginx от замены strncmp на такое побайтовое сравнение. С такими микробенчмарками в детский сад, ты хотя бы -O2 включи, чудо, и посмотри, что будет.

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

> Я в третий раз спрашиваю, на сколько сотых процента увеличивается производительность nginx от замены strncmp на такое побайтовое сравнение. С такими микробенчмарками в детский сад, ты хотя бы -O2 включи, чудо, и посмотри, что будет.

Садись, пиши код, компиль, бенчмаркай. Мне лень придумывать код, который не выкинется c -O2, как в выше указанном случае. Я понимаю что ты великий гуру оптимизации и никто тебе не указ - ну так вперёд.

PS. Очень люблю когда люди обсирают чужой стиль программинга. Ты сам что-нибудь уровня nginx написал хоть ?

Darkman ★★★
()
Ответ на: комментарий от Darkman

В догонку. На одном из моих Ada проектов замена

function "*" (a: in CGfloat3, b: in GLfloat3) return GLfloat3;

на

procedure mul (a: in GLfloat3; b: in GLfloat3; c: out GLfloat3);

Дало 18% прироста на массивах от 1_00_000 элементов при -march=athlon-xp -O2 при том что обе функции были

pragma Always_Inline;

хотя по идее при Inline разницы не должно быть никакой.

Вот так вот. А nginx операции сравнения проводит явно не 10 раз. И еще, rep* тормоззз начиная с i386, т.к. loop на конвеер ложится лучше.

Darkman ★★★
()
Ответ на: комментарий от Darkman

> Садись, пиши код, компиль, бенчмаркай.

Обожди-ка. Я сказал: такие микрооптимизации в nginx — глупость, потому что они не улучшат общую производительность больше, чем на доли процента. Ты с этим не согласился. Ну так аргументируй. Если есть результаты бенчмарков (уточняю, бенчмарков nginx), покажи их. Если нет, пойди и поплась от отчаяния.

> PS. Очень люблю когда люди обсирают чужой стиль программинга.

Тоже не люблю. Я лишь хотел сказать, что _мне_ такой стиль непонятен. И такая любовь к низкоуровневым оптимизациям мне непонятна. Как и отказ от стандартных систем сборки и последующее костылестроение. Всё это уж очень напоминает незабвенного D. J. Bernstein'а. Авторы же lighttpd мне показаались гораздо более адекватными.

ero-sennin ★★
()
Ответ на: комментарий от Darkman

> А nginx операции сравнения проводит явно не 10 раз.

Это оптимизированное сравнение используются максимум 4 раза на 1 HTTP-шный запрос, и ровно 1 раз, если это GET (т. е. в 99% случаев). В остальных местах оно вообще не используется.

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

> Это оптимизированное сравнение используются максимум 4 раза на 1 HTTP-шный запрос, и ровно 1 раз, если это GET (т. е. в 99% случаев).

Там весь src/http/ngx_http_parse.c на подобных сравнениях. Ты слона не заметил. Посмотри _внимательно_ на указанный файл, и поймёшь нафиг так было сделано и сколько времени оно сокращает на парсинге запроса.

Hint: там не просто сравнения, там вагон case и if вдобавок.

Darkman ★★★
()
Ответ на: комментарий от Darkman

> Hint: там не просто сравнения, там вагон case и if вдобавок.

Всякие сase ' ' и if (ch < '0' || ch > '9') тоже не особенно украшают код, но против них я пока ничего не имею. Мне непонятна именно замена str(n)cmp на самописные функции. Которые используются максимум 4 раза (это в случае метода LOCK, который встречается один раз за тысячелетие).

Кстати, вот ещё: макросы для сравнения строк называются так:

ngx_str3_cmp
ngx_str30cmp
ngx_str4cmp
ngx_str5cmp
ngx_str6cmp
ngx_str7_cmp
ngx_str8cmp
ngx_str9cmp.

Внимание, вопрос. По какому принципу автор расставлял символы подчёркивания? Почему в str3_cmp и str7_cmp подчёркивание есть, а в остальных нет? Сколько угодно называй меня занудой, но во взрослом HTTP-сервере такому бардаку не место.

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

#include <string.h>

bool cmp( char const * s )
{
#ifdef USE_STRNCMP
return strncmp( s, "POST", 4 ) == 0;
#else
return ( s[0] == 'P' && s[1] == 'O' && s[2] == 'S' && s[3] == 'T' );
#endif
}

int main()
{
char const * s = "POST hfsadgjfgasdjkghfjkasdghjkfgasdjkgfjkasdhgfjgasdjkgf";
int total = 0;

for( int i=0; i<1000000000; ++i )
{
if( cmp( s ) )
{
++total;
}
}

return total;
}

--------------------
$ g++ -O2 test.cc -o strncmp -DUSE_STRNCMP
$ g++ -O2 test.cc -o charcmp
$ time ./strncmp
./strncmp 1.66s user 0.00s system 99% cpu 1.666 total
$ time ./charcmp
./charcmp 1.67s user 0.00s system 99% cpu 1.670 total


---------------
На оптимизации выиграли сотую процента, на читабельности проиграли всю тысячу.

P.S.
g++ (GCC) 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)
Intel(R) Pentium(R) 4 CPU 2.60GHz

anonymous
()
Ответ на: комментарий от ero-sennin

> Мне непонятна именно замена str(n)cmp на самописные функции.

В версии 0.5.8 никаких функций не вижу. Вполне допускаю что они появились в более поздних, причём врятли это функции, скорее всего #define, и допускаю что это замена s[0]=='P' для читабельности. Почему именно == видно из такого фрагмента:

if (m[1] == 'O') {

if (m[0] == 'P' && m[2] == 'S' && m[3] == 'T') {

Банальная, и, на мой взгляд, оправданная оптимизация.

> Почему в str3_cmp и str7_cmp подчёркивание есть, а в остальных нет?

Никто не совершенен. Пофиксят.

> Сколько угодно называй меня занудой, но во взрослом HTTP-сервере такому бардаку не место.

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

Darkman ★★★
()
Ответ на: комментарий от anonymous

> На оптимизации выиграли сотую процента, на читабельности проиграли всю тысячу. 

Буагагагагага !

У тебя всё основное время уходит на сам вызов функции 'cmp'.

Ты обьяви 'bool inline cmp' и посмотри в ассемблере что 
сгенерит g++ при -O2.

Даже код приведу:

        .file   "t3.c"
        .text
        .align 2
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB3:
        leal    4(%esp), %ecx
.LCFI0:
        andl    $-16, %esp
        pushl   -4(%ecx)
.LCFI1:
        movl    $1000000000, %eax
        pushl   %ebp
.LCFI2:
        movl    %esp, %ebp
.LCFI3:
        pushl   %ecx
.LCFI4:
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
.LFE3:
        .size   main, .-main
.globl __gxx_personality_v0
        .ident  "GCC: (GNU) 4.1.2 (Gentoo 4.1.2)"
        .section        .note.GNU-stack,"",@progbits

Darkman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.