Skip to content
  1. Feb 17, 2017
  2. Feb 15, 2017
  3. Feb 14, 2017
  4. Feb 12, 2017
    • Claggy3's avatar
      Update vfpmodule.c · fb50a274
      Claggy3 authored
      Christopher Alexander Tobias Schulze - May 2, 2015, 11:57 a.m.
      This patch fixes a problem with VFP state save and restore related
      to exception handling (panic with message "BUG: unsupported FP
      instruction in kernel mode") present on VFP11 floating point units
      (as used with ARM1176JZF-S CPUs, e.g. on first generation Raspberry
      Pi boards). This patch was developed and discussed on
      
         https://github.com/raspberrypi/linux/issues/859
      
      
      
      A precondition to see the crashes is that floating point exception
      traps are enabled. In this case, the VFP11 might determine that a FPU
      operation needs to trap at a point in time when it is not possible to
      signal this to the ARM11 core any more. The VFP11 will then set the
      FPEXC.EX bit and store the trapped opcode in FPINST. (In some cases,
      a second opcode might have been accepted by the VFP11 before the
      exception was detected and could be reported to the ARM11 - in this
      case, the VFP11 also sets FPEXC.FP2V and stores the second opcode in
      FPINST2.)
      
      If FPEXC.EX is set, the VFP11 will "bounce" the next FPU opcode issued
      by the ARM11 CPU, which will be seen by the ARM11 as an undefined opcode
      trap. The VFP support code examines the FPEXC.EX and FPEXC.FP2V bits
      to decide what actions to take, i.e., whether to emulate the opcodes
      found in FPINST and FPINST2, and whether to retry the bounced instruction.
      
      If a user space application has left the VFP11 in this "pending trap"
      state, the next FPU opcode issued to the VFP11 might actually be the
      VSTMIA operation vfp_save_state() uses to store the FPU registers
      to memory (in our test cases, when building the signal stack frame).
      In this case, the kernel crashes as described above.
      
      This patch fixes the problem by making sure that vfp_save_state() is
      always entered with FPEXC.EX cleared. (The current value of FPEXC has
      already been saved, so this does not corrupt the context. Clearing
      FPEXC.EX has no effects on FPINST or FPINST2. Also note that many
      callers already modify FPEXC by setting FPEXC.EN before invoking
      vfp_save_state().)
      
      This patch also addresses a second problem related to FPEXC.EX: After
      returning from signal handling, the kernel reloads the VFP context
      from the user mode stack. However, the current code explicitly clears
      both FPEXC.EX and FPEXC.FP2V during reload. As VFP11 requires these
      bits to be preserved, this patch disables clearing them for VFP
      implementations belonging to architecture 1. There should be no
      negative side effects: the user can set both bits by executing FPU
      opcodes anyway, and while user code may now place arbitrary values
      into FPINST and FPINST2 (e.g., non-VFP ARM opcodes) the VFP support
      code knows which instructions can be emulated, and rejects other
      opcodes with "unhandled bounce" messages, so there should be no
      security impact from allowing reloading FPEXC.EX and FPEXC.FP2V.
      
      Signed-off-by: default avatarChristopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
      fb50a274
  5. Feb 10, 2017
  6. Feb 09, 2017