tgoop.com/tech_b0lt_Genona/5725
Last Update:
Есть такой популярный в узких кругах инструмент Valgrind
https://valgrind.org/docs/manual/QuickStart.html
Создан он для того, чтобы искать утечки памяти, оценивать управление памятью и в целом профилировать её.
О Valgrind я упоминал ранее
https://www.tgoop.com/tech_b0lt_Genona/4832
https://www.tgoop.com/tech_b0lt_Genona/5340
Чаще всего, из того что я видел, Valgrind использовался для программ написанных на C\C++. Это и логично учитывая, сколько проблем там возникает из-за работы с памятью.
И тут ВНЕЗАПНО11!! его поддержку завезли в Go.
Вот обсуждение из 2010 года (самое раннее, которое нашёл), где интересуются, а есть ли что-то похожее для Go
https://groups.google.com/g/golang-nuts/c/Vy5dDw0-fCY
Также я находил посты в которых пытались дебажить и Go-шный софт
Вот, например
Hunting down a C memory leak in a Go program
https://zendesk.engineering/hunting-down-a-c-memory-leak-in-a-go-program-2d08b24b617d
Но там возникали проблемы
> Our app is actually correctly freeing it’s “leaked” memory before it exits. Valgrind produces its leak report at the end of program execution by comparing what it gave out by malloc to what it received back by free, and printing out any unpaired malloc invocations. However, if our app actually does call free on all its memory before terminating, then Valgrind won’t see a leak, even if the actual amount of memory first allocated is totally unbounded!
> When we correctly destroy the librdkafka handle during app shutdown, however, all the memory from this queue gets released: Valgrind never saw a leak.
Есть посты о том, как успешно применили Valgrind, но как по мне эта успешность весьма условная: типа мы видим что что-то не так, но что бы понять нам надо взять что-то ещё. Киньте ссылок в комменты, если есть реально успешные случаи.
Вот обсуждение в issue с пояснениями
> Go doesn't support valgrind, but does support asan, msan, and tsan, which work with clang, and perhaps gcc.
valgrind fails
https://github.com/golang/go/issues/60600
Вот объяснение в proposal'е (на который собственно и ссылается имплементация https://go-review.googlesource.com/c/go/+/674077)
> Go uses mmap (which Valgrind understands) to map a large memory region and then uses our own allocator to handle allocating objects from that region. We allocate both the heap, and individual stacks, from this region. This behavior confuses Valgrind.
add valgrind hints to the runtime under special build mode
https://github.com/golang/go/issues/73602
Да и вообще, казалось бы, зачем все эти приседания, если есть GC?
Если кратко, то для
- Анализа памяти в runtime
- Проверки и обеспечения константного времени выполнения для криптографии
С первым пунктом всё понятно, а для второго немного пояснений.
Если атакующий может каким-либо образом замерять время которое требуется алгоритму для обработки входных данных, то это может дать "зацепку" для подбора ключа. Соответственно, в proposal'е описывается как Valgrind может помочь в этом
> uninitialized memory taint analysis that Valgrind does looks very similar to how we would want to analyze constant-time code. Namely, we care about conditional instructions that operate on sensitive memory, which Valgrind has all the machinery for, just that it cares about uninitialized memory. We can slightly abuse this Valgrind behavior by simply marking sensitive memory as uninitialized, and seeing if Valgrind ever complains about branching behavior that relies on it
Вот пост из 2010 года про подход
Checking that functions are constant time with Valgrind
https://www.imperialviolet.org/2010/04/01/ctgrind.html
Вот большой пост от BearSSL, если кому-то интересно будет углубиться в эту тему
Why Constant-Time Crypto?
https://bearssl.org/constanttime.html
В целом, конечно, штука хорошая и должна помочь сделать софт на Go лучше и стабильней.
Обсуждение на HN
https://news.ycombinator.com/item?id=45344708
ЗЫ Поправьте меня, но я не вижу тестов в патче (см. скрин) 🌝
BY Технологический Болт Генона
Share with your friend now:
tgoop.com/tech_b0lt_Genona/5725