Killing Free Software with Kindness

Free Software and Open-Source has gained a massive foothold in industry. Mobile phones, digital TVs, laser printers, etc. nearly all build on free software. It is actually hard these days to find embedded devices which do not contain free software. By any measure of deployment, free software is now wildly successful. That success brings economic benefits to free software hackers, in terms of employment.

Free Software has its roots in a desire to be able to tinker on software. In particular, it’s distinguished from hobbyist programming by a desire to be able to fix or improve software in devices one owns or has access to. As such, Free Software is an ethical construct which argues that vendors have a duty to their users to provide them with the ability to modify the code on the device (this is the “freedom” part). It has been further developed to argue that free software is economically a more efficient way to develop software.

As free software gained adoption, there has perhaps been an increasing trend amongst its developers to weigh the economic aspects far more heavily than the freedom to modify code. E.g. Linus Torvalds has stated he is fine with vendors using DRM on Linux devices to lock down the code, which could prevent users modifying the devices. Certain former BusyBox developers seem more concerned that big corporations use free software rather than provide source. There are many other calls for free-software copyright holders to be “pragmatic” about licensing.

Effectively, many developers now take an economic view of free software. They view free software perhaps purely as an advertisement of skills, a professional tool to build reputation, and what not. The ethical “end-user freedom” aspect is no longer significant, for many, who view it as unpragmatic. This leads to a “softly-softly” approach to Free Software licence enforcement being advocated by some, effectively tolerating vendors who do little to honour their apparent licence obligations.

However, I would argue that this is short-sighted. Firstly, if one does not believe in enforcing free software licences like the GPL, then what difference does one think there is between GPL and BSD? Secondly, consider the following:

Imagine 2 companies:

  • BadCorp
  • GoodCorp

BadCorp uses Linux, as it’s cheap and saves them precious per-unit $$ in royalties. Their upper-management have no great appreciation for free software and/or open-source other than expediency. They will release only as little code and material as they have to. They have a relatively large in-house legal team who are certainly capable of figuring out what their responsibilities are in distributing such software. They have been engaged with in the past by free software organisations about their licensing failings, however they still fail to provide full sources to the GPL software they distribute in their devices – i.e. there can be no doubt this behaviour is deliberate.

GoodCorp is medium-sized. They also use Linux because it’s cheap. However, they have people in their top-level management, perhaps founder-engineers, who still appreciate some of the reasoning behind free software, such as ethics and longer-term efficiency. The company doesn’t have huge resources, but they are willing to put in a little engineering effort into longer-term issues, like going through the community processes to get code reviewed and integrated upstream, as they can see some longer-term value in doing so, even if it less tangible. They are meticulous about making sure they comply with the GPL and they even GPL some (or, in the case of AngelCorp, all) of their device/function specific code in order to contribute back to the free software pool.

If BadCorp fails to meet its obligations, again and again, and no real action is ever taken against it, it can be argued that this is effectively punishing GoodCorp. GoodCorp is spending some of its scarce resources on complying with the GPL and engaging with the community, which BadCorp is not. This puts GoodCorp at a competitive disadvantage to BadCorp. The rational thing for GoodCorp to do is to emulate BadCorp and free up those resources and lower its costs. If nothing changes, eventually one of the more short-term-focused, businessy types in GoodCorps’ management will prevail with such an argument over the founder-engineer(s) types.

So by not enforcing free software licences, you reward those companies that pay lip service to their obligations and you punish those that care about meeting their obligations by allowing the one to free-ride on the efforts of the others. Economics dictates that the equilibrium point for the ratio of leechers to contributors will be much higher with a laisez-faire approach to licence enforcement, than it would be if the licence were enforced1.

In short, even if you take a “pragmatic” view of free software – if you are uncomfortable with the idea of suing companies that use customised free software in their devices – if you still believe that these customisations should be published (in accordance with those free software licences which often demand this), then it is important to the longer-term economic viability of free software that enforcement takes place.

Basically, and apologies for loading the terminology, are you for BadCorp or for GoodCorp?

1. This is true up to the point where licence enforcement activity makes proprietary software more attractive. Some people would argue this point is quite low, that only a laisez-faire enforcement approach allows significant adoption of free software. However that seems unlikely to me, as I feel that free software saw significant adoption rates during the period in the late 90s and early 2000s when most developers still emphasised the ethical, freedom aspects of free software. This particular argument needs further investigation, in particular to see which way the evidence lies – i.e. when the laisez-faire attitude took hold compared to adoption.

Leave a Comment

Thread-Level Parallelism and the UltraSPARC T1/T2

[I wrote this last year for something else – maybe sort of interesting given there’s been news recently about Intels’ Larrabee]

Thread-Level Parallelism and the UltraSPARC T1/T2

For a long period of time, increases in performance of CPUs were achieved by maximising sequential performance. This was achieved by increasing the instructions/cycle, using ever deeper, multi-issue pipelines and ever more speculative execution – thus extracting ever more instruction-level parallelism (ILP) from blocks of code, at ever higher clock rates. [3][4][5][6] Processors such as the DEC Alpha 21264, MIPS R12000 and Intel Pentium 4 were the result of this. As an example, the Pentium 4 Extreme Edition featured a 4-issue, out-of-order, 31 stage pipeline, and clocked at up to 3.2GHz, consuming 130W in the process.[4]

Unfortunately, though this approach served the processor industry well throughout the 1990s and most of the 2000s, its doom had already been foretold. David Wall showed empirically that there were practical limits to the amount of ILP available[1]. These limits were surprisingly low for many typical codes – between 4 and 10. Others observed that the disparity in the growth of CPU compute power, relative to memory access times, was increasing at such a rate that the latter would govern system performance ever more – dubbed the “memory wall”[2]. This meant all the gains made by complex, ILP-extracting logic would eventually be reduced to nothing, relative to the time spent waiting on memory.

Faced with these apparent hard limits on the gains that could be had from ILP, other levels of parallelism were investigated. Tullsen et al argued for thread-level parallelism (TLP): extracting parallelism by issuing instructions to multiple functional units from multiple threads of execution.[8] This is sometimes called “Chip Multi-Threading” or CMT. Olukotun et al, of the Computer Systems Laboratory of MIPS’ birthplace, argued that multiple, simpler processor-cores on a chip would be a more efficient use of the transistor budget for a chip than a single, complex, super-scalar core.[3] This is sometimes called “Chip Multi-Processing” or CMP.

Intel added CMT to their P4 CPUs, calling it “Hyper-Threading”. While it improved performance on many workloads, it was known to reduce performance on single-threaded numerical loads. Intels’ Core/Core2 Duo range are not CMT, but are CMP (being multi-core).

A 3rd, more practical factor would also come into play: Energy usage.[4][6] If an ILP-maximising processor is less efficient than a TLP-maximising processor, then the latter can potentially save a significant amount of energy. If the memory-wall means complex ILP logic will be to no avail, then ditching that logic should save power without affecting performance (in the aggregate).

In 2006, Sun released a brand new implementation of UltraSPARC, the T1 – codenamed “Niagara”. Like several other server-orientated processors, the UltraSPARC T1 was both CMP and CMT, having up to 8 cores, each core handling 4 threads. The Niagara differed reasonably radically from those other offerings in that it was designed specifically with the “memory wall” in mind, as well as power-consumption. To this end, rather than using complex, super-scalar processor cores, the T1 cores instead were very simple. Each core is single-issue, in-order, non-speculative and just 6 stages deep. The pipeline is the classic 5-stage RISC pipeline, with a “Thread Select” stage added between IF and ID. Each core is therefore relatively slow compared to a traditional super-scalar design. The T1 clocks at 1 to 1.2GHz due to the short pipeline. Rather than trying to mask memory latency with speculation, the T1 switches processing to another thread. So, when given a highly-multithreaded workload, the T1 can make very efficient use of both its compute and memory resources by amortising the memory-wait time for any one thread across the execution time of a large number of other threads. Thread selection is the only speculative logic in the T1. It is aimed at highly threaded, memory/IO bound workloads (e.g. the server half of client/server). [4] [5][6]

This approach has additional benefits. Less speculation means fewer wasted cycles. Rather than spending design time on complex, stateful logic to handle speculation and out-of-order issue, the designers can instead concentrate on optimising the chip’s power usage. The many-core approach also physically distributes heat better. The T1 uses just 72W, compared to the 130W of the P4EE, despite the T1s greater transistor count, and much higher peak performance/Watt on server work-loads. [5][6]

The T1 has just one FPU, shared by all cores. This a weakness for which the T1 has been much criticised. Indiscriminate use of floating-point by programmers, particularly less sophisticated ones, is not unheard of in target applications like web-applications (PHP, etc.). The T1 may not perform at all well in such situations. The T1 core also includes a ‘Modular Arithmetic Unit’ (MAU) to accelerate cryptographic operations.

In late 2007, Sun released the UltraSPARC T2. This CPU is very similar to T1. Changes include a doubling of number of threads per core to 8; an additional execution unit per-core and 2 issues per cycle; an 8-stage pipeline; an FPU per core (fixing the above major sore-point of the T1); and the ability to do SMP.[11] This allows for at least 32 cores and 256 threads in a single server (4-way SMP). A single CPU T2 system soon held the SPECWeb world record.[13]

Intel have gone down a somewhat similar path with their Atom processor – a very simple x86 CPU with CMT, but there are no CMP versions of it (yet).[10] Intel are also working on a massively-CMP x86 CPU, called “Larrabee”, using simple, in-order cores.[9] This will have 16 or more cores initially. It is to be aimed at the graphics market, rather than as a general-purpose CPU. Caveon offer the ‘OCTEON’, a MIPS64 based CMP, with up to 16 cores, targetted at networking/communications applications.[12]

To date there are no other simple-core, massively-CMP,CMT processors available as general-purpose systems other than systems using the UltraSPARC T1 and T2. The simple-core, massively-CMP/CMT approach it uses is undoubtedly the future, given the long-standing research results and more recent practical experience. It may take longer for such chips to become prevalent as desktop CPUs though, given the need to continue to expend transistors to maintain high sequential performance for existing, commonly minimally-threaded desktop software.

1. “Limits of Instruction-Level Parallelism“, Wall, DEC WRL researc report, 1993

2. “Hitting the Memory Wall: Implications of the Obvious“, Wulf, Mckee, Computer Architecture News, 1995

3. “The Case for a Single-Chip Multiprocessor“, Olukotun, Nayfeh, Hammond, Wilson, Chang, IEEE Computer, 1996

4. “Performance/Watt: The New Server Focus” (2005), James Laudon 1st Workshop on Design, Architecture and Simulation of CMP (dasCMP), 2005.

5. “Niagara: a 32-way multithreaded Sparc processor” Kongetira, Aingaran, Olukotun, IEEE Micro, 2005,

6. “A Power-Efficient High-Throughput 32-Thread SPARC Processor“, Leon, Tam, Weisner, Schumacher, IEEE Solid-State Circuits, 2007,

8. “Simultaneous Multithreading: Maximizing On-Chip Parallelism“, Tullsen, Eggers, Levy. 22nd An. Int. Symposium on Comp. Arch., 1995.

9. “Larrabee: a many-core x86 architecture for visual computing“, Seiler, et al. ACM Transactions on Graphics, Aug 2008.

10. http://www.intel.com/products/processor/atom/index.htm

11. “UltraSPARC T2: A Highly-Threaded, Power-Efficient, SPARC SOC“, Shah, et al. A-SSCC, 2007.

12. http://www.cavium.com/OCTEON_MIPS64.html

13. http://blogs.sun.com/bmseer/entry/sun_s_even_faster_specweb2005

Auxiliary Sources for Thread-Level Parallelism:

Leave a Comment

Quagga.net Outage

Update: Seems I can’t read – the outage possibly could be prolonged, but should not be permanent. The provider is working on the issues (power problems affecting the rack). We don’t have an immediate need for hosting, however a dual-disk caddy for a T1000 would still be ultra-useful. Thanks!

There’s been a major outage of Quagga.net services. The hosting provider has literally had to pull the plug for emergency reasons. It doesn’t look like service at that provider will be restored on any permanent basis. We’re currently looking for someone willing to sponsor costs for some or all of the following:

  • Server hosted on a commercial basis with:
    • Remote serial console
    • Remote power-switch
    • KVM support
    • 80GB or more of redundant storage
  • Hosting of a Sun T1000, ideally with:
    • Shipping costs paid for from Belgium
    • Existing single-disk upgraded to Sun dual-disk (this would obviate need for former server)

This would of course have to happen just as I’m away on holiday for 3 weeks, with only limited internet access.

If you think you can help, please leave a comment with your email.

Comments (3)

The Man Who Invented NAMA is a Property Developer

It seems Dr. Peter Bacon, the man who Fianna Fail turned to for an answer to the property-loan banking crisis and who has come up with NAMA is a bit of an academic shill for hire:

The cost of the report to Longford County Council was around €25,000-€30,000. … A substantial portion of this was contributed by an anonymous donor — believed to be Longford-born builder Joe O’Reilly.

He is, of course, a long-standing beneficiary of contracts from FF governments:

Close to former Taoiseach Bertie Ahern, his economic consultancy, Peter Bacon & Associates, picked up a steady stream of public contracts even after the Government’s change of tack on housing policy.

The best part is that he has had, extensive interests in property development companies himself. If he does not hold shares still (unusual for board members to not be compensated with shares), then he certainly must have many friends in an industry that will no doubt be a source of revenue to him again in the future:

Peter Bacon … former board member of Ballymore Properties, one of the property developers now in the spotlight,

So the plan to have all the bad property loans offloaded to the Irish state was invented by a man who quite probably is a Fianna Fail crony amd a man who besmirches his academic title through shilling. A man who definitely has very close ties to the property developers.

Why are we letting Fianna Fail “fix” this problem with this destructive plan? Why don’t the Greens walk out and let the country vote?

(And yes, I’m a bit late to this revelation)

Leave a Comment

Quick Guide to Rescuing Banks and NAMA

Based on my layman’s reading of various articles out there, here’s my rough but hopefully representative guide to rescuing banks:

     Good <---------------------------------------> Bad
     re-capitalise            do              overpay
     through                nothing         massively for
     equity                                 bad debts of
     investment                            unknown value

On the left-hand side is rescuing banks by the state investing in equity (i.e. buying shares) and potentially acquiring it completely (nationalisation) to later spin-off the good bits back into private ownership (Buiter’s “good bank”) and wind-down the bad bits. This approach has been tested before in Sweden’s banking crisis, and is currently working quite well in the UK.

On the right-hand side is where you overpay the banks massively for bad debts, with no more than a vague promise that you might try recover some of the losses in levies if the losses are too huge, and where you get no stake in the future profits the banks will make thanks to your rescue. I.e. NAMA (or SCAMA?).

“Oh, but do you really want the governments to run a bank?” – Well, do you want the government to (part-)own an existing bank through shares, or do you really prefer the government to have to setup from scratch an agency, complete with political appointments, to directly manage a very big lump of loans and property?

It seems only Green Party members can save us.

Leave a Comment

Neocons in a Nutshell

Leave a Comment

Wisdom of Squid for More Security Sensitive Applications

CVE-2009-2621 was released last week. The issues seem to include a buffer-overflow, which implies a potentially easy remote root shell exploit1. So it’s perhaps worth repeating my previous claim that Squid really should not be used for security sensitive applications.

This is not to take away from Squid. As the swiss-army knife of web-caching/proxying software it’s awesomely valuable software. It’s just that building for security is somewhat at odds with software intended to be highly flexible and featureful.

Even if Squid’s code were 100% defect free managing its default feature-set remains a significant security problem. E.g. my own ISPs’ Squid-using Pædosieve still honours CONNECT to anywhere, proving just how hard it is to configure such software to disable unneeded features – and they were made aware of the problem many months ago. Prior to that they had forgotten to lock-down access to the internal in-band management protocol (accessible by using CONNECT proxying to localhost). They only recently disabled SMTP on the Pædo-sieve, possibly because they received email sent through it via the Squid proxy.

1. The bug report mentions this is triggerable via ESI, which I don’t think is relevant to a Pædo-sieve, but as it was in some generic string storage code there may well be many other paths to the bug.

Also, bugs were found in the HTTP header parser, where it will assert if fed a very large header. Relying on assert() is somewhat fragile, as these can be disabled by the compiler. Indeed, the fix for the ESI buffer overlow is to add an assert, it seems. Not confidence inspiring, security wise at least.

Leave a Comment

Good Password Hygiene

In a hypothetically perfect world, we’d be able to remember infinite numbers of passwords. However, for most people that’s not possible. Instead we have to find a way to make best use of that limited memory. Here’s how:

  • Do not use passwords that are easy to guess, e.g anything directly related to you, like your name or names of family/friends/pets/etc; or date of birth; or favourite colour,band,etc..
  • Ideally, use a longish random string as your password, of at least 10 characters (but longer is better).
  • The same applies for password-recovery questions, which often ask for information that is in the public domain (e.g. mother’s maiden name, date of birth). Do not provide real answers! Instead just make something up, or use another random string if possible.
  • Do not re-use passwords across different websites, unless you truly do not care about what is on those sites, and what they can do in your name with that password.
  • Do not be afraid to write them down if you can store them securely. E.g. if your home is reasonably secure, it’s fine to store most passwords on paper there. This goes against advice from many well-meaning, but utterly-wrong “experts”.
  • If you trust that a computer or device is sufficiently secure, it’s perfectly fine to store passwords on it, e.g. in a text-file. Also, many programmes support saving passwords and if you trust those programmes then it’s perfectly OK to use those features.
  • Consider using disk-encryption products like PGPDisk, TrueCrypt, BitLocker or the built-in capabilities of many Linux/Unix distributions (some of which offer this at install time) to protect your data with a master key. This is particularly recommended for laptops.
  • Any computer running Microsoft Windows likely can not be considered secure and should not trusted with more sensitive information. Portable devices should not be considered secure, unless their contents are known to be encrypted, and they automatically lock themselves after a small period of unuse (i.e. don’t trust your phone too much for storing sensitive data).

Basically, in an ideal world, all your day-to-day passwords for your various, online accounts should be unguessable, random strings;  you’d never have to remember any of them; you would just, at certain times, have to enter a master pass-phrase (which should be unguessable, but still memorable and much longer than a password) without which the passwords would effectively not be accessible.

Remember, security is a compromise between convenience and consequence. The ideal level of compromise will differ between different people, and between different situations. E.g., obviously, it’s probably a good idea to tolerate a good bit of inconvenience with your online banking login details and commit these solely to memory. If you have too many accounts to memorise the details, then store them very securely, e.g. buy a strong box or small safe, and obscure which details belong to what accounts – hopefully this buys enough time to contact banks and have the details changed if your house is burgled and the box stolen.

Common sense goes a long way. Unfortunately the “experts” you sometimes hear from don’t always have it.

Comments (2)

Sharing DNS caches Considered Harmful

Eircom have been having problems with internet connectivity. It’s hard to get information about exactly what they’re seeing, but there seem to be 2 aspects to it:

  1. Eircom are getting hit with a lot of packets
  2. Customers have sometimes been directed to strange sites by Eircom’s DNS servers

Justin Mason has a good overview of the news coverage. There some points of his worth correcting though:

I.e. DDoS levels of incoming DNS packets are consistent with a poisoning attack on up-to-date DNS servers, which randomise QID.

The moral of the story here is that using recursive, caching DNS servers that are shared on any significant scale, like ISP nameservers or (even worse) OpenDNS, is just unhygienic. They’re just fundamentally flawed in todays internet environment, as they’re juicy targets for poisoning, until DNSSec is widely deployed. When finally DNSSec is deployed, shared, recursive nameservers remain a bad idea as they terminate the chain of the trust – the connection between the NS and client can still be spoofed.

In short:

  • Technical users and systems admins should install local, recursive nameservers. Preferably on a per-system basis.
  • Operating system vendors should provide easily-installed recursive nameservers and should consider installing and configuring their use by default. (Fedora provides a convenient ‘caching-nameserver’ package, and also a new dnssec-conf package with F11, though not enabled by default).
  • Consumer router vendors already ship with recursive servers, but tend to forward queries to the ISP – they should stop doing that and just provide full recursive service (hosts already do caching of lookup results anyway).

Widely shared, recursive nameservers are a major security risk and really should be considered an anachronism. It’s time to start gettting rid of them…

Comments (11)

Mail-Followup-To Considered Harmful

Dear Interwebs,

If you happen to have responsibility for some software that processes mail, please take the time to check the following:

  • That your software always errs on the side of preserving the Reply-To header, when passing on email. E.g. email list software in particular should not overwrite existing Reply-To headers, even if a list is configured to set a default Reply-To.
  • That your software can process Reply-To headers that have multiple email addresses.
  • That your software provides adequate, interactive cues to its user when they reply to an email, so as to discern what the user wants, in the context of what the sender prefers (so far as that is known).
  • If your software supports various weird, non-standard headers, like Mail-Followup-To, Mail-Copies-To, Mail-Replies-To, etc. deprecate and remove this support. No amount of extra headers can obviate the need for the cues in the previous point – all they do is make the situation worse overall.
  • If your software must support these headers, do not let such support cause the standard and well-supported Reply-To header to be automatically ignored.

If you’re a user of software that honours Mail-Followup-To and/or has buggy Reply-To behaviour, please file bugs and/or send them patches.

So why are Mail-Followup-To et al harmful? The answer is that they increase the number of ways that the wishes of the sender, the respondent and the state of the email may interact. What was already a tricky and murky area is made even murkier when you try add new ways to indicate the desired reply-path. E.g. witness Thunderbird’s help on MFT, or Mutt’s help on Mailing lists. I defy anyone to be able to keep all the rules of their MUA behaves in the presence of the various combinations of Reply-To, From, To, Cc, Mail-Followup-To and Mail-Reply-to in their head. For the few who can, I defy them to keep track of how their MUAs support interacts with the support in other MUAs.

Further, Mail-Followup-To has never been  standardised. The header is described in  DJB’s Mail-Followup-To and the dead IETF DRUMS draft. Both specs effectively say that the absence of MFT when a client does a “followup” reply should continue to go to the union of the From address (From == From or Reply-To), To and the Cc. However, these descriptions carry little authority. Unfortunately Mutt, one popular MUA, behaves differently when in list-reply mode and does not fallback to (From|Reply-To)+To+Cc in the absence of MFT – at least when I last investigated. This means Mutt basically does not inter-operate with other MUAs, when it comes to the standards-track means of indicating Reply preferences.

Before we had the problem of trying to get a few cases of bugs in broken Reply-To handling fixed (e.g. lists that blindly over-write Reply-To) + the UI design issues of figuring out where a user intends replies to go, without annoying them. Now we’ve added the problems of fractured interoperability with new same-but-different headers + the problems of bugs and deviations in the implementations of said new same-but-different headers.

Mail-Followup-To == more mess == even more brokenness.

See also: Archived DRUMS discussion on Mail-Followup-To.

Comments (2)

« Newer Posts · Older Posts »