Mentions légales du service

Skip to content
Snippets Groups Projects
  1. May 15, 2020
  2. Apr 28, 2020
  3. Apr 27, 2020
    • Kévin Le Gouguec's avatar
      Properly kill & wait simulators and GDB servers · fac2d4e7
      Kévin Le Gouguec authored
      kill -PIPE seems to make simulators and servers exit with an error
      code; those programs seem to handle SIGINT more gracefully.
      
      Couldn't test on nRF52840 nor STM32L053.
      fac2d4e7
    • Kévin Le Gouguec's avatar
      Fix cold-cache issue with RAM measurement on PC · 34478a77
      Kévin Le Gouguec authored
      My machine has a "spinning rust" disk; cipher_ram.sh would
      consistently fail
      - the first time it was run,
      - right after dropping caches (echo 3 > /proc/sys/vm/drop_caches).
      
      Instead of running "sleep 1" and hoping for the best, run GDB in the
      foreground.
      
      The -tty switch is needed to prevent a weird interaction with the
      timeout(1) command[1].  Another way to side-step the issue would be to
      give --foreground to timeout(1); however "in this mode, children of
      COMMAND will not be timed out".  I don't know if that's a problem
      (empirically it seems not); I figure fixing this locally is better
      than risking side-effects.
      
      [1]: https://notmuchmail.org/pipermail/notmuch/2019/028017.html
      34478a77
  4. Apr 23, 2020
  5. Apr 22, 2020
  6. Apr 21, 2020
  7. Apr 20, 2020
  8. Apr 16, 2020
    • Kévin Le Gouguec's avatar
      Adapt unroll pragmas to GCC · 0be3b9ea
      Kévin Le Gouguec authored
      This will only work with GCC 8.  For older version of GCC, we'd need
      to push/pop a #pragma optimize("unroll-loops") around the loop, and we
      could not control the unrolling factor.
      
      Since the FELICS-AE container uses Ubuntu 18.04 where gcc ≡ gcc-7,
      this won't actually pay off for now, but from some quick testing the
      gains are not obvious anyway.
      
      GCC 7 (no support for #pragma unroll) vs GCC 8 after this change:
      
      AES-128-GCM (vaes-ni with -O3)
          code_size: -8.75% (9176 :arrow_lower_right: 8373)
          code_ram: -15.38% (1144 :arrow_lower_right: 968)
          code_time: +5.22% (1380 :arrow_upper_right: 1452)
      
      AES-128-GCM (vaes-ni with -Os)
          code_size: +20.75% (4240 :arrow_upper_right: 5120)
          code_ram: +17.78% (720 :arrow_upper_right: 848)
          code_time: -3.18% (1508 :arrow_lower_right: 1460)
      
      The metrics look sort of backward for -O3: I'd expect increased code
      size (because instructions are duplicated) and decreased execution
      time (because the loop logic goes away).  I don't have an explanation.
      0be3b9ea
    • Kévin Le Gouguec's avatar
      Add necessary target attributes for AES-GCM vaes-ni · 1a29f6b2
      Kévin Le Gouguec authored
      Could also pass them as -m flags to gcc, but I figure it's better to
      keep algorithm-specific stuff away from compiler flags to avoid
      side-effects on other algorithms.
      1a29f6b2
    • Kévin Le Gouguec's avatar
      Split AES-GCM vaes-ni files according to FELICS conventions · b1986375
      Kévin Le Gouguec authored
      Probably not the most efficient split, since lots of code will be
      duplicated for encryption and decryption.  This is just to have
      something working before iterating on it.
      b1986375
    • Kévin Le Gouguec's avatar
      Add AES-GCM implementation based on AES-NI x86 extension · b5f1daf5
      Kévin Le Gouguec authored
      Not FELICS-compliant as-is.
      b5f1daf5
    • Kévin Le Gouguec's avatar
      Make mspdebug provide hardware multiplier · 307eabd5
      Kévin Le Gouguec authored
      Which is a much more satisfying fix than -mhwmult=none.
      
      AES-128-GCM (vref with -Os)
          code_time: -0.06% (20051549 :arrow_lower_right: 20038829)
      
      Take care of the pennies, as they say.
      307eabd5
    • Kévin Le Gouguec's avatar
      Work around compiler calling hardware functions on MSP430 · 8945f9a2
      Kévin Le Gouguec authored
      When compiling AES-128-GCM_vref with anything other than -O3 (-Os for
      example), gcc attempts to use __mspabi_mpyul_hw, the MSP430's hardware
      multiply, which seems to not work when simulated under mspdebug.
      
      Quoth man gcc:
      
      > Hardware multiplies are normally performed by calling a library
      > routine.  This saves space in the generated code.  When compiling at
      > -O3 or higher however the hardware multiplier is invoked inline.
      > This makes for bigger, but faster code.
      
      Not sure this commit is the most elegant solution; it seems not to
      have any performance impact (negative or otherwise) on AES-GCM at -O3,
      nor on ACORN/Ascon/Lilliput-AE at -O3 and -Os.
      
      If I understand correctly, this commit will mainly result in subpar
      memory performance with -Os, since some instructions will be wasted
      re-implementing __mspabi_mpyul_hw.
      8945f9a2
  9. Apr 15, 2020
    • Kévin Le Gouguec's avatar
      Remove invalid command line option for JLinkGDBServer · 0615644d
      Kévin Le Gouguec authored
      For as long as I've used FELICS, I've seen the program throw
      
      > WARNING: Unknown command line parameter -USB found.
      
      /opt/SEGGER/JLink_V670b/Doc/Manuals/UM08001_JLink.pdf says that "-USB"
      is a valid parameter for JLinkSWOViewer, JLinkSTR91x, JFlashSPI; with
      JLinkGDBServer it's probably "-select USB"?
      
      I'll just remove "-USB" and see if I get away with it, since it Works
      On My Machine™.
      0615644d
  10. Apr 14, 2020
Loading