Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I do not know why the JMP is not just a RET, however.

This is caused by the CONFIG_RETHUNK option. In the disassembly from objdump you are seeing the result of RET being replaced with JMP __x86_return_thunk.

https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...

https://github.com/torvalds/linux/blob/v6.1/arch/x86/lib/ret...

> The NOP instructions at the beginning and at the end of the function allow ftrace to insert tracing instructions when needed.

These are from the ASM_CLAC and ASM_STAC macros, which make space for the CLAC and STAC instructions (both of them three bytes in length, same as the number of NOPs) to be filled in at runtime if X86_FEATURE_SMAP is detected.

https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...

https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...

https://github.com/torvalds/linux/blob/v6.1/arch/x86/kernel/...



There are perhaps only a handful of kernel developers that:

1. would know the above

2. would choose such an obnoxious throwaway handle


I believe there are a lot more of your 2nd point than you might think.


And certainly those interested in the performance implications of the retpoline mitigation for the various speculative execution information leaks.


Have you accounted for the population of Australian kernel developers?


Good point; in that case I may have undercounted! :P

That said, most Aussie kernel devs I know are IBM PPC Ozlabs folks that are actually really nice!


Thanks a lot for the information! I was not quite sure what to look for in this case. I have added in note in the article.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: