MV
в wasi-libc аллокаторе при выделении большого размера выделяется напрямую с помощью memory_grow
Size: a a a
2020 August 03
MV
а не внутренних bin листов dlmalloc
M
в wasi-libc аллокаторе при выделении большого размера выделяется напрямую с помощью memory_grow
Насколько я знаю все контракты ограничивают макс колличество страниц. И там оно сильно ниже 2 ** 16
MV
+ там есть т.н.
simple_malloc, которую линкуется в случае, если в программе нет free, чтобы не тащить весь dlmalloc. А он хорош в данном случае тем, что там не заголовков чанков аллокаций (в которых могут быть \x000).M
+ там есть т.н.
simple_malloc, которую линкуется в случае, если в программе нет free, чтобы не тащить весь dlmalloc. А он хорош в данном случае тем, что там не заголовков чанков аллокаций (в которых могут быть \x000).Ну типичный bump аллокатор
MV
Ну типичный bump аллокатор
да
MV
Насколько я знаю все контракты ограничивают макс колличество страниц. И там оно сильно ниже 2 ** 16
ну вот это проблема да, но мало ли где можно ограничения самому выбрать
MV
кстати, интересно, с учётом jit'а к чему можно доступ так получить
M
кстати, интересно, с учётом jit'а к чему можно доступ так получить
Ни к чему. Если выйдешь за пределы линейной памяти получишь oob trap
MV
Ни к чему. Если выйдешь за пределы линейной памяти получишь oob trap
это только потому что load/store 32-битными числами оперируют
MV
а если ты сможешь выделить (пока не будем в даваться в подробности как) исполняемый x86_64 код в васм памяти, то это не спасёт
MV
в смысле в гипотетической ситуации когда этот heap overflow легко конвертится в arbitrary jump и мы (каким-то образом) записали в васм кучу исполняемый x86_64 код, то можно прыгнуть на него (ну тут ещё точный адрес нужно знать)
M
а если ты сможешь выделить (пока не будем в даваться в подробности как) исполняемый x86_64 код в васм памяти, то это не спасёт
Не очень понял. При oob в песочнице ты будешь пытаться писать в guarded page и ос выкинет тебе исключение. Ну для linux / unix по крайней мере
lp
так я не понял, тот код разве не изнутри wasm'а?
MV
так я не понял, тот код разве не изнутри wasm'а?
внутри, но он джитится в x86_64 же
MV
т.е. в конечном итоге он выполняется, как просто x86_64 asm
lp
безусловно, только действительно все load/store ограничены песочницей.
lp
то что доступны только 32-битные адреса дела не меняет
M
Так, во первых насколько мне известо все блокчейны используют стримовые AOT компиляторы или интерпретаторы
MV
Не очень понял. При oob в песочнице ты будешь пытаться писать в guarded page и ос выкинет тебе исключение. Ну для linux / unix по крайней мере
ну ты можешь же просто создать статическую переменную с шеллкодом, она будет загружена в васм память