Re: RFC: ABI support for special memory area

[Carlos O'Donell <carlos@redhat.com>]

On 02/23/2017 09:59 PM, H.J. Lu wrote:
>> Why does it run _after_ all shared objects and the executable file are loaded?
> 
> Since __gnu_mbind_setup may call any external functions, it can only
> be done after everything is loaded and relocated.

Who defines this function?

Where is it implemented?

What does a typical implementation look like for MCDRAM use?

>> Why not let the dynamic loader choose when it needs to setup the memory?
> 
> 1. We want to be able to add support for new type memory by just
> updating the run-time library of __gnu_mbind_setup, instead of
> updating glibc.

Which library defines it?

Can two libraries define it? Does the dynamic loader run every DSO's
version of __gnu_mbind_setup?

> 2. Since __gnu_mbind_setup may depend on other libraries, we
> don't want a simple executable requires libfoo and libbar, in addition
> to glibc, nor make libfoo and libbar part of glibc.

Why can't this be run in a constructor? Is that too late?

This seems like a specialized form of constructor that is guaranteed
to run before all other constructors?

>>> int
>>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length)
>>> {
>>>   return 0;
>>> }
>>>
>>> which can be overridden by a different implementation at link-time.
>>
>> What if you _can't_ bind at ADDR?
> 
> It happens on systems without special memory.  __gnu_mbind_setup
> returns a positive value and ld.so keeps going.

Isn't this a violation of what the application binary requested?

This is a soft-failure that that application doesn't know about.

Might this become a security issue if the application expected the
specific memory type?

>> What if the binding would work if ADD was any value?
>>
> 
> GNU_MBIND isn't a LOAD segment,  similar to GNU_RELRO:
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000000 0x00000000 0x00000000 0x54624 0x54624 R E 0x1000
>   LOAD           0x054e9c 0x00055e9c 0x00055e9c 0x001b0 0x001b8 RW  0x1000
>   DYNAMIC        0x054eac 0x00055eac 0x00055eac 0x00110 0x00110 RW  0x4
>   NOTE           0x000114 0x00000114 0x00000114 0x00044 0x00044 R   0x4
>   GNU_EH_FRAME   0x048eb8 0x00048eb8 0x00048eb8 0x00ff4 0x00ff4 R   0x4
>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
>   GNU_RELRO      0x054e9c 0x00055e9c 0x00055e9c 0x00164 0x00164 R   0x1
> 
> ADDR contains the start of a memory region within the LOAD segment.

What are the constraints of GNU_MBIND then?

Is it required that it covers only the SHF_GNU_MBIND marked sections which
are part of a PT_LOAD segment?

-- 
Cheers,
Carlos.