talloc issues

Sam Liddicott sam at liddicott.com
Tue Jul 28 05:51:04 MDT 2009


* tridge wrote, On 28/07/09 12:09:
> Hi Sam,
> 
>  > However it is only reasoning that can certify a use, so it can't be done
>  > by machine.
> 
> This is where we fundamentally disagree. Any change that requires
> 'reasoning' to prove it is correct is fundamentally flawed with such a
> large code base. That is why I took an approach that did it completely
> by machine and that guarantees to produce a clear warning for any case
> where semantics have changed.

But only when the code is exercised in particular circumstances.
We can never be sure that this covers all cases in a finite amount of
time, or that we get the notices in all the failures. It's not
definitely reliable.

Your approach was successful only in that it completed, but I don't find
the results more attractive than what they replace.

The large code base is a red herring, it just takes more time.

> Until you propose a method of accurately auditing the entire code base
> in a way that is definately reliable then I am strongly opposed to
> considering your proposed changes. I don't want to be chasing security
> holes for years to come.

Either you want me to provide a way of auditing the code that we both
think doesn't exist... or we don't agree on what definitely reliable means.

Because we don't rigorously declare functions that take ownership, we
don't have the information we need to audit the code automatically.

We also need to use human reasoning to work out what the buggy code
should have been.

If we parsed the C into XML I might be able produce some XSLT that
proved that the corrected C was correct... but you might not be able to
know that the XSLT does prove this. We would also have to find a
notation to declare when a function took ownership. Possible with a
"owned" keyword that was #defined to nothing.

..
>  > also indirectly by calling talloc_steal or talloc_free and then watching
>  > for a dangling pointer later (that's how I found it).
> 
> nope, that is why talloc_steal now fails when a pointer has a
> reference. 

OK, change that to: "also indirectly calling talloc_steal and watching
it fail"

>  > That's fine as a position as long as we know it wasn't the specialness
>  > that was the original problem, just inconsistent specialness. We don't
>  > need to be afraid of specialness.
> 
> I do thing treating different parents in different ways was the root
> cause of the problem. When I made talloc allow multiple parents for a
> pointer in the first place I should have stopped the asymmetry at that
> point.

Well, I disagree. I think that doing it wrongly was the root cause,
however it depends on what you were trying to do, so I defer to you on this.

I only say that I prefer the first parent to be special in the way I
said. I don't see any other way talloc_free could behave predictably,
with references; and doing so is highly desirable.

however... we understand each-other on this point...

Sam


More information about the samba-technical mailing list