Profile cover photo
Profile photo
Germán Poo-Caamaño

Post has attachment
A followup of my previous attempt of money hats. I had a Cdn$20 (Canadian dollars) note to give away and considering the new series are made of polymer, I took the chance to do an origami before it were too late.
Add a comment...

Post has shared content
Add a comment...

Post has shared content
"Finland rightly deserves attention today as a nation that treats its children as a precious resource and that honors the adults who make education their passion and their career."
Add a comment...

Post has shared content
I was warmly surprised to see how many people responded to my Google+ post about Dennis Ritchie's untimely passing. His influence on the technical community was vast, and it's gratifying to see it recognized. When Steve Jobs died there was a wide lament - and well-deserved it was - but it's worth noting that the resurgence of Apple depended a great deal on Dennis's work with C and Unix.

The C programming language is quite old now, but still active and still very much in use. The Unix and Linux (and Mac OS X and I think even Windows) kernels are all C programs. The web browsers and major web servers are all in C or C++, and almost all of the rest of the Internet ecosystem is in C or a C-derived language (C++, Java), or a language whose implementation is in C or a C-derived language (Python, Ruby, etc.). C is also a common implementation language for network firmware. And on and on.

And that's just C.

Dennis was also half of the team that created Unix (the other half being Ken Thompson), which in some form or other (I include Linux) runs all the machines at Google's data centers and probably at most other server farms. Most web servers run above Unix kernels; most non-Microsoft web browsers run above Unix kernels in some form, even in many phones.

And speaking of phones, the software that runs the phone network is largely written in C.

But wait, there's more.

In the late 1970s, Dennis joined with Steve Johnson to port Unix to the Interdata. From this remove it's hard to see how radical the idea of a portable operating system was; back then OSes were mostly written in assembly language and were tightly coupled, both technically and by marketing, to specific computer brands. Unix, in the unusual (although not unique) position of being written in a "high-level language", could be made to run on a machine other than the PDP-11. Dennis and Steve seized the opportunity, and by the early 1980s, Unix had been ported by the not-yet-so-called open source community to essentially every mini-computer out there. That meant that if I wrote my program in C, it could run on almost every mini-computer out there. All of a sudden, the coupling between hardware and operating system was broken. Unix was the great equalizer, the driving force of the Nerd Spring that liberated programming from the grip of hardware manufacturers.

The hardware didn't matter any more, since it all ran Unix. And since it didn't matter, hardware fought with other hardware for dominance; the software was a given. Windows obviously played a role in the rise of the x86, but the Unix folks just capitalized on that. Cheap hardware meant cheap Unix installations; we all won. All that network development that started in the mid-80s happened on Unix, because that was the environment where the stuff that really mattered was done. If Unix hadn't been ported to the Interdata, the Internet, if it even existed, would be a very different place today.

I read in an obituary of Steve Jobs that Tim Berners-Lee did the first WWW development on a NeXT box, created by Jobs's company at the time. Well, you know what operating system ran on NeXTs, and what language.

Even in his modest way, I believe Dennis was very proud of his legacy. And rightfully so: few achieve a fraction as much.

So long, Dennis, and thanks for all the magic.
Add a comment...

Post has shared content
I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information.

I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately.

He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind.
Add a comment...

Post has shared content
A little digression on security stuff

Today's victim is the Android pmem.c driver - and yes I told Google about this a month ago and they've been looking at it.

It's an interesting example of two things, both of which are real problems with the C language and to an extent with the kernel verification and validation tools.

pmem.c is on the whole reasonably well thought out. The majority of the code clearly documents its locking model. It handles types and values very carefully. Two things however are a bit of a problem

Firstly there is a small unchecked overflow

static unsigned long pmem_order(unsigned long len)
int i;

len = (len + PMEM_MIN_ALLOC - 1)/PMEM_MIN_ALLOC;

and the code then checks the order is valid. By this time however it is too late, a passed length of 0xFFFFFFFF will overflow and we get the wrong order.

The damage here is actually fairly small on the whole because the code is consistent about what it uses afterwards. It checks the order, and it uses the order for everything else. So I can ask for lots but get a little and it stays enforced as a little.

That shows three things always worth remembering

1. Overflow is evil. It's a pity C and processors were not defined that overflow trapped as they often were in mainframe days. Actually it's less evil here than some others because unsigned overflow is at least defined behaviour. Signed overflow is not so well defined and the compiler can use that creatively for "optimisation"

2. Check your inputs. Checking the output of something which processes untrusted input data is too late

3. Always check what you use. Google got this right and it saved their bacon. The resulting order may be wrong but it's used consistently and there is no mix of length/order elsewhere in the code which would have been catastrophic

The second problem is worse though. It's hard to tell how it happened as I don't have the entire history. It shows why code review is important and that stuff hidden in other trees may not get enough review. It also to an extent shows up a C and tool weakness.

My guess (and it is but a guess) is that the original pmem.c didn't have ioctl support and someone wrote it, someone who wasn't so experienced with multithreading and locking. The rest of the driver clearly documents and uses its locking rules. The ioctl paths just assume that there is locking lower down. In most cases there is. In a couple of cases there aren't. In one case this is a bit of a disaster

The PMEM_ALLOCATE ioctl checks if an allocation already exists, and allocates a new chunk. As far as I can see there are no locks taken. This allows the caller to do parallel allocations corrupting the allocation pool, and also to do parallel allocations and mapping functions whose results to say the least are going to be exciting. On uniprocessor and on older kernels with the BKL applies to ioctl it's probably not going to be hittable but you can keep trying very easily.

It's not btw been used on a Google device since the Nexus One (according to Google) so it's one of those 'near miss' cases, unless some third party is using it on a much newer or SMP device.

It would be easy to question the quality of the author of the code for such a mistake but more importantly the real question ought to be

- Why is it possible to make such a mistake ?

This is another area where C cannot enforce locking as the locking is outside of the language scope and while you could have added runtime assertions they all have a cost.

- Why wasn't it caught

Two possible answers come straight to mind - no peer review and because the tools can't catch it. I'm not entirely sure casual peer review would have caught it.

It does suggest we could do with a virtual machine environment where you can associate memory ranges with read/write access violations if a given lock is not held. It's hard to do this with page tables because you need a page an object unless you do clever fault handling, and because objects often contain their own lock, which itself is accessing/changing the object memory region legitimately.

A bigger style question is why pmem_allocate is different. The other helpers mostly take the locks. A clear interface where locks are taken close to the code that must hold them can really help. Sometimes it means having 'internal' versions of functions to call without the lock to avoid lock recursion but that at least can make clear the special cases.

Some day someone will write something that supercedes the Linux kernel. Probably before that someone should either fix or replace C so that it has an inbuilt ability to describe locking and statically enforce some of the locking rules at compile time. I'm sure my generation of programmers will despise the resulting language but in time we will all thank whoever does it.
Add a comment...

Post has shared content
If you don't know what's at stake with Canada's Warrantless Internet surveillance bills, it's time to get informed.
Add a comment...

Post has shared content
The EFF has more on the fake Google certificate; seems it's been in use in Iran since July 10. Not good. One wonders how many others are out there.

It's interesting that this certificate was caught using Chrome's "public key pinning" feature. Now they're saying anybody with a certificate can contact Google to get it wired into the browser. This suggests to me that we may be moving from a world full of flaky certificate authorities to the establishment of Google as the "real" certificate authority. Google may well do a more competent job of it, but I'm not at all sure I like that alternative either.
Add a comment...

Post has shared content
This is so cool! Fog Creek Software's recruiter Anna Lewis posted an opinion piece in the Washington Post that mentions GNOME's women outreach effort and the finding that advertising the opportunity to learn and work with a mentor resonates with women!

She learned about it from Leah Hanson, who was the only female intern at Fog Creek Software this summer.

While Leah learned about it from Hanna Wallach, who talked about Women in Free Software at John Hopkins in April.
Add a comment...

Thanks to +Jeff Schroeder's recommendation, +Tatiana Gutierrez-Bunster and I are enjoying frozen yogurt at Wonderpots next to Humboldt University. Slightly noisy, but very friendly environment.
Add a comment...
Wait while more posts are being loaded