David Blaikie
2013-Mar-12 20:38 UTC
[LLVMdev] failure mode of invalid (debug info) metadata
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)
Duncan Sands
2013-Mar-13 09:27 UTC
[LLVMdev] failure mode of invalid (debug info) metadata
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.
Eric Christopher
2013-Mar-13 17:17 UTC
[LLVMdev] failure mode of invalid (debug info) metadata
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>
Possibly Parallel Threads
- [LLVMdev] failure mode of invalid (debug info) metadata
- [LLVMdev] bit code file incompatibility due to debug info changes
- [LLVMdev] Debug Info Verifier: should we create a module pass for it?
- [LLVMdev] Debug Info Verifier: should we create a module pass for it?
- [LLVMdev] Debug Info Verifier: should we create a module pass for it?