Re: Fix for RTAI faults on recent x86 CPUs

"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: "

should be read as:

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

Paolo

On 05/25/2017 10:34 AM, Paolo Mantegazza wrote:
> 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