Решил написать о часто встречающейся ошибке в сетевых приложениях и сетевых устройствах. Постараюсь объяснить проблему, на примере Linux стека. И буду больше рассуждать Абстрактно, пытаясь объяснить принцип. Ведь все приложения разные, хоть суть одна. (Переносят биты туда-сюда. ) И к каждому сетевому приложению, или к сетевому устройству нужен свой подход, чтоб исправить допущенные в нём ошибки.

Проблема заключается в тех маленьких порциях данных, которыми обмениваются системы. Точнее не в самих этих порциях, а в том, как они далее собираются и обрабатываются.

Например, одна система отправляет другой системе фразу Hello World !

Как это можно сделать? Да как угодно. Выбирается любой протокол передачи данных: TCP, MPTCP, UDP. Данные разбиваются на части, которые мы назовём пакетами. И отправляются на конечную систему. (Как именно? Да это абсолютно не важно. )

Важно то, что(и как) конечная система будет делать с полученными данными. Если строка Hello World ! была разбита на два пакета:

Hello - Это содержимое первого пакета.

World ! - А это, уже второй пакет.

То после того, как сетевое устройство начнёт принимать пакеты (они могут быть обработаны самим сетевым устройством) при удачной обработке, они будут переданы далее в сетевой стек Операционной Системы (ОС). (О проблеме на этом этапе будет написано далее. )

Если пакеты попали в Сетевой Стек, то ОС обрабатывает данные пакета последовательно. Это значит, что часть пакета будет указывать, как пакет был доставлен до системы. И мы эту часть, смело пропускаем т.к. это Не важно. Отбрасываем всю часть рассуждений вплоть до важного момента до Сборки данных на транспортном уровне.

В конечном итоге, система должна понять какова правильная последовательность пакетов. Ведь, до системы мог сначала дойти пакет

World ! - Второй пакет.

А потом

Hello - Первый пакета.

И если, ОС не определяла правильную последовательность пакетов. То до приложения пользовательского уровня. Дойдёт такая строка: World !Hello . Разумеется такой подход большинство не устраивает и поэтому протоколы поддерживают номера последовательностей (а также временные метки, но это всё частности, мы будем говорить только о номерах последовательностей и назовём их seq).

Мы уже оперируем такими важными вещами: Данные и seq. Добавим к нашим знаниям, также Размер Данных.Данных и их размера, достаточно, чтоб произвести их отправку через сокет. Но зачем тогда упоминать seq?Тут нужно осознать, что можно предугадать состояние второй системы, которая принимает наш Hello World !

Смотрим на примере Linux и протокола TCP ( Код привожу из ядра Linux-5.10.7 ) В файле tcp_ipv4.c есть функция tcp_v4_fill_cb , которая прольёт свет на происходящее на конечной системе. А точнее, нас интересует

TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +    skb->len - th->doff * 4);

end_seq Это значение используется для указания конца данных пакета. (Любой следующий пакет, должен быть как минимум на единицу больше предыдущего (Для того, чтоб не быть отброшенным до начала копирования данных пакетов из сокета)

Например: Hello - Первый пакета. Размер 6 байт.

Первый пакет, имеет seq = 0x1 и end_seq = 0x7

World ! - Второй пакет. Размер 7 байт.

Второй пакет, имеет seq = 0x7 и end_seq = 0xE

Тогда данные собирутся в строку Hello World !

А вот если

Второй пакет, имеет seq = 0x4 и end_seq = 0xB

Тогда данные собирутся в строку Hello ld !

Символы Wor Будут отброшены. (Это происходит при копировании данных из пакетов, при чтении сокета ) После копирования данных. Через функцию tcp_rcv_nxt_update файла tcp_input.c указывается значение rcv_nxt в структуре протокола struct tcp_sock. Это значение, будет равняться end_seq после копирования всех пакетов в общий буфер (после чтения данных из сокета). (Первое значение rcv_nxt будет установлено сразу после tcp рукопожатия)

Короче говоря: сначала приходят пакеты и передвигается значение end_seqДалее данные копируются в общий буфер, и передвигается значение copied_seq структуры tcp_sock. И после того, как данные из пакетов (буферов сокетов) будут скопированы в общий буфер, произойдёт установка rcv_nxt в end_seq. И итерация повторяется.

Теперь рассмотрим следующее. Что будет если

Первый пакет: seq = 0xFFFFFFF0 и размер 0x64 (100)то

TCP_SKB_CB(skb)->end_seq = (0xFFFFFFF0  + 0x1 + 0 +  0x140 - 0x40);(если  doff = 5)TCP_SKB_CB(skb)->end_seq = 0xFFFFFFF0 + 0x65 = 0x100000055

Т. е. произошло переполнение, и результат end_seq = 0x55 (85 в десятичной)

при этом rcv_nxt = 0xFFFFFFF0 , т. к. ещё копирования данных из сокета не произошло.

Здесь возникает ситуация, когда end_seq < seq

0x55 < 0xFFFFFFF0

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

Например такой пакет будет корректен.

seq = 0xFFFFFC6E размером в 1000 байт (end_seq = 0x56 )

В этом нет ничего интересного, если не помнить о флаге URG . В Википедии сказано: 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные.

И вот тут то, и находятся возможные ошибки. Всё зависит от того, как сетевое устройство обрабатывает urg пакеты. Ошибки могут быть в реализации драйверов. Или в аппаратной части. (при TCP Offload Engine )

При больших значениях seq (близких к целочисленному переполнению),возможности регулировать размер буфера сокета (размером данных пакета),возможностью указать смещение для urg в диапазоне 0-0xffff, установкой значения rcv_nxt.Можно влиять на дальнейшее поведение системы. (на уровне ядра)Добавлю ещё такую информацию. Она не будет лишней.

Проверки номеров последовательностей пакетов, базируются на функциях: after и before. Которые проверяют, где находится число в последовательности "до" указанного числа, либо "после" или "равно".

Вот результаты работы функций с некоторыми числами, как пример.

inline bool before(__u32 seq1, __u32 seq2){   return (__s32)(seq1-seq2) < 0;}#define after(seq2, seq1) before(seq1, seq2)after( 0x80000000,  0x7fffffff ) = 1   after( 0x7fffffff,  0x80000000 ) = 0   after( 0x80000000,  0x80000000 ) = 0  before( 0x80000000,  0x7fffffff ) = 0   before( 0x7fffffff,  0x80000000 ) = 1   before( 0x80000000,  0x80000000 ) = 0  

Как видно, сравнение больше или равно, сводится к вычитанию второго аргумента из первого и сравнения результата с нулём.

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

На примере end_seq < seq

0x55 < 0xFFFFFFF0

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

if(TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq >= какое то число) {Можно зайти сюда } else { или сюда }if(0x55 - 0xfffffff0 >= какое то число)if(0xFFFFFF9B >=  какое то число)

Привожу пример кода из файла chtls_cm.c который может содержать ошибку.

В функция handle_urg_ptr присутствует такой код.

if (skb && tp->copied_seq - ULP_SKB_CB(skb)->seq >= skb->len)chtls_free_skb(sk, skb);

В нем присутствуют три переменных: copied_seq, seq, skb->len на которые можно влиять.

На самом деле нет (из-за особенностей работы устройства, нельзя влиять на ULP_SKB_CB(skb)->seq ). Еслиб можно было влиять на (skb)->seq, тогда можно подобрать такие значения seq, copied и skb->len при которых, сработает очистка буфера сокета и код драйвера, продолжит свою работу.

Далее, рассмотрим такой пример: в файле chtls_cm.c

Есть функция chtls_recv_data в ней присутствует такой код

if (unlikely(hdr->urg))handle_urg_ptr(sk, tp->rcv_nxt + ntohs(hdr->urg));if (unlikely(tp->urg_data == TCP_URG_NOTYET &&     tp->urg_seq - tp->rcv_nxt < skb->len))tp->urg_data = TCP_URG_VALID |       skb->data[tp->urg_seq - tp->rcv_nxt];

Сразу можно обратить внимание на вызов handle_urg_ptr(sk, tp->rcv_nxt + ntohs(hdr->urg)); Где находятся два аргумента tp->rcv_nxt + ntohs(hdr->urg) .

rcv_nxt можно предсказать, а hdr->urg установить в пакете. Таким образом, пердав какое то число в функцию handle_urg_ptr для дальнейшей обработки. Но это не так кретично, как следущий код.

if (unlikely(tp->urg_data == TCP_URG_NOTYET &&     tp->urg_seq - tp->rcv_nxt < skb->len))tp->urg_data = TCP_URG_VALID |       skb->data[tp->urg_seq - tp->rcv_nxt];

Тут снова видим tp->urgseq - tp->rcv_nxt < skb->len , два числи на которые может воздействовать отправитель пакетов, сравниваются с значением размера данных сокета, который также указывается отправителем (через количество отправляемых данных). А далее skb->data[tp->urg_seq - tp->rcv_nxt];

Снова два значения, устанавливаемые удалённо tp->urg_seq - tp->rcv_nxt. Обратятся, к данным по индексу - ???

tp->urg_seq - tp->rcv_nxt < skb->len Данное условие создаёт иллюзию, что при обращении к массиву skb->dataurg_seq - tp->rcv_nxt  Будут находиться, внутри массива данных сокета.И не могут быть больше skb->len, ведь чуть выше делалась проверка tp->urg_seq - tp->rcv_nxt < skb->lenВобщем,  в суровой реальности индекс массива может бытьskb->data[0xffffffff];skb->data[0xfffffff0];skb->data[0xffffff00]; и тд.

Это приводит к чтению памяти, по указному индексу. Либо к зависанию системы.

Далее ещё один пример.

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

Фактически, можно произвести тестирование "черного ящика" но с допущением, что проверяться будут различные условия для порядковых номеров пакетов.

Когда устройство делает аппаратную обработку tcp пакетов, то предполагается что взаимодействие клиент/сервер происходит, по стандартному сценарию. Когда все действия систем перекладываются на сетевой стек. Все данные имеют, порядковые номера указываемые сетевой подсистемой (временные метки, размер пакетов и тд.). Но если, пакеты сформированы вне "системы", то есть огромная вероятность, что что-то пойдёт не так. Ведь, когда программист тестирует сетевое приложение (или аппаратуру), то он не выходит из стандартной схемы тестирования. Берёт приложение, или пишет его сам. Создаёт сокет и шлёт данные. Как именно шлются эти данные, программисту не важно. В этом проблема. Люди больше концентрируют внимание на том, какие именно данные шлются, а не на том, как они отправляются.

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

А когда тестируется сетевое устройство, то после ошибки обработки данных (или не ошибки) в устройстве. Оно может передать в драйвер не корректные данные. Которые по сути, никак не могли появиться. (в теории) (Но если вспомнить о проблемах проверки порядковых номеров. То вероятность обнаружить ошибку, резко возрастает)

Вот пример: в файле chtls_main.c

Есть функция chtls_recv , она работает с пакетом который уже был обработан сетевым устройством.

void chtls_recv(struct chtls_dev *cdev,       struct sk_buff **skbs, const __be64 *rsp){struct sk_buff *skb = *skbs;unsigned int opcode;int ret;opcode = *(u8 *)rsp;   // Тут находится ОШИБОЧНЙ ОПКОД__skb_push(skb, sizeof(struct rss_header));skb_copy_to_linear_data(skb, rsp, sizeof(struct rss_header));ret = chtls_handlers[opcode](cdev, skb); // Вызов функции по, не правильному опкодуif (ret & CPL_RET_BUF_DONE)kfree_skb(skb);}

После обработки пакета устройством, сетевая карта передаёт драйверу опкод операции которую должна выполнить система.

opcode = *(u8 *)rsp; Содержит опкод инструкции, которую будет выполнять система.

Но если, передать устройству определённые пакеты, которые пройдут все проверки по значениям seq и дополнить их urg, то устройство выставит определённый опкод для выполнения, который вообще не должен был никогда выставляться.

В данном примере

ret = chtls_handlers[opcode](cdev, skb);

Будет выполнена функция по адресу NULL. Что приведёт к зависанию системы.

И такие ошибки остаются не замеченными ГОДАМИ.

Также скажу, что пытался рассказать о проблеме на примере TCP и флага urg. Но точно такие же проблемы, можно обнаружить и при сборке UDP пакетов (везде. не важно, драйвера или приложения прикладного уровня, или сетевые устройства). Сколько сетевых устройств подвержено данной проблеме, не знаю. Думаю, что очень не мало.

Проверял всего одно устройство (которое было на руках). Результат, удалённый вызов нулевого указателя в ядре. Отказ в обслуживании. ( + доступ к памяти системы, в определённых диапазонах) Писал производителю о проблемах, но им это не интересно, проигнорировали и выпустили новый флагман) с теми же проблемами.

На этом пока всё.

Часто ли вы натыкались в вакансиях на слова "English B2" / "Intermediate English" / "Английский на уровне чтения документации" и задавались ли вы вопросом, почему это резко стало так важно? Сейчас действительно наблюдается тенденция, что больше и больше компаний выделяют английский язык как требуемый навык, несмотря на то что команда полностью русскоговорящая и с иностранными заказчиками не работает.

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

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

Это вторая часть из цикла статей об основных проблемах, с которыми могут столкнуться новички на старте карьеры. Первая часть находится здесь. Там можно почитать про "ожидание / реальность" работы разработчика.

Я смогу выучить, когда он мне понадобится

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

Да, тебе не нужно знать многие грамматический конструкции, и не так уж надо уметь говорить на языке, но документация написана сложным техническим языком с использованием специфических терминов. Если ты изначально не привыкнешь что массив - это array, а переменная - это variable, то потом будет тяжело покрывать весь этот объем слов, и ты просто будешь спотыкаться на каждом слове в какой-нибудь статье.

Да и в работе момент, когда "понадобится" наступит очень быстро. Когда будут возникать какие-то теоретические вопросы, тебе могут скинуть англоязычную статью или часть документации, который тебе придется как-то читать. Но без знаний и практики конечно это будет медленнее, чем могло бы быть.

Большинство вещей, которые мне могут понадобиться, уже переведены на русский язык

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

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

MDN - один из самых популярных ресурсов для чтения документации по JavaScript

Давайте зайдем на статью по методу window.scroll, она довольно часто используется для прокрутки.

Обратите внимание на пераметры

Параметры уже немного другие или мне кажется?

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

Nuxt - SSR фреймворк для Vue

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

Ну в общем-то все понятно

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

Английский - это международный язык разработки, самая актуальная и верная информация будет именно на нем.

Русских разработчиков так много, что я смогу найти ответ на любой вопрос

Когда что-то не получается, человек идет задавать вопросы гуглу. Кто знает английский язык, тот задаст на английском, а кто не знает - будет задавать на русском. Как вы думаете, кто быстрее найдет ответ?

Большая часть вопросов на том же stackoverflow написана на английском, большая часть issues в пакетах на github написана на английском. Как я уже говорила выше, этот язык - международный в плане разработки, а значит, задавая вопрос на английском, вы получаете доступ к мировой базе информации, большему количеству кейсов и огромному количеству ответов и решений.

Я буду работать с русскоговорящими людьми, зачем мне понадобиться английский

Есть стандарты того, что код оформляется на английском языке. То есть названия переменных - это не русская транскрипция, а английские слова. Комментарии к коду часто пишут на английском. Грубо говоря, если ты видишь переменную width, ты быстро понимаешь, что это связано с шириной. Человек же не знакомый с этим языком, будет дольше по времени читать программу.

Работа с git тоже часто происходит именно на английском: те же названия веток и коммиты. И даже если ты не используешь иностранный язык, другой человек в команде может, и читая историю коммитов не получится быстро сориентироваться.

Надеюсь я убедила вас, что английский надо начинать учить как можно раньше и развеяла ваши заблуждения, если они у вас были.