The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов, opennews (??), 16-Июл-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


37. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/–
Сообщение от Аноним (37), 17-Июл-21, 03:11 
Ну будет вместо бесконечной рекурсии бесконечный цикл, сильно поможет?
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от Lex (??), 17-Июл-21, 05:25 
В случае с рекурсией огромное количество данных валится в стек, тогда как в случае с циклом - можно весьма просто это подправить..
Тем более, ничего не мешает при достижении энных размеров, завершать обработку с сигналом «слишком толсто».. и с циклом это сделать сильно проще.
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/–
Сообщение от n00by (ok), 17-Июл-21, 07:52 
> В случае с рекурсией огромное количество данных валится в стек

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/–
Сообщение от Аноним (53), 17-Июл-21, 10:58 
Ну, например, CPython валит на стек процессора.
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 17-Июл-21, 12:40 
> на пример

Не вижу примера.

Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/–
Сообщение от Аноним (53), 17-Июл-21, 14:22 
import sys
sys.setrecursionlimit(100500)
def fuuuu(): fuuuu()
fuuuu()
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 17-Июл-21, 15:15 
И где там стек процессора?
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/–
Сообщение от Аноним (53), 17-Июл-21, 17:08 
sapienti sat
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 17-Июл-21, 17:55 
Вот типичная работа со стеком виртуального процессора, исполняется инструкция RETURN:

    Instruct(RETURN): {
      sp += *pc++;
      if (extra_args > 0) {
        extra_args--;
        pc = Code_val(accu);
        env = accu;
      } else {
        pc = (code_t)(sp[0]);
        env = sp[1];
        extra_args = Long_val(sp[2]);
        sp += 3;
      }
      Next;
    }

А вот как выглядит часть реализации исполнителя команд той же ВМ, которая использует аппаратный стек:

Instruct    RETURN
    mov    eax, [opcode.1]
    next_opcode
    lea    rsp, [rsp + rax * sizeof value]
    test    extra_args, extra_args
    jnz    .extra_args
    pop    vm_pc
    pop    env
    pop    extra_args
    Long_val extra_args
    Instruct_next
.extra_args:
    dec    extra_args
    jmp    Instruct_APPTERM1.br
end Instruct

Если кому не понятно, то sp это просто имя переменной-указателя, адресует выделенную по malloc() память. А rsp это регистр процессора. ЯВУ с регистрами без специальных приседаний не работают, и если кто-то полезет в стек при помощи alloca(), то к нему возникнут вопросы.

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

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от Lex (??), 17-Июл-21, 12:48 
При вызове функции, в стек падает адрес возврата + все передаваемые аргументы( строки итп - указателями ).
При работе вызванной функции, аргументы могут извлекаться( редко, обычно к ним напрямую обращаются через esp или [esp-n]. Но адрес возврата в любом случае остаётся. Итого, уже не менее 4байт для 32-битных и 8 байт - для 64-битных систем соотв на каждый вызов функции без аргументов и локальных переменных - и это только для возврата ).

Локальные переменные, явные или неявные, обычно тоже лежат в стеке( как минимум, в виде указателей )

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

71. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/–
Сообщение от n00by (ok), 17-Июл-21, 12:59 
> При вызове функции, в стек падает адрес возврата + все передаваемые аргументы(
> строки итп - указателями ).

Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?

> При работе вызванной функции, аргументы могут извлекаться( редко, обычно к ним напрямую
> обращаются через esp или [esp-n].

Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы. Да, тут надо хоть малость понимать, что такое стек процессора и куда он растёт.

Ответить | Правка | Наверх | Cообщить модератору

110. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от Lex (??), 17-Июл-21, 18:42 
Мистер не в курсе, что жс движки уже лет сто как с джИтом, а не примитивные только_интерпретаторы( поначалу да, код именно интерпретируется, но часто исполняемые функции «компилируют» для улучшения производительности ) ?

Дык ты код сишной программы в дизассемблере открой да посмотри.
Аргументы в функции обычно передаются через стек, только некоторые на стороне вызываемой функции достают данные из стека, подчищая его, а другие - работают напрямую с указателем на стек, итогом чего становится ускоренное загаживание стека на адрес возврата + все передаваемые аргументы( как минимум, их указатели ).
Можешь даже онлайн-преобразователями что-то -> асм воспользоваться типа:
https://godbolt.org/

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

Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 17-Июл-21, 18:52 
Алёша, я не удивлён, что ты своё утверждение доказать не можешь. Ты уже был пойман на пустозвонстве. Наличие JIT не является достаточным условием.

И ладно бы ты признал, что ошибся со знаком смещения от регистра стека, тогда бы с тобой имело бы смысл продолжать разговор. Но ты ведь дальше зарываешься. Так даже Криска Касперски не загонялся, пока его не вразумили. Правда, его с тобой сравнивать не уместно. Он, как минимум, умел писать и текстами зажечь.

Ответить | Правка | Наверх | Cообщить модератору

181. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от Lex (??), 20-Июл-21, 15:02 
Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие разы ты славно попадался на подмене понятий )

Кстати, о пустозвонстве..
> Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?

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

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

> что ошибся со знаком смещения от регистра стека,

Возможно, кому-то стоит меньше придираться к мелочам если есть что сказать по сути. Так меньше шансов оказаться невеждой( притом, невоспитанным ).

Так ошибся ли ? Или просто ты не понял что к чему ?
*подмигивание* А ведь ты так и не доказал не_использования стека для хранения локальных переменных или ссылок на них.. даже не просто не доказал, но и сделал вид что этого нет..

Так.. как бы ты со своей колокольни объяснил РЕАЛЬНЫЙ "выхлоп" clang'а( хотя и у гцц примерно то же самое ) а не то что у тебя в голове со стеком творится ? :

int testFunc( int arg ) {
    int tmp1 = 123;
    int tmp2 = 456;
    return tmp1 * arg;
}

push    rbp
mov     rbp, rsp
> Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы

// ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
mov     dword ptr [rbp - 4], edi
// Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
mov     dword ptr [rbp - 8], 123
// Ребяят, ну хватит уже!
mov     dword ptr [rbp - 12], 456
mov     eax, dword ptr [rbp - 8]
// Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
imul    eax, dword ptr [rbp - 4]
pop     rbp
ret


> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)

Это все здорово кнчн, но что если аргументов будет больше чем регистров ?) -Ну это к слову о не_использовании стека.
Тем более, что мире существует далеко не только линух со своими соглашениями о вызовах( хотя и в 32-битном линуховом очень даже применялся стек )

Но, да, в общем и целом на х86_64 передача аргументов стала получше
Часто данные передаются через регистры, а что не влезло - через стек против cdecl и stdcall
Хотя и есть некоторые нюансы и в вызовах и в хранени локальных переменных

Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 20-Июл-21, 17:02 
> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
> разы ты славно попадался на подмене понятий )

Потому что у тебя проблемы с памятью https://www.opennet.me/openforum/vsluhforumID3/124773.html#51 (заметь, что пруфы просил не я, я их за тебя предоставил; но там малость неувязка по срокам санкций, длиною в треть твоей жизни), при этом ты очень хорошо умеешь в "а нас то за шо?", что как бэ намекает.

> Кстати, о пустозвонстве..
>> Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?
> Помнишь ?
> Ты ведь фундаментально не прав, ведь там и далеко не только интерпретатор
> и сгенерированный код к стеку проца имеет самое прямое отношение. Но..
> признался ли хоть в чем-то ?)

Я прав в том, что сам ты ничего в данном направлении не сделал, нахватался по верхам и теперь пытаешься натянуть какое-то выдуманное тобой "там" на абстрактную JIT-компиляцию. Если бы ты создал интерпретатор и подумал над тем, как согласовать с существующей ВМ (про сборщик мусора замнём для ясности) сгенерированный на лету машинный код, ты бы сам дошёл: избавляться в нём от стека ВМ означает "иметь два стека", что накладно и нецелесообразною.

> Однозначно достаточным не является, но наличие в браузере генератора машинного кода для
> разных архитектур и его применение для генерации кода уже ощутимо повышает
> шансы, поскольку речь о вызове-таки нативных функций

Хватит рассуждать о теорвере, покажи код, где стек JS-машины адресуется через rsp. Вот как в моём примере, который я привёл от нечего делать: https://www.opennet.me/openforum/vsluhforumID3/124820.html#106

>> что ошибся со знаком смещения от регистра стека,
> Возможно, кому-то стоит меньше придираться к мелочам если есть что сказать по
> сути. Так меньше шансов оказаться невеждой( притом, невоспитанным ).

Суть вопроса проста. Кто утверждение заявляет, тот его и подтверждает. Данный случай не тот, где приходится принимать слова на веру. Если JS машины что-то валят в аппаратный стек, значит есть код, который это делает. Мне интересно на этот код посмотреть.

> Так ошибся ли ? Или просто ты не понял что к чему
> ?
> *подмигивание* А ведь ты так и не доказал не_использования стека для хранения
> локальных переменных или ссылок на них.. даже не просто не доказал,
> но и сделал вид что этого нет..

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

>[оверквотинг удален]
> int testFunc( int arg ) {
>     int tmp1 = 123;
>     int tmp2 = 456;
>     return tmp1 * arg;
> }
> push    rbp
> mov     rbp, rsp
>> Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы
> // ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ
> аргумент ?)

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

> mov     dword ptr [rbp - 4], edi
> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)

Да, это локальная переменная, потому и смещение -- отрицательное. В ней сохранён переданный через регистр edi аргумент.

> mov     dword ptr [rbp - 8], 123
> // Ребяят, ну хватит уже!
> mov     dword ptr [rbp - 12], 456

Действительно, хватит выдавать локальные переменные подпрограммы за её аргументы.

> mov     eax, dword ptr [rbp - 8]
> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))

Нет, это локальная переменная tmp1.

> imul    eax, dword ptr [rbp - 4]

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

> pop     rbp
> ret

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

Вот как должен был выглядеть твой пример:

gcc arg.c -S -fverbose-asm -masm=intel -o arg.s


testFunc:
.LFB0:
    .cfi_startproc
    push    rbp    #
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    mov    rbp, rsp    #,
    .cfi_def_cfa_register 6
    mov    DWORD PTR -20[rbp], edi    # arg, arg
# arg.c:2:    int tmp1 = 123;
    mov    DWORD PTR -8[rbp], 123    # tmp1,
# arg.c:3:    int tmp2 = 456;
    mov    DWORD PTR -4[rbp], 456    # tmp2,
# arg.c:4:    return tmp1 * arg;
    mov    eax, DWORD PTR -8[rbp]    # tmp84, tmp1
    imul    eax, DWORD PTR -20[rbp]    # _4, arg
# arg.c:5: }
    pop    rbp    #
    .cfi_def_cfa 7, 8
    ret

И предпочти изучать код после оптимизатора, это поможет понять, как работает транслятор:

gcc arg.c -O2 -S -fverbose-asm -masm=intel -o arg.s


testFunc:
.LFB0:
    .cfi_startproc
# arg.c:4:    return tmp1 * arg;
    imul    eax, edi, 123    # tmp84, tmp85,
# arg.c:5: }
    ret

>> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
> Это все здорово кнчн, но что если аргументов будет больше чем регистров
> ?) -Ну это к слову о не_использовании стека.

Для этого в скобочках и написано, что надо посмотреть.

> Тем более, что мире существует далеко не только линух со своими соглашениями

Здесь Линукс является системой по умолчанию. Архитектуру процессора ты выбрал сам, я лишь её актуализировал.

> о вызовах( хотя и в 32-битном линуховом очень даже применялся стек
> )

Ну вот и посмотрел бы, как именно он применялся, вместо эффектных попыток продемонстрировать свою базу.

Пока получается в стиле "сделайте это за меня".
Вот так передаются параметры процессу (тут немного лишнего, но оставлю как есть):


_start:
;    Допустим 1 аргумент - имя файла байт-кода.
    mov    rcx, [rsp]    ; argc
    cmp    ecx, 2
    jz    .1arg
    puts    error_about
    mov    edi, -EINVAL
    jmp    sys_exit
.1arg:    mov    rdi, [rsp + 16]    ; argv
    mov    [bytecode_filename], rdi
;    Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
;    слов после argv (rsp + 8)
    lea    rdx, [rsp + 8 + (rcx + 1) * 8]
    mov    [environment_variables], rdx

> Но, да, в общем и целом на х86_64 передача аргументов стала получше
> Часто данные передаются через регистры, а что не влезло - через стек
> против cdecl и stdcall
> Хотя и есть некоторые нюансы и в вызовах и в хранени локальных
> переменных

Это всё не имеет отношения к вопросу смещения. Просто подумай как следует, что в каком порядке складывается на стек в случае stdcall и почему помимо retn есть вариант с аргументом retn 8. И всё поймёшь. Особенно про "аргументы извлекаться" когда "адрес возврата остаётся".

Ответить | Правка | Наверх | Cообщить модератору

184. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от Lex (??), 21-Июл-21, 15:34 
>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>> разы ты славно попадался на подмене понятий )
> Потому что у тебя проблемы с памятью https://www.opennet.me/openforum/vsluhforumID3/124773.html#51
> (заметь, что пруфы просил не я, я их за тебя предоставил;
> но там малость неувязка по срокам санкций, длиною в треть твоей
> жизни), при этом ты очень хорошо умеешь в "а нас то
> за шо?", что как бэ намекает.

И в чем конкретно ложь ?
Заодно и на себя сошлись со своим не_бу_а_списанным_оборудованием, которое у тебя вдруг синонимом стало )

> Я прав в том, что сам ты ничего в данном направлении не сделал

Нет бы по честному признаться, что от души обделался с исключительно_интерпретатором в жс и отсутствием реального исполнения кода на процессоре - нет же, маню включаешь.
Хотя, что от тебя еще ожидать..

>[оверквотинг удален]
>> ?
>> *подмигивание* А ведь ты так и не доказал не_использования стека для хранения
>> локальных переменных или ссылок на них.. даже не просто не доказал,
>> но и сделал вид что этого нет..
> Это называется -- переложить бремя доказательства на оппонента. Приём демагогии такой.
> Мне не требуется что-либо опровергать, поскольку исходное твоё утверждение голословно.
> Тем не менее, скажу по секрету. Пример, на который я выше
> дал ссылку (2й фрагмент), как раз это и делает. Но к
> вопросу отношения не имеет. И я не знаю, как бы его
> к нему прикрутить.

Ты неправильно разобрал даже простейший предоставленный мной пример функции на сях и на асме с комментариями, у тебя вдруг то включалась избирательная слепота, то - отключалась память и ты забывал, НАД целевой строкой написан коммент или ПОД ней [хотя как позже оказалось ты и сам пишешь комменты НАД целевой строкой. Т.е ты даже про свои привычки забывал]
Так.. как и почему в свете этого можно верить твоей кодовой чепухе, которую ты называешь "доказательством" чего-то ?

>> ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
>> mov     dword ptr [rbp - 4], edi
>> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
>> mov     dword ptr [rbp - 8], 123
>> ...
>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>> imul    eax, dword ptr [rbp - 4]

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

>> mov     eax, dword ptr [rbp - 8]
>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
> Нет, это локальная переменная tmp1.
>> imul    eax, dword ptr [rbp - 4]
> А вот здесь как раз и должна была быть попытка выдать желаемое
> за действительное, но автор в горячке перепутал строчки.

Тебя ведь вовсе не смутило, что везде комменты написаны НАД комментируемой строкой( даже ты сам, как оказалось, именно так пишешь ), а не ПОД ней, не так ли ?)

Ну что, будешь и дальше самосливаться и разводить демагогию со своими:
Не_может_быть_отрицательных_смещений_применительно_к_стеку [может]
Это именно опечатка [нет, не опечатка]
Сейчас_аргументы_функций_в_стеке_не_хранятся [хранятся. Только теперь их туда на вызываемой стороне заталкивают, а не на вызывающей как раньше, если нельзя жестоко соптимизировать]
Вместо честного признания, что дуб-дубом и просто нахватался верхов прежде, чем хотя бы глянуть функцию в дизасме ?

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

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

>> pop     rbp
>> ret
> Возьми за правило указывать ключи транслятора, когда публикуешь листинг. Это поможет тебе
> самому избежать ряд ошибок.
> Вот как должен был выглядеть твой пример:
> gcc arg.c -S -fverbose-asm -masm=intel -o arg.s

Только я на clang'е собирал, о чем выше упоминал. Ну куда уж заморачиваться о таких мелочах избирательно-слепому, не так ли ?
Поначалу, кстати, хотел с гнутого дизасм, но там смещения не так лаконично смотрелись. Если сравнишь с моим( шланг ) - увидишь, что -20 там нет - смещения идут красиво аккурат на размер указателя/значения_переменной ( 4, 8, 12 против 20,  8, 4 )

>> mov     dword ptr [rbp - 4], edi
>> mov     dword ptr [rbp - 8], 123
>> mov     dword ptr [rbp - 12], 456

// выше - шланговский. Все ровненько, по 4 байта

> mov    DWORD PTR -20[rbp], edi
> mov    DWORD PTR -8[rbp], 123
> mov    DWORD PTR -4[rbp], 456

// выше - твой, гнутый

// Твой полный выхлоп дизасма
> testFunc:
> .LFB0:
> .cfi_startproc
> и еще куча текста и ненужных директив

Я тебе предоставил максимально компактный листинг чтобы пост не засорять
>>>> Можешь даже онлайн-преобразователями что-то -> асм воспользоваться типа:
>>>> https://godbolt.org/

Тем более, гораздо удобнее с дизасмом функций возиться в онлайн-сервисе, ссылку на который тебе я кидал ранее и через который "чистый" код и получал без тонн мусора( разумеется, сверив на соответствие с результатом локальной сборки )

> И предпочти изучать код после оптимизатора, это поможет понять, как работает транслятор:

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

И вот, снова несешь какую-то чепуху, теперь про "оптимизатор", хотя тебя вовсе не смущает, что ты "героически" собрал с оптимизациями код, рассчитанный на максимальную простоту, наглядность и компактность, оттого и собираемый БЕЗ оптимизации( иначе - придется делать пример сильно сложнее, постить горы текста, а итог будет тем же - нормальность отрицательных смещений, хранение данных локальных переменных в стеке, как и аргументов функции, обращение к ним через отрицательное смещение стека и твоя откровенная невежественность, как и неспособность признать свою неправоту )

> gcc arg.c -O2 -S -fverbose-asm -masm=intel -o arg.s
> 

 
> testFunc: 
> .LFB0: 
>  .cfi_startproc 
> # arg.c:4:    return tmp1 * arg; 
>  imul eax, edi, 123 # tmp84, tmp85, 
> # arg.c:5: } 
>  ret 
>

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

>>> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
>> Это все здорово кнчн, но что если аргументов будет больше чем регистров
>> ?) -Ну это к слову о не_использовании стека.
> Для этого в скобочках и написано, что надо посмотреть.

Как !? Ты вывалил гору мусора вплоть до примера передачи аргументов в (!) процесс но поленился сказать несколько слов по теме ?)

>> Тем более, что мире существует далеко не только линух со своими соглашениями
> Здесь Линукс является системой по умолчанию. Архитектуру процессора ты выбрал сам, я
> лишь её актуализировал.

Здесь - это у тебя в голове ? На сайте полно людей и с виндой, и с бздей.. и с яблоком немало.

>> о вызовах( хотя и в 32-битном линуховом очень даже применялся стек
>> )
> Ну вот и посмотрел бы, как именно он применялся, вместо эффектных попыток
> продемонстрировать свою базу.

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

> Пока получается в стиле "сделайте это за меня".
> Вот так передаются параметры процессу (тут немного лишнего, но оставлю как есть):

троллейбус_из_буханки.jpg

Серьезно, зачем тут это, если речь о вызываемых функциях, локальных переменных и стеке, а не о передаче параметров процессу ?

> ; Допустим 1 аргумент - имя файла байт-кода.
>  mov rcx, [rsp] ; argc
> ...
>  mov [bytecode_filename], rdi
> ; Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
> ; слов после argv (rsp + 8)
>  lea rdx, [rsp + 8 + (rcx + 1) * 8]

Кстати, забавная ситуация. Ты тоже пишешь комменты НАД комментируемой строкой..
Теперь у меня совсем нет идей, почему в случае с предоставленным мной кодом ты ИНОГДА смотрел на строку, которая была НАД комментом а не под ним и нес чепуху исходя из этого.
Хотя и была мысль, что ты пишешь комменты под целевой строкой и, по привычке, так же начал смотреть в чужой код.. но очевидно нет. Это просто твой очередной косяк.

Ну что, признаешь, что был неправ практически во всем, начиная от моей "опечатки" с отрицательным смещением стека, нахождению аргументов функции в стеке( теперь их туда заталкивают на стороне вызываемой функции, а не вызывающего.. но обращение к ним в итоге все так же в основном через стек ) и вплоть до исключительно_одного_интерпретатора в современном жс( и следующей из этого не_относимости_жс_кода к реальному пробу и стеку ) ?

Ответить | Правка | Наверх | Cообщить модератору

185. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от n00by (ok), 22-Июл-21, 13:40 
>>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>>> разы ты славно попадался на подмене понятий )
>> Потому что у тебя проблемы с памятью https://www.opennet.me/openforum/vsluhforumID3/124773.html#51
>> (заметь, что пруфы просил не я, я их за тебя предоставил;
>> но там малость неувязка по срокам санкций, длиною в треть твоей
>> жизни), при этом ты очень хорошо умеешь в "а нас то
>> за шо?", что как бэ намекает.
> И в чем конкретно ложь ?

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

> Заодно и на себя сошлись со своим не_бу_а_списанным_оборудованием, которое у тебя вдруг
> синонимом стало )

Уймись уже с этим "а нас за шо?" Исключительный нашёлся.

>> Я прав в том, что сам ты ничего в данном направлении не сделал
> Нет бы по честному признаться, что от души обделался с исключительно_интерпретатором в
> жс и отсутствием реального исполнения кода на процессоре - нет же,
> маню включаешь.
> Хотя, что от тебя еще ожидать..

Чуешь запашок из шаровар? Это потому что ты не показал код, который генерирует JIT.

>[оверквотинг удален]
>>> локальных переменных или ссылок на них.. даже не просто не доказал,
>>> но и сделал вид что этого нет..
>> Это называется -- переложить бремя доказательства на оппонента. Приём демагогии такой.
>> Мне не требуется что-либо опровергать, поскольку исходное твоё утверждение голословно.
>> Тем не менее, скажу по секрету. Пример, на который я выше
>> дал ссылку (2й фрагмент), как раз это и делает. Но к
>> вопросу отношения не имеет. И я не знаю, как бы его
>> к нему прикрутить.
> Ты неправильно разобрал даже простейший предоставленный мной пример функции на сях и
> на асме с комментариями, у тебя вдруг то включалась избирательная слепота,

Ну надо же. Когда Алёша смотрит на переданный в edi аргумент и заявляет, что он якобы передан через стек -- это у него, выходит, не слепота включается. Тем хуже для Алёши: получается, он сознательно врёт.

> то - отключалась память и ты забывал, НАД целевой строкой написан
> коммент или ПОД ней [хотя как позже оказалось ты и сам
> пишешь комменты НАД целевой строкой. Т.е ты даже про свои привычки
> забывал]
> Так.. как и почему в свете этого можно верить твоей кодовой чепухе,
> которую ты называешь "доказательством" чего-то ?
>>> ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
>>> mov     dword ptr [rbp - 4], edi

Да хоть в межушный ганглий он пусть "заталкивается". Это происходит после вызова. Передан он в регистре.

>>> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
>>> mov     dword ptr [rbp - 8], 123
>>> ...
>>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>>> imul    eax, dword ptr [rbp - 4]
> Выше, как видишь, кусок предоставленного мной кода с комментами.

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

>>> mov     eax, dword ptr [rbp - 8]
>>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>> Нет, это локальная переменная tmp1.
>>> imul    eax, dword ptr [rbp - 4]
>> А вот здесь как раз и должна была быть попытка выдать желаемое
>> за действительное, но автор в горячке перепутал строчки.
> Тебя ведь вовсе не смутило, что везде комменты написаны НАД комментируемой строкой(
> даже ты сам, как оказалось, именно так пишешь ), а не
> ПОД ней, не так ли ?)

Тюююашотакова. Шо, с тобой нельзя поступать зеркально?

>[оверквотинг удален]
> и демагогом, не способным признать собственные очевидные ошибки и пытающимся изо
> всех сил сменить тему.
>>> pop     rbp
>>> ret
>> Возьми за правило указывать ключи транслятора, когда публикуешь листинг. Это поможет тебе
>> самому избежать ряд ошибок.
>> Вот как должен был выглядеть твой пример:
>> gcc arg.c -S -fverbose-asm -masm=intel -o arg.s
> Только я на clang'е собирал, о чем выше упоминал. Ну куда уж
> заморачиваться о таких мелочах избирательно-слепому, не так ли ?

Выше Алёша писал "хотя и у гцц примерно то же самое", но ныне у него склероз. GCC с -fverbose-asm  явственно комментирует, что аргумент пришёл в регистре и создаётся его копия:

mov    DWORD PTR -20[rbp], edi    # arg, arg

Потому Алёша старательно этот нюанс выкидывает и забалтывает.

> Серьезно, зачем тут это, если речь о вызываемых функциях, локальных переменных и
> стеке, а не о передаче параметров процессу ?

Потому что, Алёша, когда аргументы передаются через стек, сначала уменьшается указатель стека, потом аргументы размещаются на его вершине. Таким образом в теле вызванной подпрограммы для доступа к аргументам следует применять арифметику с обратным знаком. Так получается положительное относительно указателя стека смещение. Ты оказался слишком глуп, что бы самостоятельно в этом разобраться, поэтому я показал тебе рабочий код. Но ты даже прочесть его не осилил.

>[оверквотинг удален]
>> ; Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
>> ; слов после argv (rsp + 8)
>>  lea rdx, [rsp + 8 + (rcx + 1) * 8]
> Кстати, забавная ситуация. Ты тоже пишешь комменты НАД комментируемой строкой..
> Теперь у меня совсем нет идей, почему в случае с предоставленным мной
> кодом ты ИНОГДА смотрел на строку, которая была НАД комментом а
> не под ним и нес чепуху исходя из этого.
> Хотя и была мысль, что ты пишешь комменты под целевой строкой и,
> по привычке, так же начал смотреть в чужой код.. но очевидно
> нет. Это просто твой очередной косяк.

Да, это мой косяк: я связался со старательно не замечающим + 8 + (rcx + 1) * 8 идиотом и пустозвоном в одном лице.

Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/–
Сообщение от n00by (ok), 17-Июл-21, 19:05 
> Аргументы в функции обычно передаются через стек

Нет, Алёша, это так было обычно, когда ты в школе на уроке истории книжку Зубкова читал. Лет десять-пятнадцать уже всё немного не так:

; Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
;
; Сохраняются при вызовах внешних функций: RBX RBP RSP R12 R13 R14 R15
;
; Параметры передаются в регистрах:
; RDI    1й
; RSI    2й
; RDX    3й
; RCX    4й    ; R10 для вызовов ядра
; R8    5й
; R9    6й

Впрочем, это не имеет отношения к вопросу, который ты так и не доказал.

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

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

144. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/–
Сообщение от pavlinux (ok), 18-Июл-21, 19:05 
......  
Ответить | Правка | Наверх | Cообщить модератору

112. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/–
Сообщение от n00by (ok), 17-Июл-21, 18:45 
> аргументы могут извлекаться
> Но адрес возврата в любом случае остаётся

Вот это, кстати, пёрл редкостного качества. Вроде как есть у человека какое-то представление, но суть перевёрнута с ног на голову. И ведь мог бы, прежде чем писать эту чушь, хотя бы картинки посмотреть. Примечательно, что именно такие и топят за Rosa Tresh.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

57. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/–
Сообщение от пох. (?), 17-Июл-21, 11:19 
> Тем более, ничего не мешает при достижении энных размеров, завершать обработку с
> сигналом «слишком толсто».. и с циклом это сделать сильно проще.

в принципе, одинаково, но при написании цикла гораздо быстрее осознаешь, что да, надо добавлять ограничитель.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру