[LLVMdev] failure mode of invalid (debug info) metadata

[Eric Christopher]

Agreed.

-eric


On Wed, Mar 13, 2013 at 2:27 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi David,
>
>
> On 12/03/13 21:38, David Blaikie wrote:
>
>> Currently the debug info metadata handling is a bit loose - LLVM
>> accepts pretty much anything that looks roughly like the desired
>> schema & is lazily resilient to some differences (see, for example,
>> llvm::DIDescriptor::get*Field functions (lib/IR/DebugInfo.cpp:81)).
>>
>> I made some parts of debug info handling more pedantic about the
>> structure (requiring a certain number of metadata operands, checking
>> the validity of debug info contexts) & now can infinitely recurse for
>> sufficiently incorrect debug info metadata.
>>
>> So I'm wondering what LLVM's guarantees are or should be here. It
>> seems there's two possibilities:
>>
>> 1) LLVM should have well defined behavior over any metadata values
>> (anything that passes the current IR verifier, I assume - though I
>> don't know a great deal about what's covered by the verifier)
>>
>> 2) LLVM should grow metadata verification to the IR verifier & have
>> well defined behavior only over metadata that passes such verification
>> (in this case we can have UB (infinite recursion, out of bounds, etc)
>> in debug info metadata handling by verifying it all up-front)
>>
>> Are there other positions? Is there a clear precedent/reason to choose
>> one of the above choices? (I'd be inclined towards (2) but not sure if
>> this violates some important principles of LLVM)
>>
>
> I vote for 2).  The verifier already does a little bit of metadata
> verification,
> but I think it should thoroughly verify all metadata that LLVM itself uses
> (while ignoring user defined metadata).
>
> Ciao, Duncan.
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/35a75420/attachment.html>