[Question] Why unsigned long argument may be an obstacle to the control-flow integrity?

[QiuhaoLi]

In 13.2 Flashing keyboard LEDs, it mentioned "Furthermore, the function prototype with unsigned long argument may be an obstacle to the control-flow integrity."

struct timer_list { 
    unsigned long expires; 
    void (*function)(unsigned long);  // <---
    unsigned long data; 
    u32 flags; 
    /* ... */ 
}; 

Could you make it clear why this argument prevents the control-flow integrity check? As far as I know, hardware-assisted CFI like intel's CET uses shadow stack for ROP and IBT for JOP/COP, and there is nothing about parameters.

[linD026]

Hi @QiuhaoLi ,
The CFI, like the Clang option here, will check the dynamic type of function call to match the static type correctly.
This kind of function prototype changes with CFI is for forward-edge protection.
The shadow stack that you mentioned is for backward-edge protection.

For more information about timer API changes, you can see this.
Also, here is the commit which changes the API.

---

We didn't mention it because it might be too deep for the beginner.
We will consider again if this kind of description is compatible.
But still, thank you for the feedback!

[QiuhaoLi]

Got it. Thanks for these helpful links! I think you can remove the paragraph about the API changes or give these links you mentioned (or maybe also this one) as additional read materials; otherwise, it's a little confusing for readers :)