rseq, membarrier and seccomp

rseq, membarrier and seccomp

[Mathieu Desnoyers]

Hi Florian,

I recall that the important projects using seccomp were modified to whitelist
rseq some time ago.

If we plan on requiring co-availability of membarrier MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
(not sure how you plan the programming model exposed by glibc wrt rseq vs membarrier availability),
we may then want those projects to whitelist membarrier as well.

Perhaps this is something to bring to their attention ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: rseq, membarrier and seccomp

[Florian Weimer]

* Mathieu Desnoyers via Libc-alpha:

> If we plan on requiring co-availability of membarrier
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ (not sure how you plan the
> programming model exposed by glibc wrt rseq vs membarrier
> availability), we may then want those projects to whitelist membarrier
> as well.

I don't think we can get MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
integration done in time for the glibc 2.35 release.  The kernel version
gap between rseq and this is also fairly large, so I expect there will
be users interested in the rump rseq we have today.

Thanks,
Florian

Re: rseq, membarrier and seccomp

[Mathieu Desnoyers]

----- On Dec 16, 2021, at 4:17 PM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers via Libc-alpha:
> 
>> If we plan on requiring co-availability of membarrier
>> MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ (not sure how you plan the
>> programming model exposed by glibc wrt rseq vs membarrier
>> availability), we may then want those projects to whitelist membarrier
>> as well.
> 
> I don't think we can get MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
> integration done in time for the glibc 2.35 release.  The kernel version
> gap between rseq and this is also fairly large, so I expect there will
> be users interested in the rump rseq we have today.

I agree with your assessment. This just means that users will have to
individually query glibc for rseq and membarrier-private-expedited-rseq
availability.

The query for rseq availability is done by checking that __rseq_size != 0,
and the query for membarrier availability still has to be designed/implemented
as future work.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: rseq, membarrier and seccomp

[Florian Weimer]

* Mathieu Desnoyers:

> The query for rseq availability is done by checking that __rseq_size != 0,
> and the query for membarrier availability still has to be designed/implemented
> as future work.

MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ should be much easier, though,
given that it's a process-wide resource.  I don't see why interested
applications can't make the system call directly today.  Apart from the
hypothetical negative performance impact on the scheduler, it should not
be observable at all whether some other library in the process also has
made the registration.

rseq is so different because there can be at most one area per thread.
There are very few kernel interfaces with this property, with good
reason.

Thanks,
Florian

Re: rseq, membarrier and seccomp

[Mathieu Desnoyers]

----- On Dec 16, 2021, at 4:25 PM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers:
> 
>> The query for rseq availability is done by checking that __rseq_size != 0,
>> and the query for membarrier availability still has to be designed/implemented
>> as future work.
> 
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ should be much easier, though,
> given that it's a process-wide resource.  I don't see why interested
> applications can't make the system call directly today.  Apart from the
> hypothetical negative performance impact on the scheduler, it should not
> be observable at all whether some other library in the process also has
> made the registration.
> 
> rseq is so different because there can be at most one area per thread.
> There are very few kernel interfaces with this property, with good
> reason.

Agreed, unlike rseq, there is no need for having a single membarrier
registration "resource owner".

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com