Re: Strange switching [threadname] to secondary mode after exception #0 in kernel-space at 0x80272444

["François Legal" <devel@thom.fr.eu.org>]

Le Vendredi, Octobre 16, 2020 10:59 CEST, Philippe Gerum <rpm@xenomai.org> a écrit:

>
> François Legal <devel@thom.fr.eu.org> writes:
>
> > Le Mercredi, Octobre 14, 2020 16:16 CEST, Greg Gallagher <greg@embeddedgreg.com> a écrit:
> >
> >> On Wed, Oct 14, 2020 at 5:37 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >> >
> >> > On 14.10.20 10:43, François Legal via Xenomai wrote:
> >> > > Anybody can help on this ?
> >> > >
> >> >
> >> > I'm unfortunately not familiar with the armv7 details of copy-from-user,
> >> > not too speak of how spectre contributed to it. Greg, Philippe, did you
> >> > come across this already?
> >> >
> >> > Jan
> >> >
> >> I'll take a look tonight but I haven't hit this in my testing.  This
> >> was found on 4.4? Have you tried the 4.19 kernels?
> >>
> >> -Greg
> >
> > So I tried the same case on 4.19.121, with the same result, and I guess for the same reason.
> > Could anybody explain why, on ARMv7, we need to copy the message header at the syscall entry, and not let the xxxmsg routine do it on its own ?
> > Also, I could not find how those COBALT_SYSCALL32emu logic work.
>
> There is no way an armv7 system would run the sys32emu code in
> Cobalt. This code path is specific to architectures which support mixed
> ABI models. Only Cobalt/x86 supports this so far, issuing x86_32
> syscalls to an x86_64 kernel. You may want to check
> CONFIG_XENO_ARCH_SYS3264, it is set to "def_bool n" in the Kconfig
> stuff.
>

Maybe I don't use the right terms here, but what I can see from the code is (in linux tree kernel/xenomai/posix/syscall32.c)
COBALT_SYSCALL32emu(sendmsg, handover,
		    (int fd, struct compat_msghdr __user *umsg, int flags))
{
	struct user_msghdr m;
	int ret;

	ret = sys32_get_msghdr(&m, umsg);

	return ret ?: rtdm_fd_sendmsg(fd, &m, flags);
}

And the problem regarding SPECTRE mitigation is with the "ret = sys32_get_msghdr(&m, umsg);" line, as af_packet (in my case, but I believe the other handlers should do the same) will also call copy_from_user on the "msghdr" argument, and the SPECTRE mitigation will check that this pointer is in the userland MM area.

> Converting long/pointer data conforming to a 32bit ABI to their 64bit
> representation is the reason why the sys32/compat wrappers exist and are
> compiled in when CONFIG_XENO_ARCH_SYS3264 is set. Aggregates arguments
> such as msg headers do contain such data.
>
> > Can anybody point me to some documentation ?
> >
>
> There is none, I'm afraid.
>
> --
> Philippe.