* RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END [not found] ` <CAMe9rOrFiHvUj4EeviT8UdA2b8b_FpiPofeNqRyWzNA9286ZNQ@mail.gmail.com> @ 2018-01-01 0:00 ` Nick Clifton 2018-01-01 0:00 ` Cary Coutant 0 siblings, 1 reply; 10+ messages in thread From: Nick Clifton @ 2018-01-01 0:00 UTC (permalink / raw) To: gnu-gabi; +Cc: H.J. Lu, Florian Weimer 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). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END Nick Clifton @ 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 0 siblings, 2 replies; 10+ messages in thread From: Cary Coutant @ 2018-01-01 0:00 UTC (permalink / raw) To: Nick Clifton; +Cc: gnu-gabi, H.J. Lu, Florian Weimer > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Cary Coutant @ 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Cary Coutant 1 sibling, 1 reply; 10+ messages in thread From: Florian Weimer @ 2018-01-01 0:00 UTC (permalink / raw) To: Cary Coutant, Nick Clifton; +Cc: gnu-gabi, H.J. Lu 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Florian Weimer @ 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 0 siblings, 1 reply; 10+ messages in thread From: Cary Coutant @ 2018-01-01 0:00 UTC (permalink / raw) To: Florian Weimer; +Cc: Nick Clifton, gnu-gabi, H.J. Lu >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Cary Coutant @ 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 0 siblings, 1 reply; 10+ messages in thread From: Florian Weimer @ 2018-01-01 0:00 UTC (permalink / raw) To: Cary Coutant; +Cc: Nick Clifton, gnu-gabi, H.J. Lu 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Florian Weimer @ 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 0 siblings, 1 reply; 10+ messages in thread From: Cary Coutant @ 2018-01-01 0:00 UTC (permalink / raw) To: Florian Weimer; +Cc: Nick Clifton, gnu-gabi, H.J. Lu >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Cary Coutant @ 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 0 siblings, 1 reply; 10+ messages in thread From: Florian Weimer @ 2018-01-01 0:00 UTC (permalink / raw) To: Cary Coutant; +Cc: Nick Clifton, gnu-gabi, H.J. Lu 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Florian Weimer @ 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 0 siblings, 1 reply; 10+ messages in thread From: Cary Coutant @ 2018-01-01 0:00 UTC (permalink / raw) To: Florian Weimer; +Cc: Nick Clifton, gnu-gabi, H.J. Lu >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Cary Coutant @ 2018-01-01 0:00 ` Florian Weimer 0 siblings, 0 replies; 10+ messages in thread From: Florian Weimer @ 2018-01-01 0:00 UTC (permalink / raw) To: Cary Coutant; +Cc: Nick Clifton, gnu-gabi, H.J. Lu 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer @ 2018-01-01 0:00 ` Cary Coutant 1 sibling, 0 replies; 10+ messages in thread From: Cary Coutant @ 2018-01-01 0:00 UTC (permalink / raw) To: Nick Clifton; +Cc: gnu-gabi, H.J. Lu, Florian Weimer > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-07-04 13:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87sh5hadd6.fsf@redhat.com> [not found] ` <CAMe9rOrFiHvUj4EeviT8UdA2b8b_FpiPofeNqRyWzNA9286ZNQ@mail.gmail.com> 2018-01-01 0:00 ` RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END Nick Clifton 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant 2018-01-01 0:00 ` Florian Weimer 2018-01-01 0:00 ` Cary Coutant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).