Why Rosyna Can't Take a Movie Screenshot

It almost feels like they're trying to hide something if they don't give any reasoning for what those values do... and so I'm rather curious as to what happens if they're changed. Some bits might have no effect, some could have catastrophic effects (e.g. if they control some of the voltage regulation circuitry), and some could have very useful effects that they just don't want you to know about. Intel CPUs have had undocumented features since their introduction; it's not hard to imagine their chipsets do too.

But assuming that's their goal:

They say they talked with Intel about opening up things, but they're far from the first one to try (and not the most powerful ones either, be it by $$$ or influence, unless there's some background story they keep to themselves).

My guess is that they intend well, talked to some sales folks, those promised the moon (and more, if necessary), and when things get serious, the sales persons will be nowhere to be found, while purism is too far down the road to start from scratch.

In the end, purism has to compromise while Intel can celebrate another design win.

So the end result will be that they use the smaller ME firmware (1.5MB is still a lot of unexplained cruft), the FSP binary (www.intel.com/fsp) and coreboot to glue things together - just like every other coreboot-using Intel based design does right now (there are a couple).

The main difference to everybody else will be that purism builds neither embedded electronics that do things no consumer has ever heard of, nor chromebooks.

That in itself is already a nice thing from a coreboot perspective, in that it provides exposure to the project and the issue, but I fear some purism backers will feel let down by such an outcome.

http://puri.sm/posts/purism-software-freedom-deconstructed/ looks like they try to indicate that "this BIOS code isn't all that much". No, it isn't - but it's exactly the part of the code that sets the rules under which the entire system later operates. In this, it's more important than the plain old (say) gimp binary in that huge top bucket, which has not much of an effect on the security or autonomy of the system or user.

I'd love to be wrong here, since either way I 'win' (actually the more I'm wrong, the more I win :) ). I just think it's unlikely given that I'm involved in that mess for the better part of a decade by now, while the purism folks seem to be newcomers with a lot of idealism but few experience with dealing with Intel and their unusual definition of software freedom.

There isn't much one can do though as favoring convenience over not-so-obvious benefits of (abstract, for them) freedom seems to stem from the very human nature...

I used to think RMS' ideas were a bit far fetched, but with each such revelation that comes to light in the form of post on some relatively unknown blog those ideas seem more and more appropriate.

So when they're done with the silicon, and routed all the traces, and so on, they can run their magic tool that measures delays and things like that, and then calculate the best performing set of values, and write them into the document.

It also allows them to dial back some of the values should they figure out that there are problems. I fully expect these numbers to change a couple of times between them finalizing their silicon and releasing it (and the reference code and documentation) to the public. Now consider how much trouble it would be, even for Intel and their world famous fabrication process, to create new silicon for each of those changes.

Take the tables in i945's raminit (http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=sr...).

From the shape of these values, they're probably some delay configuration for the different types of DDR2 pins (dq, ctl, clk) going from somewhere inside the silicon out to the pin of the package, but I doubt that the documentation actually provided any explanation for them.

Of course, one of these registers could mean 'change all calculations in a way that the electromagnetic field contains the private key'. But they need a better way to enable that function than in firmware, where it's done for everyone.

In the end, I'm fine with such magic values in magic registers, as long as they make some sense (right register block for the current task instead of messing with the audio codec while initializing usb) and are unconditional (that is, no if (user_is_evil()) write_enable_tempest_register(); ).

If there are no unexplained conditionals, any backdoor would have to apply to every user - in which case they could just enable it unconditionally in silicon.