Pages: pp. 6-7
I read with interest "Alan Turing and Bletchley Park" by Charles Severance in Computer's June 2012 issue (Computing Conversations, "Alan Turing and Bletchley Park," pp. 8-10).
However, I was disappointed that the author apparently didn't know, or at least didn't mention, that IEEE had presented an IEEE Milestone in Electrical Engineering and Computing plaque in recognition of the code-breaking work at Bletchley Park and Alan Turing's contributions to those efforts. The UKRI section proposed the milestone, and I made the presentation on 1 April 2003. The award was titled "Code-breaking at Bletchley Park during World War II, 1939-1945."
2004 IEEE President
The author responds:
I was not aware of the award or plaque during my visit. The next time I visit Bletchley Park, I will bring my camera and film the plaque and feature it in any future versions of the video that we might produce.
I opened Computer's June issue with eagerness because I noticed a reference to a piece on Alan Turing on the cover—Turing being a particular hero of mine.
It's terrific that the computing profession chose to commemorate the 100th anniversary of Turing's birth—his contributions to math, science, and the Allied cause in World War II cannot be overstated.
I was, however, disappointed to see the author's light touch, bordering on "happily ever after." Even the comment that Turing "never had to worry about funding his research" has the effect of glossing over the tragedy of his life after the war.
As many readers might know, a mere seven years after the war, Turing became the victim of the UK's anti-gay laws that were on the books in the 1950s. After reporting that he had been burglarized by a lover, Turing was instead himself arrested and offered a choice between imprisonment or chemical castration, solely because of his sexuality. The hero of Bletchley Park, with no blemishes on his patriotism, was stripped of his security clearance. His career was destroyed. After undergoing chemical castration and professional isolation for nearly two years, Turing was dead at 41 years of age, having used cyanide to commit suicide.
This was hardly the "return to academia" implied in this article, and it certainly was not a carefree career—although, yes, Severance was strictly speaking to Turing's time at Bletchley Park. That one of the greatest heroes of computer science and the intelligence communities would be treated so shabbily by the very government he helped to preserve is a matter of great shame, one that Prime Minster Gordon Brown recognized in 2009 with a formal apology.
Although Severance sought to focus on the achievements, rather than the later tragedy, I think he does Turing a disservice by failing to note what he gave up for career and country. Given all he accomplished in the short span of the war, imagine what Turing might have been able to offer the world had he lived a natural lifespan—into the 1970s and 1980s.
Severance also missed out on an opportunity to point out that modern technology companies have been on the vanguard of promoting corporate diversity and tolerance, and that an Alan Turing today—whether in the private technology sector, the intelligence field, or now even the military—would be able to live up to his full potential without the fear of losing his job, his place in society, or even his own testosterone. This is one more contribution that Turing made to modern society, and one that deserves comment—we owe him that.
The author responds:
Andrew Bono's points are all quite correct. I wanted to narrowly focus the column and video on the environment, colleagues, and equipment that surrounded Turing while he was doing his breakthrough work that resulted in many of the founding notions of our field. In my conclusion, I was simply trying to express that it's possible to be far more creative when the stakes are very high and resources are virtually unlimited, as was the case during the period while Turing was at Bletchley Park.
I wrote the column to provide a focused contribution to an overall story that has been well-told across many magazine articles, TV shows, conferences, blog posts, events, and so on during the Turing Centenary month. Bono's letter does a nice job of connecting the column to the larger context.
It's unfortunate that the authors of "Defending against Buffer Overflow Vulnerabilities" (B.M. Padmanabhuni and H.B.K. Tan, Computer, Nov. 2011, pp. 53-60) didn't include a discussion of hardware storage protection keys. Although the article provides several buffer-overflow code examples and graphical illustrations, none of the examples would result in a buffer overflow on a computer with this type of protection.
A protection-key mechanism divides physical memory into blocks of a particular size—for example, 4 Kbytes—each of which has an associated protection key. Each process also has an associated protection-key value. On a memory access, the hardware checks to determine whether the current process's protection key matches the value associated with the memory block being accessed; if not, an exception occurs.
Protection keys are part of the z/Architecture and have been available since 1964. Mainframes and their z/OS operating system are famous for their excellent security characteristics. They rarely, if ever, require a security update. In fact, most z/OS administrators don't remember ever having installed a security patch. While it appears that no data is available, I assume the absence of buffer overflows is a major contributor.
Assuming this is correct, the introduction of hardware storage protection keys in the x86 architecture and their exploitation by the x86 OS, subsystems, and middleware is an urgent requirement. An implementation in each CPU core probably requires only a very small real estate extension.
It doesn't make sense that a Windows server suffers security violations and requires frequent security updates, while a z/OS installation of comparable complexity doesn't.
A description of hardware storage protection keys is available at www.redbooks.ibm.com/redbooks/pdfs/sg246990.pdf, section 1.24, p. 43. The Motorola 68000 microprocessor implemented a comparable capability with its FC0, FC1, and FC2 signals ( www.users.cloud9.net/~stark/txhmt6.pdf, section 6.1, p. 35).