Signed-off-by: Yann Sionneau <ysionneau(a)kalray.eu>
---
libpthread/nptl/sysdeps/riscv64/libc-tls.c | 2 +-
libpthread/nptl/sysdeps/riscv64/tls.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libpthread/nptl/sysdeps/riscv64/libc-tls.c b/libpthread/nptl/sysdeps/riscv64/libc-tls.c
index 500de1d..67c3a60 100644
--- a/libpthread/nptl/sysdeps/riscv64/libc-tls.c
+++ b/libpthread/nptl/sysdeps/riscv64/libc-tls.c
@@ -17,7 +17,7 @@
#include <sysdeps/generic/libc-tls.c>
#include <dl-tls.h>
-/* On OpenRISC, linker optimizations are not required, so __tls_get_addr
+/* On RISC-V 64, linker optimizations are not required, so __tls_get_addr
can be called even in statically linked binaries. In this case module
must be always 1 and PT_TLS segment exist in the binary, otherwise it
would not link. */
diff --git a/libpthread/nptl/sysdeps/riscv64/tls.h b/libpthread/nptl/sysdeps/riscv64/tls.h
index 33a3781..8295c71 100644
--- a/libpthread/nptl/sysdeps/riscv64/tls.h
+++ b/libpthread/nptl/sysdeps/riscv64/tls.h
@@ -1,4 +1,4 @@
-/* Definition for thread-local data handling. NPTL/OR1K version.
+/* Definition for thread-local data handling. NPTL/RISCV64 version.
Copyright (C) 2005, 2007, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
@@ -70,7 +70,7 @@ register tcbhead_t *__thread_self __asm__("tp");
* ------------------------------------
* | PRE | TCB | TLS MEMORY .. |
* ------------------------------------
- * ^ r10 / TP
+ * ^ x4 / TP
*
* PRE is the struct pthread described below
* TCB is tcbhead_t
--
1.8.3.1
Hello,
About
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=858ffad2170762…
I'm not sure why exactly sizeof(int)*3 in the following line:
char buf[sizeof "/proc/self/fd/" + sizeof (int) * 3];
IIUC, this is supposed to give room for the ascii decimal representation
of the file descriptor number.
Maybe we could read the max file descriptor number configured in the
kernel from "/proc/sys/fs/file-max" (or "/proc/sys/file-max" for old
systems?).
So:
1/ fopen("/proc/sys/fs/file-max", "r");
2/ fscanf(fp, "%d", &fdmax);
3/ fdmax_length = log10(fdmax);
Then use fdmax_length
Or, much simpler: take for granted that fd is always an int, and thus
max 32 bits, and hard code that max "string length" of a file descriptor
is 10 chars.
But in any case maybe add a comment on top of the line to explain the
"magic number".
Cheers!
--
Yann
Hi,
This diff fixes a typo in the PTRACE_EVENT_SECCOMP event code.
The typo itself was introduced in 2012 when syncing with glibc header
files and was itself fixed in 2013 in the glibc headers.
diff --git a/libc/sysdeps/linux/common/sys/ptrace.h b/libc/sysdeps/linux/common/sys/ptrace.h
index 6b3c7b574..ebafe4e27 100644
--- a/libc/sysdeps/linux/common/sys/ptrace.h
+++ b/libc/sysdeps/linux/common/sys/ptrace.h
@@ -171,7 +171,7 @@ enum __ptrace_eventcodes
PTRACE_EVENT_EXEC = 4,
PTRACE_EVENT_VFORK_DONE = 5,
PTRACE_EVENT_EXIT = 6,
- PTRAVE_EVENT_SECCOMP = 7
+ PTRACE_EVENT_SECCOMP = 7
};
/* Perform process tracing functions. REQUEST is one of the values
.joris
Hi,
The getenv() library call can trap under certain conditions. It compares the passed in environment variable name (var) with the name=variables (*ep) in the environment area and returns a pointer to the value in the environment if it exists. To accomplish this, it does a memcmp() using the length of the passed in name (len) for each environment variable (*ep) against the passed in name (var). So memcmp will attempt to scan both strings for len bytes. However, if for some reason, len is equal to or greater than 16 and longer than the length of the *ep in the environment and the *ep resides near the end of a page boundary while the next page is not present or mapped, the memcmp could trap with a sigsegv error while continuing the scan with the optimization read-ahead. However, if strncmp is used instead, there is no problem since both source and destination scanning will stop when either reaches a terminating NULL
Test case: We are using gcc 4.8.5 and uclibc 1.0.31. With a small environment area, attempt to do a getenv() using a variable name such as "1234567890123456". Example: file run.c contains:
#include <stdlib.h>
#include <stdio.h>
int main()
{
char *n;
n = getenv("1234567890123456");
printf("Return val: \"%s\"\n", n);
return 0;
}
Then
<sh> cc run.c -o run
<sh> env -i 123=123 ./run.
Segmentation fault
Proposed fix:
--- uclibc/libc/stdlib/getenv.c 2019-11-13 17:22:26.260187664 -0500
+++ uclibc/libc/stdlib/getenv.c 2019-11-13 17:22:39.376111771 -0500
@@ -20,7 +20,7 @@
return NULL;
len = strlen(var);
while(*ep) {
- if (memcmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
+ if (strncmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
return *ep + len + 1;
}
ep++;
Then
<sh> env -i 123=123 ./run.
<sh>
Can we get this patch upstream?
Thanks,
----
John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System<http://www.baesystems.com/en-us/product/stop> Software Development
T 703-563-8115 | F 703-668-4359 | john.ata(a)baesystems.com<mailto:john.ata@baesystems.com>
http://www.baesystems.com/csp
[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330]<http://www.twitter.com/baesystemsinc>[cid:image004.png@01D138BC.8E54E330]<http://www.youtube.com/baesystemsinc>[cid:image006.png@01D138BC.8E54E330]<http://www.flickr.com/photos/baesystemsinc/>
