Fix for RTAI faults on recent x86 CPUs

Un ciao a tutti,

On 5.10.2017, in relation to an email thread, started by Josef 
(Assfalg), about rtai-5.0 not working on Intel i3-4100 while faulting, 
whatever kernel was being used, on the more recent i3-6100, I wrote:

"If you want to go on and diagnose it, to avoid flooding this list with 
something that may be of little interest to RTAI users, I'd  suggest to 
continue this thread privately. We'll report back to the list if and 
when we'll fix it."

Now, here we are with a fix. For it you should download rtai-5.0.1 from 
"RTAI users contributions", not from the releases repository.

I'm not completely sure but the same problem may have bitten a few other 
users. Notably Bill (Jenkins) for having insisted a bit on reporting it, 
without any solution from side.

Eventually Josef did something very convincing for me. He installed RTAI 
on i3-4600 and got it working well. Then simply took the disk from it 
and used it on the i3-6100, without any change. Thus he verified that 
kernel space was still OK but not the user space.

Such results addressed something wrong in the RTAI syscall, a difficult 
thing to digest on my side, since it has worked for almost 15 years, not 
only for x86 but for PPC, ARM and M68K also. Moreover, RTAI-5.0 is a 
release that was kept sleeping for more than a year. Nonetheless, during 
such a lapse of time has been intensively used and tested in house.

So Josef had to be patient and loose a week running my fixes, aimed at 
preserving RTAI as it is. That means, passing syscall args on the stack 
and having them used directly, as normal variables and arrays, without 
any copy to/from kernel support.

Now, the use of the same disk seems to point out that i3-6100 
(i.e.Skylake archs) has a memory protection mechanism 
(https://en.wikipedia.org/wiki/Software_Guard_Extensions?) blocking such 
an exploit, between kernel and user level permission, at the very 
hardware level.

Marco (Morandini) has pointed me to the following link: 
https://lwn.net/Articles/689395/. From it one could infer that the new 
protection mechanism has been cared at the kernel level since 4.8. 4.9 
has a couple of new sys call, mprotect and pkey_mprotect, not yet in 
glibc though.

Nonetheless, as said and since the problem has been traced back to 
Linux-3.16, it is likely that some form of protection is at work by 
default anyhow. I'll be glad if somebody can explain it more cleanly and 
clearly to me.

Anyhow, I did not dig further in the subject but simply surrendered to 
the "canonical" way of working in the kernel.

The fix will cover most of RTAI. There are todos for user space COMEDI 
and serial support. They will come soon.

Since I've not any such recent CPUs available, as seen working with 
Josef,  the problem is that half fixes will work on my machines in any 
case, but not where they are needed. Anybody wanting to donate a 
troubled hardware for a sound verification is welcomed :-).

Please, if you suspect to have been caught  in the same problem, 
download and test the above new release and let me (and this list) know.

Thanks to Josef and his patience.

Paolo.


_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai