Skip to content
  1. Feb 11, 2016
    • Daniel Wagner's avatar
      mips: Differentiate between 32 and 64 bit ELF header · f4d3d504
      Daniel Wagner authored 
      

Depending on the configuration either the 32 or 64 bit version of
elf_check_arch() is defined. parse_crash_elf{32|64}_headers() does
some basic verification of the ELF header via
vmcore_elf{32|64}_check_arch() which happen to map to elf_check_arch().
Since the implementation 32 and 64 bit version of elf_check_arch()
differ, we use the wrong type:

   In file included from include/linux/elf.h:4:0,
                    from fs/proc/vmcore.c:13:
   fs/proc/vmcore.c: In function 'parse_crash_elf64_headers':
>> arch/mips/include/asm/elf.h:228:23: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     struct elfhdr *__h = (hdr);     \
                          ^
   include/linux/crash_dump.h:41:37: note: in expansion of macro 'elf_check_arch'
    #define vmcore_elf64_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
                                        ^
   fs/proc/vmcore.c:1015:4: note: in expansion of macro 'vmcore_elf64_check_arch'
      !vmcore_elf64_check_arch(&ehdr) ||
       ^

Therefore, we rather define vmcore_elf{32|64}_check_arch() as a
basic machine check and use it also in binfm_elf?32.c as well.

Signed-off-by: default avatarDaniel Wagner <daniel.wagner@bmw-carit.de>
Suggested-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Reviewed-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12529/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f4d3d504
  3. Feb 10, 2016
  5. Feb 09, 2016
    • Paul Burton's avatar
      MIPS: Fix early CM probing · 3af5a67c
      Paul Burton authored 
      

Commit c014d164 ("MIPS: Add platform callback before initializing
the L2 cache") added a platform_early_l2_init function in order to allow
platforms to probe for the CM before L2 initialisation is performed, so
that CM GCRs are available to mips_sc_probe.

That commit actually fails to do anything useful, since it checks
mips_cm_revision to determine whether it should call mips_cm_probe but
the result of mips_cm_revision will always be 0 until mips_cm_probe has
been called. Thus the "early" mips_cm_probe call never occurs.

Fix this & drop the useless weak platform_early_l2_init function by
simply calling mips_cm_probe from setup_arch. For platforms that don't
select CONFIG_MIPS_CM this will be a no-op, and for those that do it
removes the requirement for them to call mips_cm_probe manually
(although doing so isn't harmful for now).

Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
Reviewed-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Jaedon Shin <jaedon.shin@gmail.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12475/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      3af5a67c
  7. Feb 05, 2016
    • Ralf Baechle's avatar
      MIPS: Wire up copy_file_range syscall. · e6c058f9
      Ralf Baechle authored 
      

Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e6c058f9
    • Mark Brown's avatar
      regmap: mmio: Revert to v4.4 endianness handling · 320549a2
      Mark Brown authored 
      

Commit 29bb45f2 (regmap-mmio: Use native endianness for read/write)
attempted to fix some long standing bugs in the MMIO implementation for
big endian systems caused by duplicate byte swapping in both regmap and
readl()/writel() which affected MIPS systems as when they are in big
endian mode they flip the endianness of all registers in the system, not
just the CPU.  MIPS systems had worked around this by declaring regmap
using IPs as little endian which is inaccurate, unfortunately the issue
had not been reported.

Sadly the fix makes things worse rather than better.  By changing the
behaviour to match the documentation it caused behaviour changes for
other IPs which broke them and by using the __raw I/O accessors to avoid
the endianness swapping in readl()/writel() it removed some memory
ordering guarantees and could potentially generate unvirtualisable
instructions on some architectures.

Unfortunately sorting out all this mess in any half way sensible fashion
was far too invasive to go in during an -rc cycle so instead let's go
back to the old broken behaviour for v4.5, the better fixes are already
queued for v4.6.  This does mean that we keep the broken MIPS DTs for
another release but that seems the least bad way of handling the
situation.

Reported-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      320549a2
  9. Feb 04, 2016
  11. Feb 03, 2016
  13. Feb 02, 2016
    • Maciej W. Rozycki's avatar
      MIPS: traps.c: Correct microMIPS RDHWR emulation · 7aa70471
      Maciej W. Rozycki authored 
      

Fix the code to fetch and decode the whole 32-bit instruction.  This
only really matters with the `noulri' kernel parameter as all microMIPS
processors are supposed to have all the hardware registers we support.

Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12281/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      7aa70471
    • Maciej W. Rozycki's avatar
      MIPS: traps.c: Don't emulate RDHWR in the CpU #0 exception handler · 10f6d99f
      Maciej W. Rozycki authored 
      

In the regular MIPS instruction set RDHWR is encoded with the SPECIAL3
(011111) major opcode.  Therefore it cannot trigger the CpU (Coprocessor
Unusable) exception, and certainly not for coprocessor 0, as the opcode
does not overlap with any of the older ISA reservations, i.e. LWC0
(110000), SWC0 (111000), LDC0 (110100) or SDC0 (111100).  The closest
match might be SDC3 (111111), possibly causing a CpU #3 exception,
however our code does not handle it anyway.  A quick check with a MIPS I
and a MIPS III processor:

CPU0 revision is: 00000220 (R3000)
CPU0 revision is: 00000440 (R4400SC)

indeed indicates that the RI (Reserved Instruction) exception is
triggered.  It's only LL and SC that require emulation in the CpU #0
exception handler as they reuse the LWC0 and SWC0 opcodes respectively.

In the microMIPS instruction set RDHWR is mandatory and triggering the
RI exception is required on unimplemented or disabled register accesses.
Therefore emulating the microMIPS instruction in the CpU #0 exception
handler is not required either.

Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12280/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      10f6d99f
  15. Feb 01, 2016
    • James Hogan's avatar
      MIPS: Fix FPU disable with preemption · 00fe56dc
      James Hogan authored 
      

The FPU should not be left enabled after a task context switch. This
isn't usually a problem as the FPU enable bit is updated before
returning to userland, however it can potentially mask kernel bugs, and
in fact KVM assumes it won't happen and won't clear the FPU enable bit
before returning to the guest, which allows the guest to use stale FPU
context.

Interrupts and exceptions save and restore most bits of the CP0 Status
register which contains the FPU enable bit (CU1). When the kernel needs
to enable or disable the FPU (for example due to attempted FPU use by
userland, or the scheduler being invoked) both the actual Status
register and the saved value in the userland context are updated.

However this doesn't work correctly with full kernel preemption enabled,
since the FPU enable bit can be cleared from within an interrupt when
the scheduler is invoked, and only the userland context is updated, not
the interrupt context.

For example:
1) Enter kernel with FPU already enabled, TIF_USEDFPU=1, Status.CU1=1
   saved.
2) Take a timer interrupt while in kernel mode, Status.CU1=1 saved.
3) Timer interrupt invokes scheduler to preempt the task, which clears
   TIF_USEDFPU, disables the FPU in Status register (Status.CU1=0), and
   the value stored in user context from step (1), but not the interrupt
   context from step (2).
4) When the process is scheduled back in again Status.CU1=0.
5) The interrupt context from step (2) is restored, which sets
   Status.CU1=1. So from user context point of view, preemption has
   re-enabled FPU!
6) If the scheduler is invoked again (via preemption or voluntarily)
   before returning to userland, TIF_USEDFPU=0 so the FPU is not
   disabled before the task context switch.
7) The next task resumes from the context switch with FPU enabled!

The restoring of the Status register on return from interrupt/exception
is already selective about which bits to restore, leaving the interrupt
mask bits alone so enabling/disabling of CPU interrupt lines can
persist. Extend this to also leave both the CU1 bit (FPU enable) and the
FR bit (which specifies the FPU mode and gets changed with CU1). This
prevents a stale Status value being restored in step (5) above and
persisting through subsequent context switches.

Also switch to the use of definitions from asm/mipsregs.h while we're at
it.

Since this change also affects the restoration of Status register on the
path back to userland, it increases the sensitivity of the kernel to the
problem of the FPU being left enabled, allowing it to propagate to
userland, therefore a warning is also added to lose_fpu_inatomic() to
point out any future reoccurances before they do any damage.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Reviewed-by: default avatarPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12303/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      00fe56dc
    • James Hogan's avatar
      MIPS: Properly disable FPU in start_thread() · 76e5846d
      James Hogan authored 
      

start_thread() (called for execve(2)) clears the TIF_USEDFPU flag
without atomically disabling the FPU. With a preemptive kernel, an
unfortunately timed preemption after this could result in another
task (or KVM guest) being scheduled in with the FPU still enabled, since
lose_fpu_inatomic() only turns it off if TIF_USEDFPU is set.

Use lose_fpu(0) instead of the separate FPU / MSA management, which
should do the right thing (drop FPU properly and atomically without
saving state) and will be more future proof.

Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Reviewed-by: default avatarPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12302/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      76e5846d
    • James Hogan's avatar
      MIPS: Fix buffer overflow in syscall_get_arguments() · f4dce1ff
      James Hogan authored 
      

Since commit 4c21b8fd ("MIPS: seccomp: Handle indirect system calls
(o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
arguments by incrementing both the start argument number and the number
of arguments to fetch. However only the start argument number needs to
be incremented. The number of arguments does not change, they're just
shifted up by one, and in fact the output array is provided by the
caller and is likely only n entries long, so reading more arguments
overflows the output buffer.

In the case of seccomp, this results in it fetching 7 arguments starting
at the 2nd one, which overflows the unsigned long args[6] in
populate_seccomp_data(). This clobbers the $s0 register from
syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
stack, into which syscall_trace_enter() had placed its syscall number
argument. This caused Chromium to crash.

Credit goes to Milko for tracking it down as far as $s0 being clobbered.

Fixes: 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)")
Reported-by: default avatarMilko Leporis <milko.leporis@imgtec.com>
Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.15-
Patchwork: https://patchwork.linux-mips.org/patch/12213/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f4dce1ff
  17. Jan 27, 2016
  19. Jan 24, 2016