[Xenomai] SMAP-detected direct userspace access

[Xenomai] SMAP-detected direct userspace access

[Jan Kiszka]

Hi all,

I know this is legacy code, but this is where we currently stumbled into
it, and maybe the same pattern also exists in 3.x:

http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182

more precisely:

    return pse51_mutex_check_init(&umx->shadow_mutex, attr);

Here we pass the userspace object for initialization to the core instead
of handing over the kernel shadow and then copying over the result. Is
there a reason for this? Could we have more of such cases?

Background: SMAP detects and prevents any direct userspace memory access
on x86 except or those that are wrapped in stac() and clac() (which
toggle a bit in eflags). Generally a useful feature we should allow to
be enabled for robustness reasons.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] SMAP-detected direct userspace access

[Philippe Gerum]

On 12/18/2015 05:23 PM, Jan Kiszka wrote:
> Hi all,
> 
> I know this is legacy code, but this is where we currently stumbled into
> it, and maybe the same pattern also exists in 3.x:
> 
> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
> 
> more precisely:
> 
>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
> 
> Here we pass the userspace object for initialization to the core instead
> of handing over the kernel shadow and then copying over the result. Is
> there a reason for this? Could we have more of such cases?
> 
> Background: SMAP detects and prevents any direct userspace memory access
> on x86 except or those that are wrapped in stac() and clac() (which
> toggle a bit in eflags). Generally a useful feature we should allow to
> be enabled for robustness reasons.
> 

As far as 3.x is concerned, I don't think this direct access pattern is
used there, this would have likely caused me some headaches for
supporting the 32/64 mixed ABI models, and I don't remember of any such
headache. At any rate, I don't see any reason to do this in 3.x.

-- 
Philippe.

Re: [Xenomai] SMAP-detected direct userspace access

[Gilles Chanteperdrix]

On Fri, Dec 18, 2015 at 05:23:55PM +0100, Jan Kiszka wrote:
> Hi all,
> 
> I know this is legacy code, but this is where we currently stumbled into
> it, and maybe the same pattern also exists in 3.x:
> 
> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
> 
> more precisely:
> 
>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
> 
> Here we pass the userspace object for initialization to the core instead
> of handing over the kernel shadow and then copying over the result. Is
> there a reason for this? Could we have more of such cases?

Since the user-space is copied from user-space a couple of lines
above, This looks like a typo. Replacing umx->shadow_mutex with
mx.shadow_mutex should avoid the issue.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] SMAP-detected direct userspace access

[Gilles Chanteperdrix]

On Fri, Dec 18, 2015 at 05:23:55PM +0100, Jan Kiszka wrote:
> Hi all,
> 
> I know this is legacy code, but this is where we currently stumbled into
> it, and maybe the same pattern also exists in 3.x:
> 
> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
> 
> more precisely:
> 
>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
> 
> Here we pass the userspace object for initialization to the core instead
> of handing over the kernel shadow and then copying over the result. Is
> there a reason for this? Could we have more of such cases?
> 
> Background: SMAP detects and prevents any direct userspace memory access
> on x86 except or those that are wrapped in stac() and clac() (which
> toggle a bit in eflags). Generally a useful feature we should allow to
> be enabled for robustness reasons.

BTW, I believe most RTnet ioctls have this issue.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] SMAP-detected direct userspace access

[Jan Kiszka]

On 2015-12-18 18:12, Gilles Chanteperdrix wrote:
> On Fri, Dec 18, 2015 at 05:23:55PM +0100, Jan Kiszka wrote:
>> Hi all,
>>
>> I know this is legacy code, but this is where we currently stumbled into
>> it, and maybe the same pattern also exists in 3.x:
>>
>> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
>>
>> more precisely:
>>
>>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
>>
>> Here we pass the userspace object for initialization to the core instead
>> of handing over the kernel shadow and then copying over the result. Is
>> there a reason for this? Could we have more of such cases?
>>
>> Background: SMAP detects and prevents any direct userspace memory access
>> on x86 except or those that are wrapped in stac() and clac() (which
>> toggle a bit in eflags). Generally a useful feature we should allow to
>> be enabled for robustness reasons.
> 
> BTW, I believe most RTnet ioctls have this issue.
> 

Correct, long-pending deficit that will now start to bite back more
seriously. I was always postponing this until some potential userspace
ABI overhaul.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151227/f642dd2d/attachment.sig>

Re: [Xenomai] SMAP-detected direct userspace access

[Gilles Chanteperdrix]

On Sun, Dec 27, 2015 at 06:00:02PM +0100, Jan Kiszka wrote:
> On 2015-12-18 18:12, Gilles Chanteperdrix wrote:
> > On Fri, Dec 18, 2015 at 05:23:55PM +0100, Jan Kiszka wrote:
> >> Hi all,
> >>
> >> I know this is legacy code, but this is where we currently stumbled into
> >> it, and maybe the same pattern also exists in 3.x:
> >>
> >> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
> >>
> >> more precisely:
> >>
> >>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
> >>
> >> Here we pass the userspace object for initialization to the core instead
> >> of handing over the kernel shadow and then copying over the result. Is
> >> there a reason for this? Could we have more of such cases?
> >>
> >> Background: SMAP detects and prevents any direct userspace memory access
> >> on x86 except or those that are wrapped in stac() and clac() (which
> >> toggle a bit in eflags). Generally a useful feature we should allow to
> >> be enabled for robustness reasons.
> > 
> > BTW, I believe most RTnet ioctls have this issue.
> > 
> 
> Correct, long-pending deficit that will now start to bite back more
> seriously. I was always postponing this until some potential userspace
> ABI overhaul.

The ABI overhaul should happen in the 3.1 branch, hopefully real
soon now (tm).

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] SMAP-detected direct userspace access

[Jan Kiszka]

On 2015-12-27 18:41, Gilles Chanteperdrix wrote:
> On Sun, Dec 27, 2015 at 06:00:02PM +0100, Jan Kiszka wrote:
>> On 2015-12-18 18:12, Gilles Chanteperdrix wrote:
>>> On Fri, Dec 18, 2015 at 05:23:55PM +0100, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> I know this is legacy code, but this is where we currently stumbled into
>>>> it, and maybe the same pattern also exists in 3.x:
>>>>
>>>> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/skins/posix/syscall.c#n1182
>>>>
>>>> more precisely:
>>>>
>>>>     return pse51_mutex_check_init(&umx->shadow_mutex, attr);
>>>>
>>>> Here we pass the userspace object for initialization to the core instead
>>>> of handing over the kernel shadow and then copying over the result. Is
>>>> there a reason for this? Could we have more of such cases?
>>>>
>>>> Background: SMAP detects and prevents any direct userspace memory access
>>>> on x86 except or those that are wrapped in stac() and clac() (which
>>>> toggle a bit in eflags). Generally a useful feature we should allow to
>>>> be enabled for robustness reasons.
>>>
>>> BTW, I believe most RTnet ioctls have this issue.
>>>
>>
>> Correct, long-pending deficit that will now start to bite back more
>> seriously. I was always postponing this until some potential userspace
>> ABI overhaul.
> 
> The ABI overhaul should happen in the 3.1 branch, hopefully real
> soon now (tm).
> 

Cool!

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151227/3f2c07a0/attachment.sig>