You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
|
4
|
5
(3) |
6
(2) |
7
|
8
|
|
9
|
10
|
11
|
12
|
13
|
14
|
15
(1) |
|
16
(4) |
17
(1) |
18
|
19
|
20
|
21
(1) |
22
(1) |
|
23
|
24
|
25
|
26
|
27
(3) |
28
(1) |
29
|
|
30
|
31
(6) |
|
|
|
|
|
|
From: Mark W. <ma...@kl...> - 2017-07-05 19:48:38
|
On Thu, 2017-07-06 at 00:26 +0530, Siddhesh Poyarekar wrote: > On Wednesday 05 July 2017 09:12 PM, Mark Wielaard wrote: > > I am not sure I understand this part. > > What are micro-architecture specific routines? > > These are routines written specifically for vendor CPUs, such as the > thunderx version of memcpy and memmove. The HWCAP_CPUID allows for such > routines to be launched on the correct hardware, but when run under > valgrind, those routines will not get called and any potential bugs in > those routines may get masked. aha. We probably already intercept such implementations of memcpy and memmove with our own versions anyway. See the shared/vg_replace_strmem.c source in valgrind for some of the reasons for intercepting these hyper optimized string/memory functions. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2017-07-05 15:43:05
|
Hi, Adding valgrind-developers (and dropping fedora glibc). On Fri, 2017-06-23 at 17:40 +0530, Siddhesh Poyarekar wrote: > On Friday 23 June 2017 05:10 PM, Mark Wielaard wrote: > > On Fri, 2017-06-23 at 16:47 +0530, Siddhesh Poyarekar wrote: > >> On Friday 23 June 2017 04:43 PM, Florian Weimer wrote: > >>> valgrind needs to mask out all unknown/unimplemented flags. And I > >>> thought it was 1? LD_HWCAP_MASK=1 acts as a workaround, after all. > >> > >> The remaining flags shouldn't actually matter to glibc since they're > >> essentially assumed features (asimd, fp) but there may be programs out > >> there that might read them. > > > > I found the following arm HWCAP bits in the kernel: > > > > #define HWCAP_FP (1 << 0) > > #define HWCAP_ASIMD (1 << 1) > > #define HWCAP_EVTSTRM (1 << 2) > > #define HWCAP_AES (1 << 3) > > #define HWCAP_PMULL (1 << 4) > > #define HWCAP_SHA1 (1 << 5) > > #define HWCAP_SHA2 (1 << 6) > > #define HWCAP_CRC32 (1 << 7) > > #define HWCAP_ATOMICS (1 << 8) > > #define HWCAP_FPHP (1 << 9) > > #define HWCAP_ASIMDHP (1 << 10) > > #define HWCAP_CPUID (1 << 11) > > #define HWCAP_ASIMDRDM (1 << 12) > > #define HWCAP_JSCVT (1 << 13) > > #define HWCAP_FCMA (1 << 14) > > #define HWCAP_LRCPC (1 << 15) > > > > BTW the glibc linux/aarch64/bitshwcap.h only go up to HWCAP_ASIMDRDM. > > > > Is there are corresponding ARM abi document that maps those values to > > the corresponding arm64 cpu instruction sets? Valgrind supports some, > > but certainly not all. Since valgrind emulates/translates all > > instructions explicitly it makes sense to mask off anything unknown. > > Yeah I assumed that anything before CPUID was probably implemented in > valgrind already, but if that's the conservative way to go then so be it. The issue really is that I don't know what the HWCAP bits stand for. So for me the only way is the conservative way assuming that since things worked without any bits set, that is what we should default to for now. Hopefully someone knows which instruction sets the HWCAPS bits stand for and which ones are currently (fully) implemented in valgrind. Then we can more selectively enable bits. > So does this mean that if there are specific hwcaps we know are > implemented in valgrind (now or in future), that the flags should be > enabled one by one? Yes. IMHO. > For example, if valgrind disables hwcap_cpuid then > bugs in micro-architecture specific routines may get masked out since > they will never get called (unless you're using the not-merged-yet > glibc.tune.cpu tunable) and it would change program behaviour > considerably. I am not sure I understand this part. What are micro-architecture specific routines? > So once support for midr_el1 is in place, maybe > hwcap_cpuid should be brought back. Likewise for other flags. Yes. Cheers, Mark |
|
From: <sv...@va...> - 2017-07-05 09:57:58
|
Author: mjw
Date: Wed Jul 5 10:57:48 2017
New Revision: 16458
Log:
Bug 381805 arm32 needs ld.so index hardwire for new glibc security fixes
glibc added some security hardening adding (optimized) index/strchr
calls in the LD_PRELOAD path:
commit 6d0ba622891bed9d8394eef1935add53003b12e8
Author: Florian Weimer <fw...@re...>
Date: Mon Jun 19 22:31:04 2017 +0200
ld.so: Reject overly long LD_PRELOAD path elements
arm32 doesn't have an ld.so hardwire for index/strchr like other
architectures and so will always complain during early startup:
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF84: index (in /usr/lib/ld-2.25.so)
==9495==
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF88: index (in /usr/lib/ld-2.25.so)
index/strchr is doing a word load from a partially-written
stack-allocated buffer, therefore accessing uninitialized data.
This is normal for an optimized string function. The uninitialized
data does not affect the function result.
This can be suppressed by adding a index hardwire for ld.so on arm32
like on other arches. There even was already some commented out code
to do that. Enable that code.
Modified:
trunk/NEWS
trunk/coregrind/m_redir.c
trunk/coregrind/m_trampoline.S
trunk/coregrind/pub_core_trampoline.h
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Wed Jul 5 10:57:48 2017
@@ -41,6 +41,7 @@
381289 epoll_pwait can have a NULL sigmask
381274 powerpc too chatty even with --sigill-diagnostics=no
381769 Use ucontext_t instead of struct ucontext
+381805 arm32 needs ld.so index hardwire for new glibc security fixes
Release 3.13.0 (15 June 2017)
Modified: trunk/coregrind/m_redir.c
==============================================================================
--- trunk/coregrind/m_redir.c (original)
+++ trunk/coregrind/m_redir.c Wed Jul 5 10:57:48 2017
@@ -1485,6 +1485,17 @@
(Addr)&VG_(arm_linux_REDIR_FOR_strcmp),
complain_about_stripped_glibc_ldso
);
+ /* index */
+ add_hardwired_spec(
+ "ld-linux.so.3", "index",
+ (Addr)&VG_(arm_linux_REDIR_FOR_index),
+ complain_about_stripped_glibc_ldso
+ );
+ add_hardwired_spec(
+ "ld-linux-armhf.so.3", "index",
+ (Addr)&VG_(arm_linux_REDIR_FOR_index),
+ complain_about_stripped_glibc_ldso
+ );
}
# elif defined(VGP_arm64_linux)
Modified: trunk/coregrind/m_trampoline.S
==============================================================================
--- trunk/coregrind/m_trampoline.S (original)
+++ trunk/coregrind/m_trampoline.S Wed Jul 5 10:57:48 2017
@@ -625,26 +625,26 @@
bx lr
UD2_4
-//.global VG_(arm_linux_REDIR_FOR_index)
-//VG_(arm_linux_REDIR_FOR_index):
-// ldrb r3, [r0, #0] @ zero_extendqisi2
-// and r1, r1, #255
-// cmp r3, r1
-// @ lr needed for prologue
-// bne .L9
-// bx lr
-//.L12:
-// ldrb r3, [r0, #1]! @ zero_extendqisi2
-// cmp r3, r1
-// beq .L11
-//.L9:
-// cmp r3, #0
-// bne .L12
-// mov r0, #0
-// bx lr
-//.L11:
-// bx lr
-// UD2_4
+.global VG_(arm_linux_REDIR_FOR_index)
+VG_(arm_linux_REDIR_FOR_index):
+ ldrb r3, [r0, #0] @ zero_extendqisi2
+ and r1, r1, #255
+ cmp r3, r1
+ @ lr needed for prologue
+ bne .L9
+ bx lr
+.L12:
+ ldrb r3, [r0, #1]! @ zero_extendqisi2
+ cmp r3, r1
+ beq .L11
+.L9:
+ cmp r3, #0
+ bne .L12
+ mov r0, #0
+ bx lr
+.L11:
+ bx lr
+ UD2_4
.global VG_(arm_linux_REDIR_FOR_memcpy)
VG_(arm_linux_REDIR_FOR_memcpy):
Modified: trunk/coregrind/pub_core_trampoline.h
==============================================================================
--- trunk/coregrind/pub_core_trampoline.h (original)
+++ trunk/coregrind/pub_core_trampoline.h Wed Jul 5 10:57:48 2017
@@ -100,7 +100,7 @@
extern Addr VG_(arm_linux_SUBST_FOR_sigreturn);
extern Addr VG_(arm_linux_SUBST_FOR_rt_sigreturn);
extern UInt VG_(arm_linux_REDIR_FOR_strlen)( void* );
-//extern void* VG_(arm_linux_REDIR_FOR_index) ( void*, Int );
+extern void* VG_(arm_linux_REDIR_FOR_index) ( void*, Int );
extern void* VG_(arm_linux_REDIR_FOR_memcpy)( void*, void*, Int );
extern void* VG_(arm_linux_REDIR_FOR_strcmp)( void*, void* );
#endif
|