[tor-bugs] #23295 [Core Tor/Tor]: Detect AES-NI hw encryption also if no cpu flags for AES-NI is present

[Tor Bug Tracker & Wiki]

#23295: Detect AES-NI hw encryption also if no cpu flags for AES-NI is present
--------------------------+----------------------------------
 Reporter:  naif          |          Owner:  (none)
     Type:  enhancement   |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by yawning):

 Replying to [comment:2 naif]:
 > Isn't possible to execute the AES-NI asm in a try/catch __asm__
 statement to evaluate if it's present or not?

 To add detail to what nickm said, when an illegal instruction is
 encountered, the CPU generates an interrupt (`Invalid Opcode - 0x06`).
 What happens then is OS dependent (because control is passed to the
 kernel's ISR), but on Linux this gets translated to a `SIGILL` in the
 responsible process.

 With that in mind, there's two ways to do what you want.

 The portable approach:

  * `fork()`
  * Exercise the AES-NI instructions (all of them, make sure it spits out
 coherent output) in the child.
  * If the child doesn't get killed AND the tests succeed, think about
 force enabling AES-NI support.

 The fancy approach (What nickm was alluding to):

  * `setjmp()`, if this returns `0`, it means we `longjmp()`ed from the
 `SIGILL` handler and can't use AES-NI.
  * Install a `SIGILL` handler that will `longjmp()`.
  * Exercise the AES-NI instructions (tests, etc etc etc).
  * If the tests succeed, then think about force enabling AES-NI support.

 From past experience, I don't think the portability situation for the
 signal handler based approach is horrific (and I've abused non-local gotos
 with signal handlers a decent amount), but there's no benefit to that
 approach over something `fork()` based.

 That said, personally I would be against doing either, and recommend
 `WONTFIX`ing this ticket.

 The correct way to test for CPU feature support on Intel systems is via
 `CPUID`.  If the environment is such that `CPUID` is misreporting it's
 capabilities, then the environment should be fixed.  Just because things
 happen to appear to work does not mean that features the CPU claims to not
 support should be enabled.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23295#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online