Fwd: [Patch 1/5] Problems with upstream SPECTRE mitigation found in sendmsg/recvmsg syscalls

Jan Kiszka jan.kiszka at siemens.com
Fri Dec 11 14:31:25 CET 2020

On 11.12.20 10:30, François Legal wrote:
> Le Vendredi, Décembre 11, 2020 09:36 CET, Jan Kiszka <jan.kiszka at siemens.com> a écrit: 
>> On 11.12.20 09:05, François Legal wrote:
>>> Le Vendredi, Décembre 11, 2020 07:55 CET, Jan Kiszka <jan.kiszka at siemens.com> a écrit: 
>>>> On 07.12.20 11:55, François Legal via Xenomai wrote:
>>>>> From: François LEGAL <devel at thom.fr.eu.org>
>>>>> Remove the copy of struct struct user_msghdr onto stack allocated buffer.
>>>> Reasoning is missing here: The driver callbacks are supposed to do that
>>>> copy-from-user.
>>>> But the Question is: why? Is that local copy history left-over, or do
>>>> only the drivers know how much to copy?
>>>> Jan
>>> Hi Jan,
>>> The drivers are effectively doing that, hence the problem that happens with SPECTRE mitigation activated (at least on arm arch).
>>> About the length of the copy, the drivers do about the the same, sizeof (struct user_msghdr)
>> Then we should move the common code into the common place, i.e. drop the
>> copies in the drivers instead.
> I wonder, because from what I could read on RTIPC, these driver functions seems to be callable from kernel context (see rtipc_get_arg() ).
> There is a risk of trigging SPECTRE mitigation in case is is called from kernel no, or maybe it does not get called through posix/io.c ?

RTDM drivers can call each other, and that can create a non-user entry
to callbacks. rtipc_get_arg accounts for that via

If we consolidate again over "callbacks get user_msghdr from kernel
memory" (but nothing that this struct my point to), no driver needs to
copy that struct, just the syscall entry code.


Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

More information about the Xenomai mailing list