Lots more information in my post up thread.

I came here to say "Ok, so they discovered the JTAG port." Seems that blog was already on it.

Now, the researchers claim demonstrate that, via the JTAG port, they can subvert one form of Actel's AES security (but not all--see below) on someone's design to allow reverse-engineering a circuit design loaded into the FPGA. That's fairly interesting. I know that there's a fair bit of business in claiming an FPGA is invulnerable to such snooping, so that vendor A can ship a prototype design to customer B without worrying that customer B might rip off vendor A's design. For example, vendor A might ship an FPGA-based version of a chip they're designing to customer B, so they can design/debug their system while vendor A finishes the design, so both A and B can ramp their products more closely together.

Here's Actel's pitch on design security. The hack claims to expose the AES key for at least one of their encrypted modes, which implies that that particuler security feature is busted, and the guarantees against counterfeiting, reverse engineering and overbuilding it provides are also busted. According to the (occasionally somewhat breathless) claims in this draft paper, that is indeed what they've accomplished. Even then, they didn't break everything:

There are several security protection levels in the PA3 devices according to the manufacturer's datasheet [14]. The Passkey offers the highest level of reversible protection mechanism. Various DPA techniques were attempted to extract the Passkey, however, we were unable to get even a single bit in two weeks time using our off-the-shelf DPA equipment (oscilloscope with differential probe and PC with MatLab). The Passkey hardware security had robust countermeasures that proved to be DPA resistant. In addition to the unstable internal clock and high noise from other parts of the circuit, the Passkey access verification had its side-channel leakage reduced by a factor of 100. Only noise can be observed in the power traces without any characteristic peaks in the frequency domain. This was likely to be achieved through using a well compensated silicon design together with ultra-low-power transistors instead of standard CMOS library components. In addition, the useful leakage signal has a spread spectrum with no characteristic peaks in frequency domain, thus making narrow band filtering useless.

It'll be interesting to see how Actel responds.

As for "ZOMG, the Chinese can infect all our nukes! RUN!" that seems unlikely. To perform this analysis, you need to be able to isolate the FPGA and its bitstream in a circuit where you can observe all the pieces functioning together. This is trivial in the "vendor A / customer B" scenario above. It's not so easy to do without a specimen of the system you're trying to hack, though.

It also raises the ancillary question: If my browser does precache/prerender a page, how does the website detect when I do actually visit it?

A tangentially related question: Has anyone gotten in trouble with violating their employer's Acceptable Use Policy due to browser preloading / precaching? Often, in search results or even certain news sites there are outbound links to places I'd never visit from work. But if Chrome (or even Firefox) is clicking those links behind my back, my IP address is in a corporate log somewhere as having "visited" that site, isn't it?

How are these preload/precache "hits" distinguished from normal hits? Obviously, if some of the sites are filtering these out, there's some way to tell them apart. At the same time, if the "hits" were noticeably different, there's always the chance the webserver would serve up different pages based on this difference.

There are those much more famous than I who would disagree with you. (Scroll down to "A Flame...") Of course, appeal-to-authority is not a great way to argue a point that should be settled by data.

Some workloads are amazingly pointer heavy. Compilers and interpreters are very pointer heavy, for example. At least one SPEC benchmark sped up by over 30% in early testing. Then again, a couple others slowed down, which seems odd. I imagine we'll just have to see what happens as the compilers get tuned and so forth.

If you don't like x32, don't enable it on your system. I don't think it should be written off so easily, though.

Yes, but so what? A system that supports x32 should also support x86-64. So, if you're relying on ASLR for security purposes, compile those sensitive apps as x86-64.

Granted, the potential attack surface grows as you consider larger and larger threats. For example, a GCC compiled as x32 makes a fair bit of sense. What about Open/Libre Office? Well, that depends on if you open untrusted documents that might try to exploit OOo / LO. (Odds seem pretty low, though.) And what about Firefox? Far less to trust on the web...

So, at some point, you have to make a tradeoff between the marginal benefit of increased performance/better memory footprint in x32 mode vs. increased security against certain overflow attacks that ASLR offers. For most people in most situations, the former likely wins for anything with a decent memory footprint. For people building hardened Internet-facing servers, the latter probably wins.

And it made no sense in the original headline (which appears to have been corrected). It originally read "DreamHammer's Wants To Corner the Drone OS Market."

The panda's eats, shoots and leaves.

Dreamhammer's what wants to corner the drone OS market? Don't leave me hanging here...

One fatal flaw in your exposition above: "-gate" wasn't used as a suffix adding onto something else in the case of "Watergate." The "Watergate scandal" was named after the Watergate hotel. It wasn't until sometime later someone decided to split apart Watergate and make "-gate" a suffix.

We should set RidiculouslyCleanPC (2637867) and LookAtThatCleanBooth (2637863) up on a date. Maybe they can spend some quality time cleaning each others... erm... PCs.

Mr. Plow, that's his name, his name again is Mr. Plow.

You realize that my settings have nothing to do with yours. I'm not Jonathan Corbet or anyone else associated with the site. I'm just another LWN subscriber.

But, since LWN added the comment filtering feature (that's what it's called in "My Account", at least -- go check it out), I imagine I'm not the only person who added Florian to the "filtered" list. (And I double checked, Florian is the only person in my filter set.) Enough people add Florian, and *poof*! No more oxygen for the flames.

Filtering doesn't completely hide the person. It just "folds" the threads that start at the filtered user's comment, so that they don't take up all the screen. You can still click to expand, not too much differently than here on Slashdot.

Actually, I have to admit, I'm on the first generation of the ribbon in 2007. I haven't upgraded to 2010 yet.

What I don't like about the ribbon is that there are many functions I used to use regularly that were always on screen. Now they're spread out across many different ribbon tabs, and sometimes where they ended up is non-intuitive for me. What used to be a simple click turns into an Easter egg hunt.

Perhaps if I used Office daily, I'd develop the appropriate muscle memory. But, I only use it a few times a month, and it's usually different apps -- this week it's Excel, next week it's PowerPoint.

I don't care if "zoom", "increase font size", "merge and center", and "fill with color" all belong on logically different tabs based on their function. For me, they all belong on the "I use this regularly" page.