<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 8, 2017 at 1:36 PM Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 8, 2017 at 1:32 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Fri, Sep 8, 2017 at 1:24 PM Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>I'm not sure I understand what you mean.<br><br>It seems unfortunate to me to build fixed memory limits into programs - it's nice if they scale up with bigger inputs and more memory on the machine to do more of whatever it is they do - only limited by the memory available on the machine, not some fixed limit in the program.<br><br>If this means making programs robust to allocation failure (failing gracefully rather than 'crashing') for them to be fuzzable - that seems, to me at least, an OK tradeoff.<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is subtle, but let me try again.</div><div>1. IMHO any code that tries to recover from malloc (or new!!) returning nullptr is much more complicated than adding an artificial limit as a flag (by default the flag could be arbitrarily large). <br></div></div></div></div></blockquote></span><div><br>By 'recover' I'd be OK with "exits with an error code", so not too complex, hopefully.<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But we already have this, both from asan and libFuzzer. </div><div>The problem is that 'exit' means a 'bug', which is where we started in this thread. </div><div>A proper API should not exit on malformed input (nor leak, crash, OOM, timeout, etc) -- it should return an error code to the caller. </div></div></div></div></blockquote><div><br>Then shouldn't we be plumbing through memory allocation failure as an error to the caller, if that's the argument?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I feel like plumbing through flags with bounds into every program/allocation is a bit burdensome/awkward/uncommon. Maybe other folks have other ideas/perspectives & I'm off in the weeds.<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not every allocation. </div><div>Only those allocations that take the size from un-trusted user-provided inputs. </div></div></div></div></blockquote><div><br>But it wouldn't just be those - the input might say "there are a million things" and then for each thing you go and allocate a known size block. Or other less entirely correlated - I mean most of the memory LLVM or any program allocates is dictated by its inputs, even if it's not taking bytes from the input and using it to determine the size of the allocation.<br><br>Or maybe the user input causes a just-barely-sane size, then the program goes to allocate some normal data structure it always allocates and that tips it over.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>It's also much harder to test. </div><div>2. malloc is not guaranteed to return nullptr even in cases when there is actually not enough memory. It may instead return something backed by swap and this can easily kill your machine. </div></div></div></div></blockquote></span><div><br>Sure enough - though I'm not sure adding a flag to every program is going to be a real path forward for protecting processes from user input. I'd expect to use OS level protections for memory limits, etc, there. <br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div> </div></div></div></div>
</blockquote></div></div>
</blockquote></div></div></div></blockquote></div></div>