You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-30 15:01:01
|
On Sat, 30 Aug 2003, Thomas Eschenbacher wrote: > I want to verify my KDE-3 application (kwave.sf.net) with valgrind, but > as soon as the main window appears the program exits and I see a bunch > of messages like these: > > ==18449== valgrind's libpthread.so: KLUDGED call to: sem_destroy > > What is going wrong, does that mean that there is a bug in my > application or is there a problem with valgrind and/or glibc/libpthread? Valgrind's libpthread implementation is incomplete; for some functions it pretends to implement them but just does a cheap imitation (a "kludge" -- maybe we should not use this word as it's meaning doesn't seem to be widely known), in the hope that this is enough; often it is. Unfortunately, it seems that for your application it's not enough. If you are keen, you could try hacking coregrind/vg_libpthread.c to implement sem_destroy() and any other "kludged" functions to a sufficient level for things to work. N |
|
From: Nicholas N. <nj...@ca...> - 2003-08-30 14:53:26
|
On Fri, 29 Aug 2003, Michael E. Locasto wrote:
> The motivating example here is a fairly ambitious project to automatically
> patch certain known classes of software vulnerabilities like stack or
> heap-based overflows.
You should read this paper:
@InProceedings{Kir:shepherding2002,
author = {Vladimir Kiriansky and Derek Bruening and Saman Amarasinghe},
title = {Secure Execution Via Program Shepherding},
booktitle = {Proceedings of the 11th USENIX Security Symposium},
pages = {191--206},
address = {San Francisco, California, USA},
month = aug,
year = 2002,
summary = {Nice paper about preventing a broad range of security
attacks such as format-string and stack overwrite attacks.
Doesn't try to detect the attack itself, but rather its
effect; watches for control transfers to suspicious (eg.
injected) code. Does this by (a) only running code that
comes from trusted origins (eg. binary image, libraries),
(b) restricting control flow transfers and (c) using
"uncircumventable" sandboxing. Built with Dynamo/RIO, a
fast Valgrind-like program supervision meta-tool. The
sandboxing is used to avoid attacks against RIO itself.
Performance is excellent, on average about 1.1--1.2 times
slower than unprotected, on Linux and Windows.},
}
I'm not sure whether the described system is available for general use,
but it sounds a lot like what you're suggesting.
N
|
|
From: Thomas E. <Tho...@gm...> - 2003-08-30 08:01:13
|
Hi, I want to verify my KDE-3 application (kwave.sf.net) with valgrind, but as soon as the main window appears the program exits and I see a bunch of messages like these: ==18449== valgrind's libpthread.so: KLUDGED call to: sem_destroy What is going wrong, does that mean that there is a bug in my application or is there a problem with valgrind and/or glibc/libpthread? The application works fine without valgrind. my system is a SuSE-8.2 with KDE-3.1.3, Qt-3.1.2-54, glibc-2.3.2-5, gcc-3.3-23 I use valgrind-1.9.6-20030725-0 and also tried the CVS version - no difference. It also doesn't matter which skin I use, I tried memcheck, addrcheck, the cache profiler and so on, they all fail. Thomas. -- ________________________________________________________________________ Thomas Eschenbacher <Tho...@gm...> |
|
From: Steve G <lin...@ya...> - 2003-08-30 01:46:02
|
>As I understand it, our main problem with using >libsafe is twofold: its termination of the process >when an overflow is discovered, Right. This is where the libckpt stuff comes in. You would want to change that behavior and use one of the proces restoration calls when the overflow was detected. Just to make sure we are talking about the same library, you can find it here: http://www.cs.utk.edu/~plank/plank/www/libckpt.html >and libsafe only covers certain C library functions. Right. This is a limitation. Valgrind is much more flexible in this regard. However, if you really grok what libsafe is doing, and you have a modern compiler that supports typeof, you might be able to abstract what they are doing and create a generic instrumentation routine. >In addition, we're really looking for fine-grained >tracking of memory (more than the bounds checking ) Right. Libsafe only does one thing...and it does it pretty well. Valgrind is much more flexible for general memory problems. But as others pointed out, it may be hard to turn on and off at will. That's why I was focusing on something a little easier, but not as powerful as valgrind. In any event, it sounds like an interesting project. Best Regards, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |