logo       

Re: RFC: linux backdoor prevention: msg#00067

Subject: Re: RFC: linux backdoor prevention
Hi Steve,

> > Readability is in the eye of the beholder.  For example, often this kind
> > of construction:
> >
> >     if ( (A = result_of_some_call) < 0)
> >             barf;
> >
> > amounts to:
> >
> > try {
> >     A = result_of_some_call;
> > } catch (badness: A < 0) { barf; }
> >
> > (sorry, I forget what the C++/java or
> > whatever syntax is - I hope you get
> > the idea).
>
> I don't get the idea. The Linux kernel is written in C - not C++ or Java
> so:
>
>       if (((a = foo()) < 0)
>               barf;
> and
>
>       a = foo()
>       if (a < 0)
>               barf;
>
> amount to exactly the same thing. In fact in C++ and Java it is still the
> same...

They are logically equivalent, but readability is not about logical equivalance.
I was just trying to point out why some people might find the first form more
readable than the second form, due to psychological factors: the first form
expresses a form of control flow (exception block wrapping a function call)
that is widely used.

> Where the side effect can be useful is in a while loop. For instance, a
> common C idiom is :
>
>       while ((c = getchar()) != EOF)
>
> This "parses" fine for my mind but the side effects in an if expression are
> evil.

This while loop can easily be rewritten to avoid the side effect.  Doesn't
this example just go to prove that "readability is in the eye of the beholder"?

In any case, the original post, if I understood it right, was suggesting that
kernel backdoors (malicious attacks) could be made harder by enforcing a
coding style that forbids side effects.  I doubt this could be done in the linux
kernel world, think "herding cats".  This quickly bifurcated into a readability
discussion.  How about getting back to the main point: how to make malicious
attacks harder?  I suggested making uid an opaque type that can only be
manipulated via function calls.  Any other suggestions?

All the best,

Duncan.


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/


<Prev in Thread] Current Thread [Next in Thread>