221–230 of 277 posts
Earlier quoted context omitted.
I don't think it is. It wouldn't make sense since memcpy is basically supposed to convert between arbitrary binary data.
From a practical point of view, yes, but I would be very surprised if the C standard had any accommodation for memcpy being a way to leak the value of a structure's padding.
Earlier quoted context omitted.
From a practical point of view, yes, but I would be very surprised if the C standard had any accommodation for memcpy being a way to leak the value of a structure's padding.
You clearly haven't understood the thread.
Earlier quoted context omitted.
I'm confused what I'm supposed to look for in that article (do you mean you were the author?) but anyway -- I feel like calling this merely a "caveat" gives the wrong impression? It seems a bit like telling people to mix bleach with vinegar and then saying "Oops, sorry, I did know that it produces chlorine! I forgot to mention that caveat." The caveat isn't just a side note for the margins, it's a critical reason why…
Technically I don't think memset forces the compiler to clear the padding and keep it clear either though. The magic of the C abstract machine.
Earlier quoted context omitted.
Why? memset followed by memcpy must return the same byte everywhere. Otherwise what would memset even mean?
I feel like accessing the bytes that correspond to padding might be implementation-defined, but I couldn't find this in the standard.
_6 When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values. 51)_
So sure, a memcpy after a memset aught to preserve all the bytes, but if they are updated through a struct which contains padding then the values in the padding bytes will be left unspecified.
Earlier quoted context omitted.
And most importantly dont expect memset to be executed at all. Most -O2 compilers happily optimize the memset away if if doesn't care about the sideeffects. Therefore there exists the "secure" memset variants, which are the insecure variants adding a simple compiler barrier, so it isn't optimized away. And there exists the very few really secure memset_s variants with a real memory barrier which guarantees memset to…
you can write your own memset that bypasses all of that. Its just 2 lines of code.
It is worth noting that many C projects go for extreme portability. That's why C is used in the first place, and sometimes C99 is too much. I still sometimes work with compilers that barely support C89. That's for the aerospace industry BTW. There are even some libc that don't accept free(NULL).
If you know the platform you are writing for is not ancient, that's fine but if you are writing portable code, you have to realize these ancient platforms are still alive.
I think ditching K&R C is fine though. I've seen some of it but never encountered a case where it was the only thing the compiler supported.
Earlier quoted context omitted.
RDMA (Infiniband) does DMA to/from network. Why we should not use RDMA?
Hmm, that concern is not just limited to RDMA; any kind of shared memory communication across a trust boundary is vulnerable to info leaks in the padding of the struct. That does seem like a real issue. Not sure what's the appropriate mitigation. Having to memset is a drag, and it's easy to forget to do it in some place or another. I'm tempted to say that you should only use packed structs for shared memory communica…
Edit: Also, lots of simulation codes I am aware of tend to send flat arrays anyway. So I'd say that your concerns are mostly theoretical in nature.
Earlier quoted context omitted.
And most importantly dont expect memset to be executed at all. Most -O2 compilers happily optimize the memset away if if doesn't care about the sideeffects. Therefore there exists the "secure" memset variants, which are the insecure variants adding a simple compiler barrier, so it isn't optimized away. And there exists the very few really secure memset_s variants with a real memory barrier which guarantees memset to…
you can write your own memset that bypasses all of that. Its just 2 lines of code.
Earlier quoted context omitted.
are you sure that the padding is not zeroed by memset? [1] says that memset_s exists because it is not optimized away if it just clears a variable that will not be used after the call (unlike memset) On the other end: people who do this for security reasons say not to trust memset_s is 'an optional feature of c11 and not really portable' [2] [1] https://en.cppreference.com/w/c/string/byte/memset [2] https://www.crypt…
I don't think memset is required to zero out any padding, because the effects of this are not observable.