Paul Boddie's Free Software-related blog

Paul's activities and perspectives around Free Software

Other people’s thoughts on “Freedom and security issues on x86 platforms”

A couple of months ago, we had a brief discussion on the FSFE discussion mailing list about the topic of “Uncorrectable freedom and security issues on x86 platforms“, but it just came to my attention that a bunch of other people were discussing our discussion, too. Hacker News is, of course, so very “meta”, but fortunately they got onto discussing the actual topic as well.

The initial message in the original discussion advocated adopting the Power computing architecture as a primary hardware platform for Free Software. Now, the Hacker News participants were surprised that nobody mentioned SPARC and yet I was sure that SPARC did get mentioned in our discussion. A brief search doesn’t find any mention of it, however, and I’m embarrassed to admit that I do know about things like LEON and even used SPARC-based hardware for many years. (The Sun 4 workstations at my university had SPARC CPUs, for instance.)

I suppose the disconnect here involves price, availability and performance of readily-available products. Certainly, a free hardware SPARC implementation can be synthesised for an FPGA, but the previous discussion covered things like RISC-V in a similar fashion: it’s nice to have the ability to deploy a “soft processor” in an FPGA, but customers of computing products usually expect “hard” CPU performance. And you can at least buy ARM and MIPS CPUs, even if they aren’t free hardware implementations, having decent-enough performance which support Free Software from the very bottom of the software stack.

The participants in the meta-discussion wondered why MIPS became so popular given that there are licensing fees involved, whereas Sun made certain SPARC designs available under the GPL, and given that the SPARC architecture is supposedly royalty-free. For some manufacturers, this is asking the wrong question: they did not seek to license the patent-encumbered versions of the MIPS architecture; like the OpenRISC initiative, they merely implemented the unencumbered versions instead.

It would be nice to have a high-performance, inexpensive, readily-available free hardware CPU for use in free hardware designs. And of course those designs would support Free Software completely. But until that comes to pass, we have to work with what we can get. And indeed, for whichever architecture seems to be favoured for such a role, we also need to have usable and accessible hardware that is compatible with our favoured architecture so that we may prepare ourselves for the day it finally gets rolled out.

There might be a reason why SPARC isn’t so well supported by things like GNU/Linux distributions. Sadly, unlike various competitors, inexpensive SPARC products seem to be thin on the ground, and without those the efforts to maintain ports of large Free Software collections inevitably grind to a halt, but I would be only too happy for someone to point me to a source of products that I may have overlooked. There is no inherent reason why SPARC couldn’t be a viable platform for Free Software, regardless of what people may have to say about register windows!

One Response to “Other people’s thoughts on “Freedom and security issues on x86 platforms””

  1. Luke Kenneth Casson Leighton Says:

    hiya paul,

    we’ve been talking on and off, and you’ve helped support
    the eoma68 initiative to make devices that are completely
    computer-agnostic, i.e. upgradeable, i.e. it doesn’t actually
    matter what the processor is, it’s just a “computer card” like
    a “memory card”.

    the advantage of this kind of “computer card” approach is that
    it keeps fabless semiconductor companies on their toes. designs
    of products basically are heavily-tied to the actual processor.
    once a factory begins designing a product based around a specific
    processor, using whatever Reference Designs are available, it’s
    fair to assume that they will continue to do so, except where the
    prices are so ridiculously lower that the factory has to follow
    the money.

    with the eoma68 approach, the freedom to switch out the entire
    computer has the side-effect of speeding up that decision-making
    process, so that if one company produces a spying processor or
    makes a mistake by allowing the VPU to have arbitrary access to
    the memory bus from userspace, people can flip that out at the
    press of a button – END USERS can flip it out – and replace it
    within seconds.

    explaining that to fabless semiconductor companies it becomes
    possible to pressurise them to make *much* better SoCs that, for
    example, properly respect end-user privacy as well as respect
    the software licenses.

    but that’s all background. what i wanted to point out is that
    there is LITERALLY not a SINGLE processor ANYWHERE IN THE WORLD
    that is accessible to us that respects copyright law, user
    privacy, software freedom principles, and is accessible without
    some form of NDA or other cartelling business practice.

    this is pretty insane. it might as well be 1984, not 2016.

    back in 2012 i put together an initiative to create an FSF
    Endorseable Processor. i had a team standing by who were really
    excited because it was something that had never been done before.
    i got a fantastic education into what’s actually involved in
    creating an SoC. for a realistic chance of success first time,
    bearing in mind that the mask charges for 28nm are two MILLION
    dollars U.S., you had better be licensing hard macros from various
    companies which include extremely comprehensive test vectors
    that make damn sure that their part of the final chip will actually
    work.

    so, you pay $50k for HDMI, $25k for audio, $300k for USB3, $300k
    for DDR3/4, $50k for SATA, and so on. the actual processor core
    itself is peanuts. if you’ve ever seen a picture of a RISC
    processor, it’s like 1% of the total die, somewhere in the corner.
    the memory bus lanes are huge: they occupy something like 15%
    of the processor, in a big wide lane down the centre and branch
    out. the 1st level cache occupies a WHOPPING 20 to 30% of the
    entire die, and the I/O pads each take up an incredible 0.1% each
    in order to handle the current and make space for the gold wires
    to contact properly when the die is put into a package.

    now, in amongst this, since this time, we’ve had the RISC-V
    initiative. i think you might be able to tell from the above
    paragraph that to focus the open hardware community’s attention
    on the *processor*, when the hardest part is the *integration*,
    is… a little bit naive. don’t get me wrong: i think it’s great
    that RISC-V exists, and that at some point in the next 10-15
    years we might have a working affordable RISC-V SoC which is worth
    buying.

    but.. i don’t know if the RISC-V teams are actually aware that
    the creation of a 28nm (or below) processor involves hugely
    complex software to work out the best way to lay out the IC,
    from companies like Mentor Graphics, Synopsis and Cadence. this
    software costs $250,000 ***PER WEEK*** to use, it’s that complex
    for them to maintain. synthesis is what it’s called, and it’s
    a totally different proposition to design something for an FPGA
    than it is to design something that will successfully work in
    an actual silicon IC. so there are simulations done which LITERALLY
    take MONTHS to verify – hence all the test vectors.

    now, this is again where the RISC-V project is again a bit naive,
    because they’re developing things like DDR3 interfaces which, because
    of their lack of experience (and lack of access to 28nm and below because of the huge costs involved) are extremely unlikely to work first time.
    multiply that by N interfaces, and the chances of them putting
    together a working fully-open hardware SoC first time, second time
    and even third time are pretty much guaranteed to be ZERO.

    ST Electronics manages to get away with the iterative approach because
    their employees all have “University” credentials on the back of their
    business cards. they use that to gain huge E.U. grants, and on the
    back of *that* they can do iterative experimentation when other companies
    have to spend between $30 to $50 *MILLION* on the synthesis and
    simulation tools which allow them to guage if they will have a 100%
    success before wasting the foundry’s time.

    and that’s the other thing: foundries (such as TSMC) *really* don’t
    like having their time wasted by newcomers who can’t design successful
    ICs first time. they put those people at the back of the queue
    (waiting list time: 18 to 24 months) or they just don’t reply to their
    phone calls or emails. TSMC also prioritise Taiwanese customers above
    all others, which is why CSMC went to a lot of trouble to get hold of
    28nm a few years ago.

    anyway, i thought it might be useful to share these insights into what
    actually goes into getting an SoC made. it’s a totally different world:
    it’s nothing like software. risks are high, but payoffs are huge.
    so i am seeking another way to get an FSF Endorseable Processor made.
    it would be helpful to have the funds to invest in the company that
    i am looking to work with, because that would give a little bit more
    clout. but i might be able to pull it off anyway, without that. we
    will have to see. but you can be absolutely certain that it will
    be a processor that respects software freedom, will have an entirely
    Libre 3D and 2D GPU, a Libre VPU, and will be reasonably modern i.e.
    won’t suck performance-wise or memory-wise.

    it would however be nice to canvas people’s opinions as to what should
    go into it, but i have to be honest that i am reluctant to do that
    for fear of people wanting something resembling a kitchen sink
    (as in “everything thrown in, including the kitchen sink”). having
    been tracking SoCs for over five years now, i have a pretty good handle
    on what’s practical and what’s not. still, it would be good to
    have people’s input just to make absolutely sure i haven’t missed
    anything.