Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment IOMMU (Score 4, Informative) 125

Yes, when I saw this I thought that this was a reason to make motherboard IOMMUs a security feature. Also, the DMA destination memory pages should not have the executable bit turned on. Recent generations of Intel/AMD CPUs have provided the ability to turn that bit off.

Comment Agreed on the activists (Score 2, Insightful) 380

They killed the goose that layed the golden eggs.

The uber-green and anti-nuke activists likely don't live there, and probably consider these folks collateral damage in their larger fight. Ideally, such activists would be up-front about the economic costs of some of their stands. Even beyond this now-impoverished small town, growing economies need affordable energy; that's just an economic fact. High energy costs reverberate through the entire supply chain, and raise the costs of virtually every good-and-service that normal people use.

Everybody wants clean air and water, but some green initiatives come with a serious price-tag.

Comment Re:They didn't release enough phones, IMO.... (Score 1) 348

Good point. And, for my money, I prefer Apple's approach to Android's. We may get to the point where screens are high enough resolution I don't care about pixel accuracy, but we're not there quite yet.

Isn't it cool that there are several competing options in the market? I think that's a win, don't you?

Comment Information leakage attacks most likely vector (Score 2) 607

I don't think the NSA has to break actual keys brute-force, but with information leakage it has been shown that data can be sussed-out of an encrypted stream (particularly an interactive one). Given sufficient leakage of known quantities, keys can be broken in much less time.

As we've seen just recently, even something as innocuous as HTTP compression over a SSL link can result in serious information leakage by anyone monitoring the size of the payloads.

Encryption streams, in general, require additional random data to be inserted into the stream and for the salt to be continuously modified (i.e. feedback) to remain strong. If one does neither of those things than the information leakage increases to the point where the keys can be broken without spending years of cpu cycles.

-Matt

Comment Re:Does it support TSX? (Score 1) 180

I don't think you actually bothered to read and understand what I wrote. Try again. This time read my responses (or at least the first two) a bit more carefully.

I'm not in the least saying that transactional hardware support is bad. I am saying that programming to Intel's transactional interface FIRST, as your primary programming model, particularly for consumer applications, can lead to very undesirable results on hardware that doesn't support it.

Intel tends to implement first-run features with very weird restrictions and other goo that only leads to trouble down the line. Their HVM stuff being a really good case in point (AMD's is much, much cleaner, too bad AMD dropped off the performance curve a few years ago). There are plenty of other examples as well. There are very severe limitations to what Intel's (now TWO) transactional models can handle. Programming specifically to those interfaces is akin to the people who would hand-code assembly years ago for a 15% improvement over C and think it was good (hint: all that code was thrown out the window soon after).

Right now only very short locked code sections can operate reasonably under Intel's current transactional model. It just so happens that the most prevalent use of spin locks in modern architectures is with short locked code sections. Longer locked code sections do not typically use spin locks. So a reasonable first approximation of any implementation of Intel's model is going to be as a way to boost spin locks.

In a well written SMP application or kernel there are not actually very many places where conflicts create performance issues. In either Linux or DragonFly I can only think of two places: (1) Concurrent file descriptor access from a threaded program, and (2) Concurrent VM faults from a threaded program to the same memory location(s) (same underlying VM objects and same underlying page table page). And that's pretty much it. For applications it will depend on the application of course, I'm not completely dismissing it. I LIKE the concept. I DON'T LIKE the severe limitations imposed by Intel's model. It's that simple.

-Matt

Comment Re:Does it support TSX? (Score 1) 180

Not to put too fine a point on it, but I've written hundreds of thousands of lines of SMP code on modern systems (and, frankly, I was doing SMP code with paired 8-bit CPUs over 28 years ago), so if you think you are somehow stating something in regards to my knowledge base, I would humbly suggest that you take your opinions and shove them down a toilet somewhere because you clearly have no clue whatsoever as to what I've been doing the last 20 years.

-Matt

Slashdot Top Deals

Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy.

Working...