<p dir="ltr">.<br>
><br>
><br>
> That boundary is usually user input. We assume that the program's memory hasn't been compromised, but anything the user puts in should be treated with suspicion. Would you use a browser that didn't check for buffer overruns?<br>
><br>
> Part of the problem is that we assume the linker is being used in a context where the input can be trusted. A lot of the time that's true, but assuming it limits the contexts in which LLD could be used. For example, you couldn't use LLD as the linker in a build-farm if it crashed on malformed input - what's to stop someone uploading a malformed ELF file and tricking the linker into sniffing other projects being built on the same server? <br>
></p>
<p dir="ltr">You cannot possibly use llvm or lld in an adversarial situation. Cherry picking a few bugs to fix will not change that.</p>
<p dir="ltr">So my position is not that I don't want to trade run time performance for safety. My points are</p>
<p dir="ltr">* I don't want to trade my time implementing stuff users will see (linker script, debug index, speed) for things users will not.</p>
<p dir="ltr">* I don't want to pretend that cherry picking a few bound checks will make lld safe on untrusted input.</p>
<p dir="ltr">Cheers,<br>
Rafael<br>
</p>