Meta bug for the ability to taint data that comes out of IPC, moving existing IPC code over to this system, and related tooling.

The goal is to enable IPC methods to opt-in to being 'tainted', meaning their resulting Recv call will be provided Tainted<T> types instead of the original T types. The Tainted<> types will require explicit validation of the data before it can be used for comparisons or in arithmetic. They are intended to be passed down callstacks (still in Tainted<> form) to whatever location is appropriate to validate (or complete validation) of the data before finally unwrapping it into a T. We will iterate on the ergonomics of validation and unwrapping.

The purpose is to ensure that validation on data actually occurs and is not forgotten, to increase consideration of validation so it can be as strict as possible, and to make it clear from a code point of view where and what validation is performed on IPC parameters. The latter in particular will aid in code review, and can be used with static/dynamic analysis tools.

Could you please give a slightly longer description of what taint analysis is (like a paragraph or something), so that people who aren't familiar with it can understand the why and how of these bugs? I've come across it in academic work, but I'm still not entirely sure what the specifics and goals of your work are. Thanks.

(In reply to Andrew McCreight [:mccr8] from comment #1)

Could you please give a slightly longer description of what taint analysis is (like a paragraph or something), so that people who aren't familiar with it can understand the why and how of these bugs? I've come across it in academic work, but I'm still not entirely sure what the specifics and goals of your work are. Thanks.

Sorry, I meant to do that sooner after I got bug numbers for commit messages; but got sidetracked. I updated the original comment.