Optimization-unstable code

Posted Dec 5, 2013 8:35 UTC (Thu) by jezuch (subscriber, #52988)
Parent article: Optimization-unstable code

> char *buf = ...;
> unsigned int len = ...;
>
> if (buf + len < buf) /* overflow check */
> ...

> On some architectures, according to the paper, that's no great loss as the test doesn't work. But on other architectures, it does protect against a too large value of len.

My take on this is: if you invent TRICKSY code like this, it's your damn fault if it breaks.

> I think the only answer to those lines is to advise you to not use any programs written in C.

Haha only serious ;)

to post comments

Optimization-unstable code

Posted Dec 5, 2013 12:42 UTC (Thu) by Felix.Braun (guest, #3032) [Link] (7 responses)

char *buf = ...;
unsigned int len = ...;
if (buf + len < buf) /* overflow check */

The way I see it, buf + len can only be < buf if len is sufficiently big to wrap around the address space. Wouldn't it be much more useful to check for a buffer overflow like this instead?

if (buf + len >= &len) ...

Optimization-unstable code

Posted Dec 5, 2013 13:42 UTC (Thu) by HelloWorld (guest, #56129) [Link]

That makes no sense. Why would there be any relationship between the buffer's bounds and len's address? You do have a point though: the check quoted in the LWN article is insufficient, and in fact, the check in the paper is different:

char *buf = ...;
char *buf_end = ...;
unsigned int len = ...;
if (buf + len >= buf_end)
  return;   /* len too large */
if (buf + len < buf)
  return;   /* overflow, buf+len wrapped around */
/* write to buf[0..len-1] */

Optimization-unstable code

Posted Dec 5, 2013 14:01 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

That only works if buf points to the stack (which would happen with char buf[]). If buf is malloc'd or points to a .data section, its value and len's location on the stack are pretty unrelated.

Maybe I'm missing something, but what are you supposed to do if the check fails? Complain that malloc is giving you bad pointers? If there's a bug serious enough that malloc is giving you a block that wraps around the end of the address space, I'd almost it rather crash to get away from that libc ASAP ;) . Or you're not asking for a big enough block, but that's an easy fix too.

Optimization-unstable code

Posted Dec 5, 2013 14:44 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (1 responses)

No, it doesn't work at all. The compiler can move automatic variables in the stack as it wishes. For example, with "-fstack-protector" it is a good idea for the compiler to move arrays near the top of the stack, so that overflows will overwrite the canary value and will be detected.

The compiler can also reuse memory for variables with overlapping lifetimes.

Optimization-unstable code

Posted Dec 8, 2013 14:20 UTC (Sun) by nix (subscriber, #2304) [Link]

The compiler can also reuse memory for variables with overlapping lifetimes.

I hope you meant 'non-overlapping'!

Optimization-unstable code

Posted Dec 12, 2013 11:36 UTC (Thu) by etrusco (guest, #4227) [Link] (2 responses)

Maybe you meant

if (buf + len >= (char *) len) ...

Optimization-unstable code

Posted Dec 12, 2013 12:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

That would only ever be true if buf is between NULL and address len. That's an awfully low pointer to get in userspace.

Optimization-unstable code

Posted Dec 12, 2013 14:07 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Err, nevermind. I should read things closer.