Messages in this thread | | | Date | Sun, 15 May 2005 16:21:36 +0200 (CEST) | From | Mikulas Patocka <> | Subject | Re: Hyper-Threading Vulnerability |
| |
On Sun, 15 May 2005, Andi Kleen wrote:
> On Sun, May 15, 2005 at 03:51:05PM +0200, Mikulas Patocka wrote: > > > > > > On Sun, 15 May 2005, Andi Kleen wrote: > > > > > On Fri, May 13, 2005 at 09:16:09PM +0200, Diego Calleja wrote: > > > > El Fri, 13 May 2005 20:03:58 +0200, > > > > Andi Kleen <ak@muc.de> escribi?: > > > > > > > > > > > > > This is not a kernel problem, but a user space problem. The fix > > > > > is to change the user space crypto code to need the same number of cache line > > > > > accesses on all keys. > > > > > > > > > > > > However they've patched the FreeBSD kernel to "workaround?" it: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch > > > > > > That's a similar stupid idea as they did with the disk write > > > cache (lowering the MTBFs of their disks by considerable factors, > > > which is much worse than the power off data loss problem) > > > Let's not go down this path please. > > > > What wrong did they do with disk write cache? > > They turned it off by default, which according to disk vendors > lowers the MTBF of your disk to a fraction of the original value. > > I bet the total amount of valuable data lost for FreeBSD users because > of broken disks is much much bigger than what they gained from not losing > in the rather hard to hit power off cases. > > -Andi
BTW. Is there any blacklist of disks with broken FLUSH CACHE command? Or a list of companies that cheat in implementation of it?
Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |