Muli Ben-Yehuda's journal

I finally did it. I bought the three
volume boxed edition of D. E. Knuth‘s
epic masterpiece, “The Art
of Computer Programming”. Since I already have a copy of
the third volume, “Sorting and Searching”, I’ll be happy to
trade it for a book of equal stature, or possibly sell it. Let
me know at mulix (at) mulix.org if you’re interested…

Dan Aloni, of coLinux fame, will be
visiting me at HRL on
Sunday and giving a talk on coLinux. I look forward to meeting
Dan again and learning more about coLinux.

As you may recall, gentle reader, I have been somewhat
unsatisfied with my job situation lately. Specifically, the lack
of anything resembling kernel hacking in the embedded Linux
project I was working on. Well, as of today, I split my time
between the previously mentioned embedded Linux project, and a
new, cool, exteremely interesting, innovative and challenging
project, that has lots of kernel love. I am truly excited about
this. As a matter of fact, /me does the happy happy joy joy
dance. I also have the chance to work directly once again with
my good pal Oleg
Goldshmidt, which makes me doubly happy.

I commited a small patch to
syscalltrack today which users have been asking for, which
allows you to see a
timestamp for each rule. Amongst other things, it gives one
a pretty accurate indication of how a given syscall takes,
assuming a non-preemptive kernel and adding in the syscalltrack
overhead.

A couple of interesting links that landed my way: IRC Images, shows images that
have been /topic on IRC lately (content about as low-brow as one
would expect from IRC) (via jwz), and Movitz: A Common
Lisp OS development platform (via xach).

Working on an embedded Linux system is making me treat
everything I think I know with suspicion. It makes me
re-validate old assumptions. Memory and storage footprints of
common system utilities, behavior under heavy load, the cost of the various
kind of context switches, kernel behavior under adverse
conditions, debuggability, self stabilization, etc. There are
many areas for improvement.

Yesterday evening Oron
Peled gave a Haifux
talk on Advanced
Autoconf. The lecture was great, and we also had a special
guest from Italy at the club meeting, Marco Bodrato.

A few weeks ago, Marco emailed me after he found my GPG key on
biglumber.com. biglumber.com is a website for coordinating
key signings, and since Marco was planning to visit Israel, he
wanted to see if we could meet and sign each other’s keys. We
exchanged a few emails, and then Orna and I invited Marco to the
weekly Haifux meeting, to be followed by an impromptu key
signing party and one of the world famous Haifux dinners.

Thus, after Oron’s lecture we went out to Spargo and had a
delicious dinner. There were about ten people in attendance,
including a few new faces, and the talk ranged from the slightly
to the incredibly geeky. As usual, fun was had all around, and
the wine didn’t hurt, either. After dinner I drove Marco to
Kibbutz Lohamei Hagetaot, and then drove home. Retired to
bed at 3 AM to continue reading about the Common
Lisp Object System.

Today I barely dragged myself out of bed at 10 AM and went to
work. There were two talks scheduled for today, the first by
Yehuda Lindel from IBM Watson on
The Security of Protocols in Modern Network Settings which
was interesting but too theretical for my not-quite-awake-yet
state at the time, and the other by Nadav Har’El on
Web Automation with libwww-perl, which was excellent.

Creative Thinking – A Tale of Seven Hats

Yesterday at work we had a “creative thinking” workshop. It wasn’t
nearly as bad enough as I expected it to be, and I actually
enjoyed bits and parts of it. We learned techniques for
facilitating constructive discussion, how to do proper
brainstorming, how to come up with creative solutions to
problems and how to distill problems into their essence. I
particularly enjoyed the ‘provocation’ method. For example, when
discussing extreme
programming, we took the sentence “in XP you write the
tests first”, and ended up with the provocative statement “never
write tests”. That led me to contemplate systems that are never
tested, and thus are expected to fail quite often, and thus must
learn to cope with their failures gracefully, which leads to
completely different ways of thinking about designing software
systems. Fun stuff.

syscalltrack – another bug that wasn’t squashed[0]

We support two methods of communication with the kernel in
syscalltrack. The first and oldest is via sysctl, and is fairly
ugly. The second is via a device file. While I was testing the
previously mentioned build fix to get it to build with Linux
2.4, I noticed that loading and unloading rules via the device
file was failing with -EBADF, while sysctl was
working. Yesterday I checked and figured out what was
happening (quoted here because it doesn’t show up in the
archives yet).

 
On Sat, Feb 21, 2004 at 11:57:18PM +0200, Muli Ben-Yehuda wrote:
> tea:/hydra/home/muli/src/syscalltrack-head# tests/stress/tester -d 
-t simple_syscall_usage
> starting test 'simple_syscall_usage' (subsystem module(1)) []
> 'dev_file_do_request': failed to send the request, with error 'Bad
> file descriptor'

-EBADF is returned in only one place, when someone tries to write to
the log device. Why would we be trying to write to the log device,
when we're actually trying to write to the control device?

Answer: because the major numbers on the device files /dev/sct_ctrl0
and /dev/sct_log0 are messed up?

Indeed, because I loaded the modules manually rather than via
sct_load, the device files had the wrong major numbers, and
/dev/sct_ctrl0 actually had the major number of the log
device. Oops. Fixing the device numbers for the /dev/sct_* files based
on the output from /proc/devices solved the problem.

On a side note, I think we should move to netlink for
communicating with the kernel, as that seems to be the standard
way to do it.
relayfs could also be interesting, if and when it ever makes
it into the vanilla kernel.

[0] This title reminds me of the closing slide in the Creative
Thinking workshop. The slide said “opportunityisnowhere”, and
you could parse it either as “opportunity is no where” or
“opportunity is now here”, depending on your general outlook on
life. FWIW, It’s the bug that wasn’t, not the bug that wasn’t
squashed.

a semblance of weekend hacking

Fixed a bug in syscalltrack, where the
kernel module wouldn’t build against 2.4.25-rc3 due to b0rkeness in the Makefiles. We
were defining things that only the build system should define,
when appropriate, such as EXPORT_SYMTAB. Works for me with and
without module versioning, but Amir says that it’s still broken
for him. Waiting for more details.

(later…) Turns out it really was broken. The fact that a
kernel module compiles does not mean it will actually
load. Fixed it after a couple of hours fighting with 2.4’s
kbuild and our convoluted modules structure. Building out of
tree modules is such a pain, every time I do it I vow never to
do it again.

I also gave some serious thought to the 2.6 port while doing the
dishes (some of my best thinking happens then…) and decided
that I’m not going to work on it in the near future. Life is too
short and my TODO list is overflowing with more interesting,
less Sisyphic stuff. If anyone wants to pick this up, I’ll be
happy to help.

Also Spent a couple of hours trying to figure out why the LaTeX
slides from Orna’s upcoming shell lecture slides won’t get
correct syntax highlighting in XEmacs. A verbatim environment
with ‘$’ signs in it, which
font-latex.el parses as starting a math
environment. Eventually gave up temporarily and fired off a bug
report to the author.

Still reading Paul
Graham’s ANSI Common Lisp. That books blows away my
mind. Last ght’s brain food was a ray tracer, and then macros. I
could feel my mind rhythmically expanding and shrinking while
reading.

Colin Watson gave a
status update on debian-devel-announce. I should go look
at the release critical bug list and see if there’s anything I
can fix, because I should contribute more to my favorite
distribution. In fact, I should do that right now.

all userspace and no kernel makes Muli a dull boy

There’s this project at work, let’s call it Whale, that I’m
working on at the moment. That project is Strategic, and
Important. The tasks that I’m working on require significant
Linux expertise. However, they are all userspace tasks,
with nary a kernel code line in sight. For an aspiring kernel
hacker such as yours truly, that is, to put it mildly, “not
optimal”. On-going efforts to move to another project where it’s
all kernel and no luserspace, are meeting stiff resistance. This
is despite past promises to the contrary, and it makes me very
unhappy. Watch this space for updates.

show me the code

There’s this Telux
talk on Sunday. The talk is titled “The Open Source Development
Model”. It’s going to be given by Ori Idan
and Shoshannah Forbes. I find
it curious that neither of the speakers appear to have done any
significant open source development – especially considering the
work done by some of the other Telux members.

Now, don’t get me wrong, documentation is important, and so is
evangelism and helping new users, and any other non-development
task. But none of them compare, IMNSHO, to actually putting in
the effort and writing code. The code is the foundation that
everything else is built on. Without the code, neither
documentation nor evangelism would make any difference.

edit: Shoshannah wrote to let me know that the talk is titled “OpenSource for Non-Developers”, which certainly puts everything in a different perspective. I stand by my original comments in general, but they obviously do not apply in thic case.

Rough and partial notes from Elad Barkan‘s Security
Weaknesses in the GSM Cellular System talk. For most of the
excellent talk, I was too busy listening to take notes. Any mistakes
here are more than likely mine, not Elad’s.

GSM uses algorithms called A3/A8 for authentication and key exchange,
and an algorithm called A5 for encryption.

Most operators use COMP128 for A3 and A8, COMP128 is not a trapdoor
function (one way function), and was thoroughly broken.

A5 is a PRNG, input is Kc and Frame#, output is a one time pad used as
keystream. There are several versions of A5:

• A5/0 – no encryption
• A5/1 – strong encryption
• A5//2 – weak encryption
• A5/3 – newest algorithm based on KASUMI – not used yet, believed
  to be safe. Based on sound cryptographic protocols and open for
  review.

All of the previous attacks against A5 are known plaintext attack, and
it is not clear how can an attacker gain the known plaintext.

Elad et al present a cyphertext only attack, with less than a second
of cyphertext required!

The GSM design flow is that is uses error correction codes, but
wrong. The usual way is message -> cyphertext -> coded cyphertext, the
GSM way: message -> coded message -> encrypted-coded-message. GSM
introduces HUGE redundancy into every message – basically every bit is
repeated again at a known location. Gives us plenty of info for an
algebraic attack against the cyphertext.

Attack is less than a second on a pc, against cyphertext only, on
A5/2. A5/1 is less trivial, but doable, given enough pre-computation
and storage.

Another flaw: the session initiation stage uses any of the A5 protocols
the base station tells the phone to use, and the base station is never
required to authenticate to the phone. Simple man-in-the-middle attack
allows us to tell the phone to use weak A5/2 for session initiation
stuff, and get all of the phone’s secret information. Even if the
network uses A5/1, by the time the phone switches to A5/1, we know its
secret and can decrypt everything.

Hamakor yearly assembly

Yesterday evening Orna and me attended the first yearly meeting
of Hamakor. It took
place at TAU, and there were about 20 people in attendance. The
agenda included a short summary by gby delivered in his usual
entertaining style, short speeches by whoever was interested in
speaking during which I tuned out and worked on ljablog.el, and election of a new board of directors and
comptrollers committee. After the meeting we went to an
excellent restaurant called “To The Bone”, and much fun was
had.

The new board is made of Nadav Har’El, Alon Altman
and Ori
Idan. Somehow I found myself elected to the comptrollers
committee, along with former board member Shachar Shemesh and Adir
Abraham. I wish the new board members the best of luck, and look
forward to their efforts in the upcoming year.

There were a few unpleasant moments during the meeting and
afterward, though. Some of the people in attendance grate on my
nerves whenever I meet them, and I was too polite to tell them
to just fuck off already. I have little patience for
people who won’t let the speaker finish what he’s saying before
jumping in with an asinine question or proclamation, or who are
self proclaimed experts, and both kinds were well represented
there.

elisp, how I love thee

Spent large parts of the day today playing with xemacs and
elisp. I looked for an xemacs TODO mode, and settled on a
customized todoo.el,
after checking out todo-mode.el. planner.el
also looks promising, but will require some time to learn in
depth. I also worked some more on ljablog.el,
converting it to use structures for the different blogs it
supports. I think I’m reading elisp fluently now, at least when
macros aren’t involved. As a matter of fact, I should post this
now and go continue reading Paul Graham‘s ANSI Common
Lisp.

Amir has merged the FreeBSD port to syscalltrack HEAD. HEAD now has support for Linux, FreeBSD, NetBSD and OpenBSD! cool beans.

Yesterday, Amir implemented support for ‘fullpath()’ and ‘fdpath()’ in the filter format. This is a feature our users (all two of them ;-)) have been asking for a long time. It allows the user to match against the full path of a file, or the full path of a file descriptor. Now you can have a rule that catches every read of ‘/etc/passwd’, without catching ‘open’ first and noting the file descriptor. Of course, this is NOT SECURE, since another thread could come in and modify the syscall parameters after we check them and before the kernel acts on them, but syscalltrack is a debugging, not security, tool.

I had a nice idea today during a discussion with Amir and choo on syscalltrack-hackers, to unify the filtering and logging syntax and mechanisms. The benefits are obvious, consistent configuration syntax and less complex kernel code, because the logging format is currently parsed completely in kernel, unlike the filter format. The only disadvantage is breaking configuration file backward compatibility. I think it’s something we can still afford to do, at this stage of development. I might even take a stab at implementing it later tonight, after (during ;-)) Hamakor‘s yearly meeting. It will be a nice refresher from the weekend’s elisp hacking.

It’s days like these that make me appreciate free software. Whenever I
would post a blog entry with HTML’s ‘pre’ stanzas in it to
livejournal via ljupdate, the
entry would appear horribly mangled (exhibit
1). That in itself is not too bad, since I could go immediately to
the livejournal website and edit it to display properly, but when the
entry got syndicated on kerneltrap, it would make the
page impossbile to view. Unacceptable – exhibit 2.

So I dug into the ljupdate source code to figure out what was going
on. It turns out that ljupdate would munge the text in order to
prepare it for livejournal’s incoming filters, which would demunge it
into proper HTML. Unfortunately, the munging would destroy ‘pre’
stanzas, rendering them all on one long line.

After ascertaining that this was the problem, I set out to fix
it. First I tried to get ljupdate to not munge ‘pre’ stanzas, but
then, after reading this
post, I decided to implement an ‘HTML mode’ flag. A few hours
later and several tens of test posts later, it works.

all
on
different
lines!

ljupdate-allow-the-user-to-mark-post-as-html-A1 is the ljupdate
fix. Now to integrate with ljablog.el…