Комментарии 7
Хаб называется «Реверс-инжиниринг», а вот подсветки ассемблеров действительно не хватает.
интересно, а если поток оставил частичный контекст, сознательно отдав остаток кванта, а возобновляется затем по таймеру? Несохраненные регистры будут содержать данные другого потока, или инициализированы ядром RTOS?
Заглянул в свою копию исходников ThreadX. Если поток оставил частичный контекст, то в любом случае после его возобновления в несохранённых регистрах будет мусор от предыдущего потока + самой функции schedule.
Спасибо, я так и думал. Хорошо, что в мире RTOS процессы априори дружественны друг другу — в «больших» системах такое поведение считалось бы уязвимостью ;)
в «больших» системах такое поведение считалось бы уязвимостью
В «больших» системах процессы в контексте ядра тоже дружественны друг другу. Если вы заглянете в исходники linux, в реализации функций _switch_to (которые выполняют архитектурно-специфичную работу по переключению контекста), то увидите, что там контекст тоже сохраняется и восстанавливается не полностью. Вот, например: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/entry.S#n556
Ну почему? Это по соглашениям — «мусорные» регистры. Далее, отдача остатка кванта — это, по сути, вызов системной функции, соответственно, возвращение в место выполнения — это возврат из (череды) функций. r0, r1 при этом используются для возврата значения, при этом пишутся туда значения непосредственно перед возвратом, уже после получения управления. Т.е. это всё равно что рассчитывать на какие-то значения в регистрах r0-r3 после возврата из какой-то функции с типом возвращаемого значения — void: в одном и том же коде на разных компиляторах или разных параметрах сборки там будут абсолютно непредсказуемые значения. Если ваш код на этом построен, то да, безопасности может прийти каюк.
Собственно такая проблема может быть только если вы пишите функцию на ассемблере либо баг в компиляторе. В первом случае — вы сами себе враг, во втором случае — главное догадаться посмотреть диззасемблерный листинг, если там будет такое:
bl _proc
cmp r2, #0
то похоже, что-то прогнило в Датском королевстве.
Собственно такая проблема может быть только если вы пишите функцию на ассемблере либо баг в компиляторе. В первом случае — вы сами себе враг, во втором случае — главное догадаться посмотреть диззасемблерный листинг, если там будет такое:
bl _proc
cmp r2, #0
то похоже, что-то прогнило в Датском королевстве.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenOCD, ThreadX и ваш процессор