RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Nick Clifton]

Hi Guys,

  I would like to propose the addition of a new dynamic tag to the gABI:

#define DT_GNU_GOT_PLT_END 0x60000100

  This tag would have two effects:

    * Its presence in the dynamic section would indicate that the 
      .got.plt section is on its own in a page aligned region of
      memory.

  IE no other sections overlap the pages used by the .got.plt, and
  the section has been padded so that it ends on a page alignment
  boundary.

    * The value of the tag would give the address of the first
      byte beyond the end of the .got.plt.

  This means that the size of the .got.plt can be computed by 
  subtracting the value of the DT_PLTGOT tag from the DT_GNU_GOT_PLT_END
  tag.

  The practical use of this tag is to allow the dynamic linker to
  isolate the .got.plt section by changing the permissions on the pages
  that it occupies.

Cheers
  Nick

PS.  I did see that there are already two tags called DT_PLTPAD and
  DT_PLTPADSZ, but apparently these are used by Solaris for implementing
  text relocations with 30-bit displacements (R_SPARC_WDISP30).

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Cary Coutant]

>   I would like to propose the addition of a new dynamic tag to the gABI:
>
> #define DT_GNU_GOT_PLT_END 0x60000100
>
>   This tag would have two effects:
>
>     * Its presence in the dynamic section would indicate that the
>       .got.plt section is on its own in a page aligned region of
>       memory.
>
>   IE no other sections overlap the pages used by the .got.plt, and
>   the section has been padded so that it ends on a page alignment
>   boundary.
>
>     * The value of the tag would give the address of the first
>       byte beyond the end of the .got.plt.
>
>   This means that the size of the .got.plt can be computed by
>   subtracting the value of the DT_PLTGOT tag from the DT_GNU_GOT_PLT_END
>   tag.
>
>   The practical use of this tag is to allow the dynamic linker to
>   isolate the .got.plt section by changing the permissions on the pages
>   that it occupies.

First: If you're proposing this for the gABI, you should drop the
"GNU_" from the name. Or are you really proposing this just for the
Gnu ABI?

Second: Spelling. If the other related tag is DT_PLTGOT, let's spell
this one similarly -- DT_PLTGOT_END.

Third: Adding an "end of section" address is unusual for the dynamic
table. You've been quite explicit to say "the address of the first
byte beyond the end of the .got.plt", but it's actually much less
error prone to give the size of the section rather than its ending
address. You could have DT_PLTGOTSZ, which would parallel other
dynamic tags.

Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide
that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT :
DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8),
then add the three reserved entries. There's a one-to-one relationship
between the PLT and the PLTGOT, and every PLTGOT entry must have a
relocation.

Fifth: If all you're trying to say is "the .got.plt section is
isolated on its own pages", couldn't you just use one of the DT_FLAGS
or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this
condition is a bit risky -- what if someone decides they'd like to
record the size of .got.plt even when it's not isolated on its own
pages?

-cary

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Florian Weimer]

On 06/22/2018 11:28 PM, Cary Coutant wrote:
> Third: Adding an "end of section" address is unusual for the dynamic
> table. You've been quite explicit to say "the address of the first
> byte beyond the end of the .got.plt", but it's actually much less
> error prone to give the size of the section rather than its ending
> address. You could have DT_PLTGOTSZ, which would parallel other
> dynamic tags.

With the size, it's also possible to express that the section ends at 
the top of the address space.  (Although this doesn't really matter in 
practice.)

> Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide
> that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT :
> DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8),
> then add the three reserved entries. There's a one-to-one relationship
> between the PLT and the PLTGOT, and every PLTGOT entry must have a
> relocation.

The PLT count wouldn't include the padding at the end of the section, so 
it doesn't confer the required information.

> Fifth: If all you're trying to say is "the .got.plt section is
> isolated on its own pages", couldn't you just use one of the DT_FLAGS
> or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this
> condition is a bit risky -- what if someone decides they'd like to
> record the size of .got.plt even when it's not isolated on its own
> pages?

Well, isn't this a problem no matter what we specify?  That someone 
might provide incorrect information?  If we use a number, at least 
disagreement about the run-time page size isn't a source of potential 
issues.

Thanks,
Florian

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Cary Coutant]

>> Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide
>> that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT :
>> DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8),
>> then add the three reserved entries. There's a one-to-one relationship
>> between the PLT and the PLTGOT, and every PLTGOT entry must have a
>> relocation.
>
> The PLT count wouldn't include the padding at the end of the section, so it
> doesn't confer the required information.

That plus a simple flag does, though.

>> Fifth: If all you're trying to say is "the .got.plt section is
>> isolated on its own pages", couldn't you just use one of the DT_FLAGS
>> or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this
>> condition is a bit risky -- what if someone decides they'd like to
>> record the size of .got.plt even when it's not isolated on its own
>> pages?
>
> Well, isn't this a problem no matter what we specify?  That someone might
> provide incorrect information?  If we use a number, at least disagreement
> about the run-time page size isn't a source of potential issues.

My point is that a DT_PLTGOTSZ entry could be useful on its own to
indicate the size of the PLT GOT. If you make it *also* imply that the
PLT GOT is isolated on its own pages, you're pre-empting that meaning
of the tag (which, given the name, would be the most obvious meaning).
Although I guess DT_PLTGOTSZ could be taken to mean: "Here's the size
of the PLT GOT, possibly including any trailing padding intended to
pad it out to a page boundary. If it works out that the beginning and
end of the segment are both at page boundaries, then it's possible to
make it relro." In other words, the tag's presence doesn't -- on its
own -- imply that the PLT GOT has been placed on separate pages, but
provides the information to determine whether it has.

That leads me to another question: How would this be different from -z
relro -z now? It looks to me like a binary with such a PLT GOT would
be nothing more than a -z relro -z now binary where nothing but the
.got.plt section ends up as RELRO. So why not just use the
PT_GNU_RELRO program header for this?

-cary

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Florian Weimer]

On 06/24/2018 08:04 PM, Cary Coutant wrote:

> My point is that a DT_PLTGOTSZ entry could be useful on its own to
> indicate the size of the PLT GOT. If you make it *also* imply that the
> PLT GOT is isolated on its own pages, you're pre-empting that meaning
> of the tag (which, given the name, would be the most obvious meaning).
> Although I guess DT_PLTGOTSZ could be taken to mean: "Here's the size
> of the PLT GOT, possibly including any trailing padding intended to
> pad it out to a page boundary. If it works out that the beginning and
> end of the segment are both at page boundaries, then it's possible to
> make it relro." In other words, the tag's presence doesn't -- on its
> own -- imply that the PLT GOT has been placed on separate pages, but
> provides the information to determine whether it has.

That's right, the dynamic linker would still have to apply checks to 
make sure that everything is laid out as expected because the run-time 
page size could be larger than the link-time page size.  That shouldn't 
happen, but you can't really now.

> That leads me to another question: How would this be different from -z
> relro -z now? It looks to me like a binary with such a PLT GOT would
> be nothing more than a -z relro -z now binary where nothing but the
> .got.plt section ends up as RELRO. So why not just use the
> PT_GNU_RELRO program header for this?

It doesn't disable lazy binding, so there is no visible semantic 
difference in symbol binding.

With page isolation, we can use pkey_mprotect to assign a protection key 
to the .got.plt and only make it readable while _dl_fixup is running. 
That would provide most of the security benefits of BIND_NOW+RELRO, 
without disabling lazy binding.

Thanks,
Florian

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Cary Coutant]

>> That leads me to another question: How would this be different from -z
>> relro -z now? It looks to me like a binary with such a PLT GOT would
>> be nothing more than a -z relro -z now binary where nothing but the
>> .got.plt section ends up as RELRO. So why not just use the
>> PT_GNU_RELRO program header for this?
>
> It doesn't disable lazy binding, so there is no visible semantic difference
> in symbol binding.
>
> With page isolation, we can use pkey_mprotect to assign a protection key to
> the .got.plt and only make it readable while _dl_fixup is running. That
> would provide most of the security benefits of BIND_NOW+RELRO, without
> disabling lazy binding.

OK, so it's a variant of RELRO. I'd prefer using a new program header
type, PT_GNU_PLTGOT, then.

-cary

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Florian Weimer]

On 06/24/2018 11:05 PM, Cary Coutant wrote:
>>> That leads me to another question: How would this be different from -z
>>> relro -z now? It looks to me like a binary with such a PLT GOT would
>>> be nothing more than a -z relro -z now binary where nothing but the
>>> .got.plt section ends up as RELRO. So why not just use the
>>> PT_GNU_RELRO program header for this?
>>
>> It doesn't disable lazy binding, so there is no visible semantic difference
>> in symbol binding.
>>
>> With page isolation, we can use pkey_mprotect to assign a protection key to
>> the .got.plt and only make it readable while _dl_fixup is running. That
>> would provide most of the security benefits of BIND_NOW+RELRO, without
>> disabling lazy binding.
> 
> OK, so it's a variant of RELRO. I'd prefer using a new program header
> type, PT_GNU_PLTGOT, then.

Wouldn't this cause the binaries not to run with an older loader?

Thanks,
Florian

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Cary Coutant]

>> OK, so it's a variant of RELRO. I'd prefer using a new program header
>> type, PT_GNU_PLTGOT, then.
>
> Wouldn't this cause the binaries not to run with an older loader?

Maybe, but new dynamic table entries could do that, too. Does anyone
remember what the experience was when PT_GNU_RELRO was added?

-cary

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Florian Weimer]

On 06/26/2018 02:42 AM, Cary Coutant wrote:
>>> OK, so it's a variant of RELRO. I'd prefer using a new program header
>>> type, PT_GNU_PLTGOT, then.
>>
>> Wouldn't this cause the binaries not to run with an older loader?
> 
> Maybe, but new dynamic table entries could do that, too.

I think ld.so ignores unknown DT_* entries.

> Does anyone remember what the experience was when PT_GNU_RELRO was added?

There were binutils crashes.

But I was mistaken: ld.so ignores unknown PT_* entries, too.

I still think a DT_* entry is conceptually the right choice here.  It's 
really specific to the PLT.  It's not something that I expect can be 
used to change other mappings successfully.

Thanks,
Florian

Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END

[Cary Coutant]

> First: If you're proposing this for the gABI, you should drop the
> "GNU_" from the name. Or are you really proposing this just for the
> Gnu ABI?

Sorry, my mistake -- I filter generic-abi and gnu-gabi mail into the
same folder, and didn't notice that you sent this to the gnu-gabi list
only.

-cary