[PATCH] SH: Re: archs need fixing
Kaz Kojima
kkojima@rr.iij4u.or.jp
Mon Jan 10 04:58:00 GMT 2005
> For SH, I have a problem about the protection of GLRO area when
> the audit function is used. I'll report it with the another mail,
> since it looks a little generic problem.
When testing tst-audit1 for SH target, the write access to
GLRO(dl_audit) is failed in dl_main at rtld.c:1376
/* Now append the new auditing interface to the list. */
newp->ifaces.next = NULL;
if (last_audit == NULL)
last_audit = GLRO(dl_audit) = &newp->ifaces;
For SH, it looks that an early protection for GLRO area is
done in _dl_map_object_from_fd at dl-load.c:1372
if (__builtin_expect ((stack_flags &~ GL(dl_stack_flags)) & PF_X, 0))
{
/* The stack is presently not executable, but this module
requires that it be executable. We must change the
protection of the variable which contains the flags used in
the mprotect calls. */
#ifdef HAVE_Z_RELRO
if (mode & __RTLD_DLOPEN)
{
uintptr_t p = ((uintptr_t) &__stack_prot) & ~(GLRO(dl_pagesize) - 1);
size_t s = (uintptr_t) &__stack_prot - p + sizeof (int);
__mprotect ((void *) p, s, PROT_READ|PROT_WRITE);
if (__builtin_expect (__check_caller (RETURN_ADDRESS (0),
allow_ldso|allow_libc) == 0,
0))
__stack_prot |= PROT_EXEC;
__mprotect ((void *) p, s, PROT_READ);
}
else
...
The ifdef'ed part isn't executed for x86 but runs on SH before
_dl_protect_relro is applied to ld.so. These mprotect's are
executed unconditionally and GLRO is write-protected on SH.
It seems that this part adds the protection too early. The
appended patch sees whether _dl_protect_relro is applied to
ld.so already or not in shared case and takes the page boundary
into account like as _dl_protect_relro does. How does it
look like?
Regards,
kaz
--
2005-01-09 Kaz Kojima <kkojima@rr.iij4u.or.jp>
* elf/dl-load.c (_dl_map_object_from_fd): Take account
of the page boundary and whether the rtld is already
relocated or not when changing the protection of GLRO
area.
diff -uprN ORIG/libc/elf/dl-load.c LOCAL/libc/elf/dl-load.c
--- ORIG/libc/elf/dl-load.c 2005-01-07 08:25:45.000000000 +0900
+++ LOCAL/libc/elf/dl-load.c 2005-01-10 11:35:51.000000000 +0900
@@ -1362,14 +1362,25 @@ cannot allocate TLS data structures for
if (mode & __RTLD_DLOPEN)
{
uintptr_t p = ((uintptr_t) &__stack_prot) & ~(GLRO(dl_pagesize) - 1);
- size_t s = (uintptr_t) &__stack_prot - p + sizeof (int);
+ size_t s = ((uintptr_t) &__stack_prot - p + sizeof (int))
+ & ~(GLRO(dl_pagesize) - 1);
- __mprotect ((void *) p, s, PROT_READ|PROT_WRITE);
+#ifdef SHARED
+ if (s && GL(dl_rtld_map).l_relocated)
+#else
+ if (s)
+#endif
+ __mprotect ((void *) p, s, PROT_READ|PROT_WRITE);
if (__builtin_expect (__check_caller (RETURN_ADDRESS (0),
allow_ldso|allow_libc) == 0,
0))
__stack_prot |= PROT_EXEC;
- __mprotect ((void *) p, s, PROT_READ);
+#ifdef SHARED
+ if (s && GL(dl_rtld_map).l_relocated)
+#else
+ if (s)
+#endif
+ __mprotect ((void *) p, s, PROT_READ);
}
else
#endif
More information about the Libc-hacker
mailing list