Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
I'm not familiar with the security benefits of VT-d; might you have a link to a whitepaper or another resource?
This attack is relevant for password storage apps. As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example: https://github.com/andy-goryachev/PasswordSafe/blob/master/s... A symmetric key used to encrypt/decrypt RAM-based data is generated on the fly. There is a brief period in time when data is present in the clear in memory - when it's…
You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen Cache did something similar with No-Fill Mode. Tresor used CPU debug registers.
How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
I'm not familiar with the security benefits of VT-d; might you have a link to a whitepaper or another resource?
VT-d is an I/O MMU: it does address space translation for DMA. In a virtualization scenario it enables DMA between real peripherals and virtual machines. In a security context it means you can control which parts of memory a malicious peripheral can DMA to, instead of granting it access to the full physical address space. In a more general OS driver context, it means that you don't have to worry about reserving low memory addresses for doing DMA with devices that only support 32-bit addressing.
It's a shame that Intel only advertises VT-d as an enterprise-oriented virtualization feature and only offers it on a few models of consumer CPUs. They should have treated it like the NX bit and made it universal so that operating systems could rely on it. It's frankly disgusting that they are withholding an efficient hardware solution to an entire class of security problems, when they could make it available to almo…
Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.
Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d...
This means that previous *-K (multiplier-unlocked) models have VT-d disabled, right? So you have to choose between overclocking and VT-d.
Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
Well, I doubt Intel sees it as a security feature first and foremost. But even if they did, they don't have an obligation to be "responsible" in how they market their features. Many of their pricing choices ultimately end up being related to yield. If they need to devote more transistors in order to enable an IOMMU, seems like it makes sense to charge more for it.
This attack is relevant for password storage apps. As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example: https://github.com/andy-goryachev/PasswordSafe/blob/master/s... A symmetric key used to encrypt/decrypt RAM-based data is generated on the fly. There is a brief period in time when data is present in the clear in memory - when it's…
You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen Cache did something similar with No-Fill Mode. Tresor used CPU debug registers.
There are cases when not only key material but also some data need to be protected.
For example, in a context of password storage app, the passwords and associated text should not remain in the clear in memory, and possibly even the character buffer of entry fields such as JPasswordField.
This is the reason for the MemCrypt code mentioned earlier.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
Well, I doubt Intel sees it as a security feature first and foremost. But even if they did, they don't have an obligation to be "responsible" in how they market their features. Many of their pricing choices ultimately end up being related to yield. If they need to devote more transistors in order to enable an IOMMU, seems like it makes sense to charge more for it.
Core count, clock speed, and cache quantity are related to yield. HyperThreading, VT-d, AVX, Turbo Boost, AES-NI, TSX, and ECC are all too integral to the core design; they're physically present on all chips and it is extremely unlikely for a manufacturing defect to affect one of those features without otherwise crippling the chip. Those features are used for product segmentation that is not driven by any real marginal cost.
Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.
Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d... This means that previous *-K (multiplier-unlocked) models have VT-d disabled, right? So you have to choose between overclocking and VT-d.
Yes, although prior to Haswell it was still possible to do a moderate amount of overclocking on the non-K models that do have VT-d; the multiplier could be increased by about the same margin as the Turbo Boost feature uses, and you still got Turbo on top of that. Haswell marked a shift from a limited-unlocked multiplier to a fully-locked multiplier for the non-K parts.