Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Memsetting Structures

anmolsarma.in

Post reply on HN
Print view View original

171–180 of 277 posts

Re: Stop Memsetting Structures

#171

Post by tlholaday »

hermitdev wrote: post #166
hermitdev wrote: post #129

Earlier quoted context omitted.

If you're relying upon the value of padding, you're already into undefined behavior.

If you're either using via either assigning or reading the value that is stored in the padded area of a class or struct you are in undefined behavior, any version of the standard you choose. So, care to explain the downvotes?

Although I did not downvote, I suspect your comment is being downvoted because it appears to overlook the risk of data leaking to an adversary through the padding bytes.

Re: Stop Memsetting Structures

#172

Post by jcr1488 »

hermitdev wrote: post #166
hermitdev wrote: post #129

Earlier quoted context omitted.

If you're relying upon the value of padding, you're already into undefined behavior.

If you're either using via either assigning or reading the value that is stored in the padded area of a class or struct you are in undefined behavior, any version of the standard you choose. So, care to explain the downvotes?

If you pass partially uninitialized objects (including padding) between kernel space and user space, there's a chance that the (less privileged) user space code can recover information it shouldn't be able to see, regardless of what the spec says about undefined behaviour. Such information may include secrets that previously occupied the memory where a new, unrelated struct now resides. The same can also apply to passing objects between different machines.

All "undefined behaviour" means is that the spec can no longer guarantee anything about the execution of a program once a constraint is violated. It doesn't say anything about the practicality of actually doing it on any given implementation.

FWIW I didn't downvote you, but your reasoning about undefined behaviour seems overly simplistic. It should never be used to explain away security concerns.

Re: Stop Memsetting Structures

#173

Post by klingonopera »

amboar wrote: post #68
wbl wrote: post #41

Earlier quoted context omitted.

Please explain how you send a struct over the network without UB and leaking the padding.

Use a packed struct (e.g. __attribute__((packed))). You may take a performance hit due to lack of alignment, but that's the judgement call

Would this work

  struct S {char data, char pad0, char pad1, char pad2};
  int main() {S dataStruct; printf("%s", dataStruct.data); return 0;}
and give me a 4-byte struct or would the compiler optimize it all away and leave me with a 1-byte struct?

Re: Stop Memsetting Structures

#175

Post by a_t48 »

blattimwind wrote: post #155
a_t48 wrote: post #106

Earlier quoted context omitted.

That's a pretty classical file serialization trick to pack a bunch of heterogeneous data in one file. A header/manifest starting the file, with an array of names, offsets, and sizes.

Actually works somewhat well for mmap'ed access, too, by using a macro or function to "dereference" "pointers" (offsets).

Or even an OffsetPtr class with overloaded arrow and dereference operator, if you swing that way. :)

Re: Stop Memsetting Structures

#176

Post by shaklee3 »

klingonopera wrote: post #107
userbinator wrote: post #99

Earlier quoted context omitted.

I may want to redefine free(). 2) If I do, my free() does not null-check. I think redefining standard functions to do something very unexpected is very poor decision, especially when it means you now have to burden all its callsites with an extra check. But I'm quite sure that "delete" in C++ e.g. definitely needs to be null-checked (unless they changed that in some newer C++ revision No, it was never needed in C++ e…

Yes, you're right about delete. I still do it, and will still do it, though. I have my reasons. No, I wouldn't redefine free(), I'd use my own terminology, but I'd search the code for it and replace it verbatim, and seeing that it apparently is standard practice for both C++ and C to null-check their pointers before deletion, I have all the more reason to do so, because my code assumed that it didn't. Delete shouldn'…

What are your reasons?

Re: Stop Memsetting Structures

#177

Post by [deleted] »

andrewshadura wrote: post #148
bjourne wrote: post #113

Earlier quoted context omitted.

I'm joking because endless flame wars have already been spent debating this issue. But I realize not everyone has heard them yet, so let's strap on the football shoes and bring out the horse carcass one more time! There are platforms on which NULL, integer 0 and floating point 0 is not the same. Hence memsetting won't do the right thing. On modern platforms they are, but still, you don't want to get the Standard C We…

By the standard, the null pointer must be equivalent to 0.

[deleted]

Re: Stop Memsetting Structures

#178

Post by [deleted] »

unmole wrote: post #45
dataflow wrote: post #14

Earlier quoted context omitted.

Nope it doesn't: //GCC: -O0 //MSVC: /Od #include #include struct S { unsigned char x; int y; }; int f(int f) { S a; memset(&a, f, sizeof(a)); unsigned char y[2]; memcpy(&y, &a, sizeof(y)); return y[1]; } int g() { S a = { 1, 2 }; unsigned char y[2]; memcpy(&y, &a, sizeof(y)); return y[1]; } int main(int argc, char *argv[]) { f(0xDD); printf("%#x\n", g()); f(0xFF); printf("%#x\n", g()); } It definitely seems like the…

I am aware of the fact that unitilized padding can have nasty side effects: https://lwn.net/Articles/417989/ But yeah, I should have mentioned the caveats too. I will update the post once I'm back at my computer.

[deleted]

Re: Stop Memsetting Structures

#179

Post by saagarjha »

mehrdadn wrote: post #158
Dylan16807 wrote: post #156

Earlier quoted context omitted.

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.

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.

Re: Stop Memsetting Structures

#180

Post by saagarjha »

CJefferson wrote: post #24
Someone wrote: post #12

Earlier quoted context omitted.

Sending structures that include padding or that you don’t know the exact layout of over the network is another thing you shouldn’t do, period. Code doing that may break with a compiler change or a compilation flag change on one end of the connection, even if you can guarantee both ends use the same CPU.

Changing compiler or flags won't change structs, unless you do something crazy. If it did, you couldn't link C libraries compiled with one compiler with programs compiled on another. You can't be sure you can send such structures to different OSes or CPUs however.

> If it did, you couldn't link C libraries compiled with one compiler with programs compiled on another.

You cannot do this unless the compilers have the same ABI, which is not part of the standard.

Post reply on HN