Re: Fix for RTAI faults on recent x86 CPUs

Hello Paolo,

I checked the bios setting of the i3-6100 system.
SW Guard Extension (SGX) was disabled.
Although the idea of SGX suggests itself, the problem might have another cause.

Josef


-----Ursprüngliche Nachricht-----
Von: Rtai [mailto:[email protected]] Im Auftrag von Paolo Mantegazza
Gesendet: Donnerstag, 25. Mai 2017 10:35
An: rtai
Betreff: [Rtai] 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



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