Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 2002 21:53:11 -0600
From:      "Mike Meyer" <mwm-dated-1015905191.fcfbe5@mired.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Mike Meyer <mwm-dated-1015899312.445e86@mired.org>, Peter Leftwich <Hostmaster@Video2Video.Com>, Miguel Mendez <flynn@energyhq.homeip.net>, Cliff Sarginson <csfbsd@raggedclown.net>, freebsd-security@FreeBSD.ORG, chat@FreeBSD.ORG
Subject:   Re: http://users.uk.freebsd.org/~juha/
Message-ID:  <15494.58407.33613.314390@guru.mired.org>
In-Reply-To: <3C86D7D6.C11D7E@mindspring.com>
References:  <20020306191854.C2150-100000@earl-grey.cloud9.net> <3C86C11C.8A31C8BB@mindspring.com> <15494.52528.125952.145716@guru.mired.org> <3C86D7D6.C11D7E@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> types:
> Mike Meyer wrote:
> > While Heisenberg's uncertainty doesn't apply as described to macro
> > events, the concept certainly works. If you instrument a kernel to
> > find performance problems, you've just slowed the kernel down, and
> > changed what routines get used when. And I'm sure we've all had the
> > experience of adding a print to try and catch a bug, and the bug
> > vanishes.
> This only happens if you don't know what you are doing.
> It's very easy to do instrumentation which subtracts
> itself out of the overall count, if the instrumentation
> is for profiling.  For debugging of timing sensitive
> problems, you have to use non-invasive techniques in
> order to avoid changing the timing.  It isn't rocket
> science.

Of course it's not rocket science. It's computer science. You haven't
got it right yet. To make sure you're not changing the paging behavior
of the system, you can't use any memory on the system, meaning you
have to be watching it on a hardware monitor. And even that isn't good
enough in all cases. I had bugs in horizontal microcode that the extra
timing to grab the trace information hid, because the time used to
sample the lines allowed the bus to settle before the next subword
executed, so it read the correct values when run that way, but read
random values run at full speed.

> As to the idea that the observer always changes the thing
> being observed, that's silly.  It's only true if the
> observer isn't copetent, until you get down to the quantum
> level.

I'll grant you that a sufficiently careful observer can probably get
away without changing what's being observed above the quantum level. I
wouldn't guarantee it until someone conclusively disproves the Bell
hypothesis.

If you are a careful enough hacker that you don't even leave
footprints on the instruction trace of the machine you're breaking
into, I'll grant you're probably not a cracker. I also want to know
how you did it.

> > Given that computers are so blasted cheap these days, and the
> > availability of open source software, there's a lot of learning that
> > can be done without stealing cycles from someone else.
> Actually, the use of individual equipment is one of the
> things that's wrong with todays CS classes.  If you do
> your work on your own machine at home, rather than using
> shared resources, you never learn to "play nice" with
> other software on the system that you didn't plan on.
> It's one of the reasons Windows Systems are so fragile
> these days, when programs from different vendors are loaded
> on them: the programmers responsible never had to learn
> to "play nice with the other kids".

Can't argue with that. I'd place it right behind sharing code being
considered cheating in school as a problem.

But we're talking about people breaking into computers to ostensibly
"learn things". Given that they can buy a used computer for a lot less
than a used car, if not get them for free when their parents upgrade,
why are they breaking into other people systems?

> > No, they'll just slow them donw, possibly screw up the accounting, and
> > similar things that can make peoples lifes miserably. Read the book by
> > the guy at LBL who helped track down a couple of crackers, even though
> > they mostly used a "look but don't touch" methodology on his
> > computers. His web site seems to be gone, or I'd send over there to
> > order a Kleine bottle from him as well.
> You mean Clifford Stoll's "The Cuckoo's Egg: Tracking a Spy
> Through the Maze of Computer Espionage", in which he used
> non-invasive observational teqniques that did not impact
> what he was observing?  8-).

Yes, that's the book. And what he did wasn't non-invasive, it was just
below the level of the people breaking into his system noticed.

> PS: The people he was writing about in "The Cuckoo's Egg"
> we definitely not just observers...

True. They were hopscotching to another system. But the clue that
started him on the case was simply cycles that hadn't been accounted
for. So even if they had done nothing more than look around for $.75
cents worth of cpu time (about 10 minutes back then), he would have
noticed them.

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15494.58407.33613.314390>