Bodo Moeller <[EMAIL PROTECTED]> writes:
>On Sun, Dec 09, 2007 at 07:16:22PM +1300, Peter Gutmann wrote:
>> There was a discussion on this list a year or two back about problems in
>> using
>> memset() to zeroise in-memory data, specifically the fact that optimising
>> compilers would remove a mem
On Sun, Dec 09, 2007 at 07:16:22PM +1300, Peter Gutmann wrote:
> There was a discussion on this list a year or two back about problems in using
> memset() to zeroise in-memory data, specifically the fact that optimising
> compilers would remove a memset() on (apparently) dead data in the belief th
On Thu, 13 Dec 2007 21:11, [EMAIL PROTECTED] said:
> volatile char buf[SIZE];
> /* ... do stuff with buf ... */
> memset(buf, 0, sizeof(buf));
This has the little disadvantage that you need to check the attributes
of BUF first and that you can't immediately see what the memset i
| I've been through the code. As far as I can see, there's nothing in
| expand_builtin_memset_args that treats any value differently, so there
| can't be anything special about memset(x, 0, y). Also as far as I can
| tell, gcc doesn't optimise out calls to memset, not even thoroughly
| dead ones.
Jack:
Thank you for pointing this. I must admit you point to an inescapable
counter-example for my analysis.
Maybe global optimization was not a significant factor in the 1980's
when the C standard language was established -- it does refer to
external linkage and "genuine function".
In th
I've been through the code. As far as I can see, there's nothing in
expand_builtin_memset_args that treats any value differently, so there can't be
anything special about memset(x, 0, y). Also as far as I can tell, gcc doesn't
optimise out calls to memset, not even thoroughly dead ones: for e
On Tue, 11 Dec 2007, Leichter, Jerry wrote:
> You can almost, but not quite, get the desired effect for memory zero-
> ization with "volatile".
I thought that this was guaranteed to work:
volatile char buf[SIZE];
/* ... do stuff with buf ... */
memset(buf, 0, sizeof(buf));
On Wed, Dec 12, 2007 at 05:27:38PM -0500, Thierry Moreau wrote:
> As a consequence of alleged consensus above, my understanding of the C
> standard would prevail and (memset)(?,0,?) would refer to an external
> linkage function, which would guarantee (to the sterngth of the above
> consensus) re
Leichter, Jerry wrote:
On Wed, 12 Dec 2007, Thierry Moreau wrote:
| Date: Wed, 12 Dec 2007 16:24:43 -0500
| From: Thierry Moreau <[EMAIL PROTECTED]>
| To: "Leichter, Jerry" <[EMAIL PROTECTED]>
| Cc: Peter Gutmann <[EMAIL PROTECTED]>, cryptography@metzdowd.c
On Wed, 12 Dec 2007, Thierry Moreau wrote:
| Date: Wed, 12 Dec 2007 16:24:43 -0500
| From: Thierry Moreau <[EMAIL PROTECTED]>
| To: "Leichter, Jerry" <[EMAIL PROTECTED]>
| Cc: Peter Gutmann <[EMAIL PROTECTED]>, cryptography@metzdowd.com
| Subject: Re: M
/ testf.c /
#include
#include
typedef void *(*fpt_t)(void *, int, size_t);
void f(fpt_t arg)
{
if (memset==arg)
printf("Hello world!\n");
}
/ test.c /
#include
#include
typedef void *(*fpt_t)(void *, int, size_t);
ext
| > If the function is defined as I suggested - as a static or inline -
| > you can, indeed, takes its address. (In the case of an inline, this
| > forces the compiler to materialize a copy somewhere that it might
| > not otherwise have produced, but not to actually *use* that copy,
| > except whe
Leichter, Jerry wrote:
If the function is defined as I suggested - as a static or inline - you
can, indeed, takes its address. (In the case of an inline, this forces
the compiler to materialize a copy somewhere that it might not otherwise
have produced, but not to actually *use* that copy, ex
| > However, that doesn't say anything about whether f is actually
| > invoked at run time. That comes under the "acts as if" rule: If
| > the compiler can prove that the state of the C (notional) virtual
| > machine is the same whether f is actually invoked or not, it can
| > elide the call. No
| > Then the compiler can look at the implementation and "prove" that a
| > memset() to a dead variable can be elided
|
| One alternative is to create zero-ing functions that wrap memset()
| calls with extra instructions that examine some of the memory, log a
| message and exit the application
Leichter, Jerry wrote:
| > There was a discussion on this list a year or two back about
| > problems in using memset() to zeroise in-memory data, specifically
| > the fact that optimising compilers would remove a memset() on
| > (apparently) dead data in the belief that it wasn't serving any
|
| > There was a discussion on this list a year or two back about
| > problems in using memset() to zeroise in-memory data, specifically
| > the fact that optimising compilers would remove a memset() on
| > (apparently) dead data in the belief that it wasn't serving any
| > purpose.
|
| Then, s/mem
On 09 December 2007 06:16, Peter Gutmann wrote:
> Reading through "Secure Programming with Static Analysis", I noticed an
> observation in the text that newer versions of gcc such as 3.4.4 and 4.1.2
> treat the pattern:
>
> "memset(?, 0, ?)"
>
> differently from any other memset in that it's n
* Thierry Moreau:
> Peter Gutmann wrote:
>
>> There was a discussion on this list a year or two back about problems in
>> using
>> memset() to zeroise in-memory data, specifically the fact that optimising
>> compilers would remove a memset() on (apparently) dead data in the belief
>> that
>> it
Peter Gutmann wrote:
There was a discussion on this list a year or two back about problems in using
memset() to zeroise in-memory data, specifically the fact that optimising
compilers would remove a memset() on (apparently) dead data in the belief that
it wasn't serving any purpose.
Then, s
20 matches
Mail list logo
