fortify_source and syscall wrapping

Jan Kiszka jan.kiszka at siemens.com
Thu Sep 10 13:04:07 CEST 2020


On 10.09.20 12:37, Jan Leupold via Xenomai wrote:
> Hi all,
> 
> I just had a long debugging session and wanted to comment the result here
> on the list.
> 
> When using -D_FORTIFY_SOURCE=2 the first ioctl() after open() suddenly
> failed. This is due to an inline function "open()" (in bits/fcntl2.h),
> that will analyse the call arguments and forward the function call
> accordingly. When the second argument is not a compile-time constant,
> then the call is forwarded to "__open_2()" instead of "__open_alias()".
> 
> So when you write:
> 
> open("/dev/rtdm/rtser0", O_RDWR);
> 
> then __cobalt_open() will be called. But when you use a function like
> this:
> 
> int my_function(int mode) {
>     return open("/dev/rtdm/rtser0", mode);
> }
> 
> then __open_2() will be called. The consequence is that the following
> ioctl(RTSER_RTIOC_SET_CONFIG) fails, as the file descriptor was not
> opened by __cobalt_open().
> 
> This is a nasty little difference. My solution was to write:
> 
> int my_function(int mode) {
>     return __WRAP(open("/dev/rtdm/rtser0", mode));
> }
> 
> Maybe this is just ancient history for you, but I had some "fun" to find
> this.
> 

Not at all - thanks for reporting! We already handle the open vs. open64
case. I do not see a reason that speaks against including this case as
well, i.e. adding more wrappers. Patches welcome.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list