Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/arch/x86/x86





On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote:
> Even if you don't have the ability to change the defective hardware?

The hardware is not defective. We are not talking about variable timing
for basic arithmetic operations based on the operand value. Outside
maybe division, that could be considered a hardware bug. A believe
that timing of complex operations like memory access should be constant
is IMO completely misguided for general purpose computing. Outside a
very narrow range of hardware, it is absurd to even consider it.

On other processors, the issues are needing to do timing attacks due to flaws in the hardware. For x86, no such bugs are known. History suggests it is unwise to take the absence of evidence to be evidence of absence....

> Why should I provide an attacker a stop watch? I want him/her to build
> their own that has the potential to be accurate enough, but is necessarily
> less accurate than the one I'm denying them access to.

It has been said before: this is breaking completely valid use cases
without actually fixing anything. It is security by obscurity at its
best.

I'm not advocating turning it off by default. I'm saying that it would be useful to allow removal of access to the counter as a mitigation technique, perhaps while waiting for a more general / complete fix for a kernel bug to be available.

Warner


Home | Main Index | Thread Index | Old Index