cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c

[Kris Kennaway]

Colin Percival wrote:
> Kris Kennaway wrote:
>> Colin Percival wrote:
>>> To quote core@, whom I agree with on this point:
>>>   We think this decision should be revisited once at least one of the
>>>   following occur: new crypto code is made available by crypto vendors to
>>>   address cache-related attacks, or sufficient work is performed on
>>>   scheduling and protection mechanisms to prevent the attack from being
>>>   exploited.
>>>
>>> When I have time, I'm working on a cryptographic library ...
>> Sounds possibly infeasible and at the very least a long way off.  Is it
>> appropriate to continue to leave hyperthreading disabled for the
>> indefinite future pending the completion of a library you hope to one
>> day write?
> 
> You seem to be ignoring the second half of core's criteria for revisiting
> this decision: "or sufficient work is performed on scheduling and protection
> mechanisms to prevent the attack from being exploited".  This certainly
> seems to be the route which involves less work -- but since my expertise is
> in cryptography rather than schedulers, I can only work on the cryptographic
> option.
> 
> Colin Percival

On the contrary, my response is the same.  If you wanted to solve this 
problem by modifying the scheduler or developing a protection API you 
could have put some effort into solving it over the past 2 years, 
soliciting help from the community when you needed it.  It seems more 
likely to me that you have just lost interest in solving the problem, 
which leaves FreeBSD stuck in an indefinite wait state.

Do you have a concrete proposal for bringing this problem to a 
conclusion, other than hoping that either you will one day be motivated 
(financially or otherwise) to work on it yourself, or that someone else 
will step in and solve the problem instead?

Kris