Date: Sun, 15 May 2005 13:13:56 -0700 From: Nate Lawson <nate@root.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Colin Percival <cperciva@freebsd.org> Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.csrc/sys/amd64/include cpufunc.h src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h Message-ID: <4287AD84.6070600@root.org> In-Reply-To: <97079.1116154766@critter.freebsd.dk> References: <97079.1116154766@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <4286E6A5.4030902@freebsd.org>, Colin Percival writes: > >>Nate Lawson wrote: >> >>>That is at best, hyperbole. >> >>Have you been talking to Intel lately? >> >> >>> Crypto implementations which properly >>>implement blinding or operate in constant time are not vulnerable. >> >>Crypto implementations which implement blinding are vulnerable. > > > This is not just about crypto. > > There are many processes which a random process should not be allowed > to spy on in a multiuser system. > > Your boss text-procssing or email program for one thing. Every general-purpose machine has measurable timing side channels. The question is merely one of bandwidth. I can time your boss's keystrokes using a loop on an SMP system that runs "ps -l" looking for "ttywait" and get a rough measurement. With enough samples, I can regenerate what he typed. This attack against SSH-encrypted sessions has been shown to be effective. My point was that FreeBSD (like most general-purpose OS) has many timing channels that are comparably as effective for an attacker as HTT. Disabling HTT does not significantly reduce an attacker's likelihood of success since they can just use another timing channel. However, it does disable a useful feature. Are we going to disable SMP next? As Colin wrote in his paper, identifying, analyzing, and characterizing the bandwidth of all possible side channels in a system is a very difficult task. There is no way to know whether or not disabling a given feature reduces the probability of a successful attack without doing this analysis. On the other hand, the loss of functionality is quite certain. Given that FreeBSD is a general-purpose OS, we need to limit timing channels the best we can while maintaining the widest possible feature support. Since we can't completely eliminate timing channels, the best hope is for applications that handle secrets to do so in a data-independent way. None of this is easy. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4287AD84.6070600>