gABI extension proposal: PT_SHMMAP

gABI extension proposal: PT_SHMMAP

[H. Peter Anvin]

Hello,

I would like to propose an extension to the ELF gABI, which is analogous
to PT_LOAD except that it requests that the underlying file be
memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for
PT_LOAD.  PT_SHARED or PT_SHLOAD would be other possible names.

The main motivation for this is to allow the Linux kernel vDSO to
finally become as close to an "ordinary" ELF DSO as is possible.  The
vDSO depends on having its kernel-provided data page(s) at a specific
offset from the vDSO code; this is currently done by ad hoc memory
areas, which has a number of problems, especially for mixed-mode programs.

The idea is to convert the vdso to a proper file in one of the
kernel-provided filesystems (e.g. /proc or /sys); by defining this type,
an ELF parser would be able to create the appropriate mappings without
any ad hoc code.

This may be usable for other operating systems or perhaps even in
userspace.  However, if there is no such interest then it would be
possible for Linux to use one of the PT_*OS constants; however, I
generally believe it is better to try to be as inclusive as possible.

	-hpa

Re: gABI extension proposal: PT_SHMMAP

[Cary Coutant]

> I would like to propose an extension to the ELF gABI, which is analogous
> to PT_LOAD except that it requests that the underlying file be
> memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for
> PT_LOAD.  PT_SHARED or PT_SHLOAD would be other possible names.
>
> The main motivation for this is to allow the Linux kernel vDSO to
> finally become as close to an "ordinary" ELF DSO as is possible.  The
> vDSO depends on having its kernel-provided data page(s) at a specific
> offset from the vDSO code; this is currently done by ad hoc memory
> areas, which has a number of problems, especially for mixed-mode programs.
>
> The idea is to convert the vdso to a proper file in one of the
> kernel-provided filesystems (e.g. /proc or /sys); by defining this type,
> an ELF parser would be able to create the appropriate mappings without
> any ad hoc code.
>
> This may be usable for other operating systems or perhaps even in
> userspace.  However, if there is no such interest then it would be
> possible for Linux to use one of the PT_*OS constants; however, I
> generally believe it is better to try to be as inclusive as possible.

I'd prefer not to add a new PT_ value that, for the most part, means
the same thing as PT_LOAD. It would be more appropriate to use a
PT_LOAD segment with a new p_flag value, say PF_SHARED. Would that
work?

-cary

Re: gABI extension proposal: PT_SHMMAP

[hpa]

On June 1, 2017 12:15:52 PM PDT, Cary Coutant <ccoutant@gmail.com> wrote:
>> I would like to propose an extension to the ELF gABI, which is
>analogous
>> to PT_LOAD except that it requests that the underlying file be
>> memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for
>> PT_LOAD.  PT_SHARED or PT_SHLOAD would be other possible names.
>>
>> The main motivation for this is to allow the Linux kernel vDSO to
>> finally become as close to an "ordinary" ELF DSO as is possible.  The
>> vDSO depends on having its kernel-provided data page(s) at a specific
>> offset from the vDSO code; this is currently done by ad hoc memory
>> areas, which has a number of problems, especially for mixed-mode
>programs.
>>
>> The idea is to convert the vdso to a proper file in one of the
>> kernel-provided filesystems (e.g. /proc or /sys); by defining this
>type,
>> an ELF parser would be able to create the appropriate mappings
>without
>> any ad hoc code.
>>
>> This may be usable for other operating systems or perhaps even in
>> userspace.  However, if there is no such interest then it would be
>> possible for Linux to use one of the PT_*OS constants; however, I
>> generally believe it is better to try to be as inclusive as possible.
>
>I'd prefer not to add a new PT_ value that, for the most part, means
>the same thing as PT_LOAD. It would be more appropriate to use a
>PT_LOAD segment with a new p_flag value, say PF_SHARED. Would that
>work?
>
>-cary

That would work fine, and it does indeed probably make more sense.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: gABI extension proposal: PT_SHMMAP

[Suprateeka R Hegde]

Please add it under PF_MASKOS range similar to other existing flags like
PF_MIPS_*, PF_HP_*, etc. May be something like PF_GNU_SHARED.



--
Supra

On 02-Jun-2017 01:08 AM, hpa@zytor.com wrote:
> On June 1, 2017 12:15:52 PM PDT, Cary Coutant <ccoutant@gmail.com> wrote:
>>> I would like to propose an extension to the ELF gABI, which is
>> analogous
>>> to PT_LOAD except that it requests that the underlying file be
>>> memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for
>>> PT_LOAD.  PT_SHARED or PT_SHLOAD would be other possible names.
>>>
>>> The main motivation for this is to allow the Linux kernel vDSO to
>>> finally become as close to an "ordinary" ELF DSO as is possible.  The
>>> vDSO depends on having its kernel-provided data page(s) at a specific
>>> offset from the vDSO code; this is currently done by ad hoc memory
>>> areas, which has a number of problems, especially for mixed-mode
>> programs.
>>>
>>> The idea is to convert the vdso to a proper file in one of the
>>> kernel-provided filesystems (e.g. /proc or /sys); by defining this
>> type,
>>> an ELF parser would be able to create the appropriate mappings
>> without
>>> any ad hoc code.
>>>
>>> This may be usable for other operating systems or perhaps even in
>>> userspace.  However, if there is no such interest then it would be
>>> possible for Linux to use one of the PT_*OS constants; however, I
>>> generally believe it is better to try to be as inclusive as possible.
>>
>> I'd prefer not to add a new PT_ value that, for the most part, means
>> the same thing as PT_LOAD. It would be more appropriate to use a
>> PT_LOAD segment with a new p_flag value, say PF_SHARED. Would that
>> work?
>>
>> -cary
> 
> That would work fine, and it does indeed probably make more sense.
> 

Re: gABI extension proposal: PT_SHMMAP

[H. Peter Anvin]

On 06/07/17 08:54, Suprateeka R Hegde wrote:
> Please add it under PF_MASKOS range similar to other existing flags like
> PF_MIPS_*, PF_HP_*, etc. May be something like PF_GNU_SHARED.

Any particular reason that you feel this is not generally useful?

	-hpa

Re: gABI extension proposal: PT_SHMMAP

[James Y Knight via gnu-gabi]

Why is MAP_SHARED even needed for the linux vdso use-case?

All the mappings created for the vdso are read-only mappings, right?
And on Linux, MAP_PRIVATE mappings already reflect changes made to the
underlying file, so long as the process hasn't written to the page, I
think?

So, if you're intending to use this to implement the "vvar" mapping,
isn't the default MAP_PRIVATE already sufficient?

On Wed, May 31, 2017 at 5:23 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Hello,
>
> I would like to propose an extension to the ELF gABI, which is analogous
> to PT_LOAD except that it requests that the underlying file be
> memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for
> PT_LOAD.  PT_SHARED or PT_SHLOAD would be other possible names.
>
> The main motivation for this is to allow the Linux kernel vDSO to
> finally become as close to an "ordinary" ELF DSO as is possible.  The
> vDSO depends on having its kernel-provided data page(s) at a specific
> offset from the vDSO code; this is currently done by ad hoc memory
> areas, which has a number of problems, especially for mixed-mode programs.
>
> The idea is to convert the vdso to a proper file in one of the
> kernel-provided filesystems (e.g. /proc or /sys); by defining this type,
> an ELF parser would be able to create the appropriate mappings without
> any ad hoc code.
>
> This may be usable for other operating systems or perhaps even in
> userspace.  However, if there is no such interest then it would be
> possible for Linux to use one of the PT_*OS constants; however, I
> generally believe it is better to try to be as inclusive as possible.
>
>         -hpa

Re: gABI extension proposal: PT_SHMMAP

[Cary Coutant]

> Why is MAP_SHARED even needed for the linux vdso use-case?
>
> All the mappings created for the vdso are read-only mappings, right?
> And on Linux, MAP_PRIVATE mappings already reflect changes made to the
> underlying file, so long as the process hasn't written to the page, I
> think?
>
> So, if you're intending to use this to implement the "vvar" mapping,
> isn't the default MAP_PRIVATE already sufficient?

He mentioned that this was for the kernel-provided *data* page,
implying to me that he wants a writable, but still sharable (i.e., not
copy-on-write) mapping.

It seems generally useful to me. I probably wouldn't object to a new
gABI bit, but a little more background would be helpful in deciding.

-cary

Re: gABI extension proposal: PT_SHMMAP

[Suprateeka R Hegde]

On 07-Jun-2017 10:40 PM, H. Peter Anvin wrote:
> Any particular reason that you feel this is not generally useful?

1. The use case provided looks extremely specific to Linux. AFAIK, none
of the unix like HP-UX, Solaris or AIX need this requirement.

2. This looks so specific to a runtime loader that it can be as well
handled as a special case in GNU mmap system (may be in ld.so).

3. Assuming Cary is right in understanding that you want a writable but
still sharable page, such features are not even provided by some of the
legacy unix kernels.

4. Eventually there can be many such flags if we start going with
specific claims. For instance there was a request for
PF_NOREAD/SHF_NOREAD that would help some archs (STM?) to protect code
from being read.

5. Why dont we try to fit this proposal under the bigger one - program
properties - proposed by H.J. ? The theme there is to pass such
information to runtime.

6. Lastly, the proposal looks incomplete:
5-a. The hex value for the proposed flag is missing
5-b. The proposal should be sent to Generic SYS-V ABI group and not
GNU-GABI alone.
5-c. The complete semantics of this flag in a standard form. The
semantics should talk about what is mandatory, what is optional. Is the
current/existing UNIX should be changed to honor this flag or is this
optional?

--
Supra

Re: gABI extension proposal: PT_SHMMAP

[H. Peter Anvin]

On 06/08/17 09:19, Suprateeka R Hegde wrote:
> On 07-Jun-2017 10:40 PM, H. Peter Anvin wrote:
>> Any particular reason that you feel this is not generally useful?
> 
> 1. The use case provided looks extremely specific to Linux. AFAIK, none
> of the unix like HP-UX, Solaris or AIX need this requirement.
> 
> 2. This looks so specific to a runtime loader that it can be as well
> handled as a special case in GNU mmap system (may be in ld.so).
> 
> 3. Assuming Cary is right in understanding that you want a writable but
> still sharable page, such features are not even provided by some of the
> legacy unix kernels.
> 
> 4. Eventually there can be many such flags if we start going with
> specific claims. For instance there was a request for
> PF_NOREAD/SHF_NOREAD that would help some archs (STM?) to protect code
> from being read.
> 

SHF_NOREAD makes total sense - there is no real reason for the current
asymmetry
between the SHF and the PF flags -- you don't need PF_NOREAD because you
already
have PF_R, but there is no SHF_ flag to indicate that a the resulting
segment
should be linked to be !PF_R.

My proposal is also missing that aspect (see below.)


> 5. Why dont we try to fit this proposal under the bigger one - program
> properties - proposed by H.J. ? The theme there is to pass such
> information to runtime.

I think this is completely orthogonal - that would be a program property
rather than a per-segment property?

> 6. Lastly, the proposal looks incomplete:
> 5-a. The hex value for the proposed flag is missing
> 5-b. The proposal should be sent to Generic SYS-V ABI group and not
> GNU-GABI alone.

That is certainly true, but H.J. suggested vetting it here first,
exactly to get the t's crossed and the i's dotted first.  The PT_ vs PF_
question was one.

> 5-c. The complete semantics of this flag in a standard form. The
> semantics should talk about what is mandatory, what is optional. Is the
> current/existing UNIX should be changed to honor this flag or is this
> optional?

So, a slightly refined proposal (if these numbers conflict with newer
allocations/proposals please let me know):


0x00000008 (2^3) - PF_SHARED

	This segment MUST be memory-mapped using MAP_SHARED.  Not
	all operating systems need to support this capability.  If this
	is not possible due to lack of operating system support or
 	because the underlying image is not possible to memory-map,
	the loading of the image should be aborted with an error.

0x00001000 (2^12) - SHF_SHARED

	This section MUST be made part of a PF_SHARED segment when
	linked.

OPTIONALLY, new reserved section names:

	.shrodata	- readonly data section to be mapped shared
	.shdata		- writable data section to be mapped shared
	.shbss		- zerofill section to be mapped shared

Re: gABI extension proposal: PT_SHMMAP

[Suprateeka R Hegde]

On 09-Jun-2017 02:33 AM, H. Peter Anvin wrote:
> 
> SHF_NOREAD makes total sense 

Yes but under processor specific extensions. Not generally.

>> 5. Why dont we try to fit this proposal under the bigger one - program
>> properties - proposed by H.J. ? The theme there is to pass such
>> information to runtime.
> 
> I think this is completely orthogonal - that would be a program property
> rather than a per-segment property?

H.J's design, as far as I remember, was extensible to accommodate such
handshakes between linker and loader. I may be wrong though.

> So, a slightly refined proposal (if these numbers conflict with newer
> allocations/proposals please let me know):
> 
> 
> 0x00000008 (2^3) - PF_SHARED
> 
> 	This segment MUST be memory-mapped using MAP_SHARED.  Not
> 	all operating systems need to support this capability.  If this
> 	is not possible due to lack of operating system support or
>  	because the underlying image is not possible to memory-map,
> 	the loading of the image should be aborted with an error.

This is the reason I said it should be OS specific. The above definition
itself is so attached to OS support.

It would make sense to make it part of a generic standard when:

1. There are different loaders provided by different vendors for the same OS
2. (Hypothetically) A loader on one OS is expected to handle/load an ELF
produced by a linker from another OS.

> 0x00001000 (2^12) - SHF_SHARED
> 
> 	This section MUST be made part of a PF_SHARED segment when
> 	linked.

This again is not complete. A non-ambiguous standard should also tell is
it necessary for a gABI compliant ELF linker to mark sections that go
into shared segments, as SHF_SHARED? Similarly, is it necessary for a
gABI compliant linker to mark PT_LOAD that gets shared, as PF_SHARED?

> OPTIONALLY, new reserved section names:
> 
> 	.shrodata	- readonly data section to be mapped shared
> 	.shdata		- writable data section to be mapped shared
> 	.shbss		- zerofill section to be mapped shared

IMHO, these are so trivial that it is only worth to be done under a tool
chain specific option. These are not at all useful in general.

That said,

1. Send the proposal to Generic SYS-V ABI group. Lets see the consensus.
2. I may have to object this if the standards mandates that a gABI
compliant linker *MUST* mark PF_SHARED to mean PT_LOAD as sharable. I am
absolutely fine if marking PF_SHARED is optional -- I will not do it on
HP-UX.

--
Supra

Re: gABI extension proposal: PT_SHMMAP

[H. Peter Anvin]

On 06/07/17 17:30, Cary Coutant wrote:
>> Why is MAP_SHARED even needed for the linux vdso use-case?
>>
>> All the mappings created for the vdso are read-only mappings, right?
>> And on Linux, MAP_PRIVATE mappings already reflect changes made to the
>> underlying file, so long as the process hasn't written to the page, I
>> think?
>>
>> So, if you're intending to use this to implement the "vvar" mapping,
>> isn't the default MAP_PRIVATE already sufficient?
> 
> He mentioned that this was for the kernel-provided *data* page,
> implying to me that he wants a writable, but still sharable (i.e., not
> copy-on-write) mapping.
> 
> It seems generally useful to me. I probably wouldn't object to a new
> gABI bit, but a little more background would be helpful in deciding.
> 

It's not writable, at least not in the intended usage.  I will
experiment and see if PT_LOAD might just do the right thing.  Even so,
it might be safer to have a PF_MMAP bit indicating that this *must* be
mmapped.

That legacy Unix kernels doesn't support this feature is in my opinion a
total red herring.  If anything, this would permit these systems to
error out rather than do something that is completely unexpected.

The user space usage I was considering would amount to a shared bss
section.  This way multiple processes could have a shared memory area
with symbols.  It could either be done as an anonymous mapping (p_memsz
> p_filesz) in which case it would be shared among fork() clients, or as
a file-based mapping (in which case the file would, unfortunately, have
to be writable.)

However, if the consensus is that this is not interesting outside this
particular use case, then putting it under PF_MASKOS makes sense.

	-hpa