Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Parent Full thread

From that file:

    pci_or_config32(PCI_DEV_HSW, 0xb0, 1 << 0);     /* BDSM */

What is "BDSM"? It almost seems like a strangely appropriate name for another DRM feature.

It's actually somewhat hidden in our haswell driver because so much is now binary-only on Intel platforms.

One thing that I've noticed browsing around Coreboot sources is that the source code is rather opaque - full of "magic constants" with little to no meaning. It may be "open-source" and GPL, but I don't think it's in the spirit of open-source to have code that can't really be understood. I can get the same depth of information by just disassembling a BIOS and seeing what addresses it writes with what values. If anything, it feels like someone has found a way to "contribute" to open-source without actually disclosing much. (Aside: how do binary-only blobs get let into Coreboot? It sort of defeats the purpose, doesn't it?)

and see the system either not start at all, or reliably shut down after 30 minutes

That second alternative is just scary. Really scary, like a hidden silent killswitch.

When all you do is to write a single opaque value in a register, and never use those bits again, it's slightly excessive to give each of them a name. This also reflects in chipset documentation, which sometimes comes with pages and pages of "write X to register Y", and not much more.

The value is that the higher level structure is more easily visible when you know what is code and what is data (which is the main issue with disassembly), and the ability to quickly see that you haven't missed extra code that is executed in some sneaky place because everything in the output is accounted for somehow.

The options we have with coreboot are to have 8MB of unaccounted stuff, or 500KB of unaccounted stuff. The latter can be reverse engineered more easily, since the scope is known, and the complexity is a magnitude smaller (no code decompressing other code, jumping into it, ...). That was actually done for sandybridge. We even built tools to simplify reverse engineering (www.serialice.com)

As for the funnily named BDSM register: http://www.intel.com/content/dam/www/public/us/en/documents/... calls it "Base Data of Stolen Memory". Essentially, both GPU and ME get assigned some system memory to work in, and that register contains the first address that isn't available to the CPU due to this arrangement.

That register itself is harmless. In older Intel chipsets, it was possible for the host CPU to get a peek into the ME's memory by messing with that register, which was used for some ME analysis in 2012 or 2013. Unfortunately they plugged that hole, and that register's role is more of the informative kind.

Interesting stuff! I bet you coreboot guys could write some incredibly interesting blog posts with all the "secrets" you have learned. I really admire your work.

Not a blog post, but one of the coreboot devs held a talk at 31C3 about one of those extra processors in AMD's architecture: http://media.ccc.de/browse/congress/2014/31c3_-_6103_-_en_-_...

This also reflects in chipset documentation, which sometimes comes with pages and pages of "write X to register Y", and not much more.

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.

For the most part it's probably that they kept things flexible that aren't strictly necessary, but it simplified their development process of the silicon.

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.

Reply on news.ycombinator.com