корень зла (программистское)

[avva]

Любопытная попытка написать супер-оптимизированный HTTP request/response parser. Намерения самые добрые, но... мне кажется, в этом небольшом модуле я смог бы набрать материала на часовую лекцию о том, когда не надо оптимизировать и как не надо.

Даже проглядев его вскользь, я вижу несколько мест, где на первый взгляд очень эффективный подход на самом деле даст относительно медленный код, который легко можно улучшить; а также заодно и место, где есть потенциальный buffer overflow. Утверждение автора, что его модуль "...is nearly optimal in its use of CPU instructions", конечно, слишком оптимистично. Но главное - почти наверняка выбранная модель общения с клиентом, через колбэки, на практике приведет к большим потерям времени и эффективности, чем столь тщательно сынженированные ручные подгонки под названия HTTP-методов, или отсутствие malloc()-ов.

Меж тем проект, ради которого это затеяно, Node.js (быстрый V8-джаваскрипт на сервере), весьма интересен.

Comments

[unbe.livejournal.com]

А где потенциальный buffer overflow? Я нашел только неправильный индекс у usual[], но это не buffer overflow.

[avva.livejournal.com]

c = lowcase[(int)ch];

обратите внимание, что ch - char, а не unsigned char.

[unbe.livejournal.com]

да, верно, с usual[] та же история, но это не совсем buffer overflow.

[avva.livejournal.com]

Скажем так, это видимо не exploitable buffer overflow, но тем не менее это он :) больше вреда, чем скормить коллбэку какое-то количество случайного мусора, который и так можно было послать самому, это не причинит. Но все равно. Я ему черкну письмо наверное.

[(Anonymous)]

«не exploitable»

зависит от коллбэка. парсер думает, что проверяет, что header field состоит из законных символов (буквы, цифры, минус), но при этом пропускает символы <0. если коллбэк понадеется на эту проверку и со своей стороны станет индексировать этими символами какие-то свои массивы, может оказаться еще как exploitable.

[avva.livejournal.com]

да, вы совершенно правы, спасибо за уточнение.