1. 29 8月, 2017 20 次提交
  2. 29 6月, 2017 2 次提交
    • M
      MIPS: math-emu: For MFHC1/MTHC1 also return SIGILL right away · 70f743d1
      Maciej W. Rozycki 提交于
      Update commit 1ac94400 ("MIPS: math-emu: Add mfhc1 & mthc1
      support.") and like done throughout `cop1Emulate' for other cases also
      for the MFHC1 and MTHC1 instructions return SIGILL right away rather
      than jumping to a single `return' statement.
      Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16401/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      70f743d1
    • M
      MIPS: math-emu: Prevent wrong ISA mode instruction emulation · 13769eba
      Maciej W. Rozycki 提交于
      Terminate FPU emulation immediately whenever an ISA mode switch has been
      observed.  This is so that we do not interpret machine code in the wrong
      mode, for example when a regular MIPS FPU instruction has been placed in
      a delay slot of a jump that switches into the MIPS16 mode, as with the
      following code (taken from a GCC test suite case):
      
      00400650 <set_fast_math>:
        400650:	3c020100 	lui	v0,0x100
        400654:	03e00008 	jr	ra
        400658:	44c2f800 	ctc1	v0,c1_fcsr
        40065c:	00000000 	nop
      
      [...]
      
      004012d0 <__libc_csu_init>:
        4012d0:	f000 6a02 	li	v0,2
        4012d4:	f150 0b1c 	la	v1,3f9430 <_DYNAMIC-0x6df0>
        4012d8:	f400 3240 	sll	v0,16
        4012dc:	e269      	addu	v0,v1
        4012de:	659a      	move	gp,v0
        4012e0:	f00c 64f6 	save	a0-a2,48,ra,s0-s1
        4012e4:	673c      	move	s1,gp
        4012e6:	f010 9978 	lw	v1,-32744(s1)
        4012ea:	d204      	sw	v0,16(sp)
        4012ec:	eb40      	jalr	v1
        4012ee:	653b      	move	t9,v1
        4012f0:	f010 997c 	lw	v1,-32740(s1)
        4012f4:	f030 9920 	lw	s1,-32736(s1)
        4012f8:	e32f      	subu	v1,s1
        4012fa:	326b      	sra	v0,v1,2
        4012fc:	d206      	sw	v0,24(sp)
        4012fe:	220c      	beqz	v0,401318 <__libc_csu_init+0x48>
        401300:	6800      	li	s0,0
        401302:	99e0      	lw	a3,0(s1)
        401304:	4801      	addiu	s0,1
        401306:	960e      	lw	a2,56(sp)
        401308:	4904      	addiu	s1,4
        40130a:	950d      	lw	a1,52(sp)
        40130c:	940c      	lw	a0,48(sp)
        40130e:	ef40      	jalr	a3
        401310:	653f      	move	t9,a3
        401312:	9206      	lw	v0,24(sp)
        401314:	ea0a      	cmp	v0,s0
        401316:	61f5      	btnez	401302 <__libc_csu_init+0x32>
        401318:	6476      	restore	48,ra,s0-s1
        40131a:	e8a0      	jrc	ra
      
      Here `set_fast_math' is called from `40130e' (`40130f' with the ISA bit)
      and emulation triggers for the CTC1 instruction.  As it is in a jump
      delay slot emulation continues from `401312' (`401313' with the ISA
      bit).  However we have no path to handle MIPS16 FPU code emulation,
      because there are no MIPS16 FPU instructions.  So the default emulation
      path is taken, interpreting a 32-bit word fetched by `get_user' from
      `401313' as a regular MIPS instruction, which is:
      
        401313:	f5ea0a92	sdc1	$f10,2706(t7)
      
      This makes the FPU emulator proceed with the supposed SDC1 instruction
      and consequently makes the program considered here terminate with
      SIGSEGV.
      
      A similar although less severe issue exists with pure-microMIPS
      processors in the case where similarly an FPU instruction is emulated in
      a delay slot of a register jump that (incorrectly) switches into the
      regular MIPS mode.  A subsequent instruction fetch from the jump's
      target is supposed to cause an Address Error exception, however instead
      we proceed with regular MIPS FPU emulation.
      
      For simplicity then, always terminate the emulation loop whenever a mode
      change is detected, denoted by an ISA mode bit flip.  As from commit
      377cb1b6 ("MIPS: Disable MIPS16/microMIPS crap for platforms not
      supporting these ASEs.") the result of `get_isa16_mode' can be hardcoded
      to 0, so we need to examine the ISA mode bit by hand.
      
      This complements commit 102cedc3 ("MIPS: microMIPS: Floating point
      support.") which added JALX decoding to FPU emulation.
      
      Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.")
      Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # 3.9+
      Patchwork: https://patchwork.linux-mips.org/patch/16393/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      13769eba
  3. 28 6月, 2017 1 次提交
  4. 10 4月, 2017 1 次提交
  5. 02 3月, 2017 2 次提交
  6. 25 12月, 2016 1 次提交
  7. 12 10月, 2016 1 次提交
  8. 25 9月, 2016 1 次提交
  9. 04 8月, 2016 1 次提交
    • M
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada 提交于
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  10. 02 8月, 2016 1 次提交
    • P
      MIPS: Use per-mm page to execute branch delay slot instructions · 432c6bac
      Paul Burton 提交于
      In some cases the kernel needs to execute an instruction from the delay
      slot of an emulated branch instruction. These cases include:
      
        - Emulated floating point branch instructions (bc1[ft]l?) for systems
          which don't include an FPU, or upon which the kernel is run with the
          "nofpu" parameter.
      
        - MIPSr6 systems running binaries targeting older revisions of the
          architecture, which may include branch instructions whose encodings
          are no longer valid in MIPSr6.
      
      Executing instructions from such delay slots is done by writing the
      instruction to memory followed by a trap, as part of an "emuframe", and
      executing it. This avoids the requirement of an emulator for the entire
      MIPS instruction set. Prior to this patch such emuframes are written to
      the user stack and executed from there.
      
      This patch moves FP branch delay emuframes off of the user stack and
      into a per-mm page. Allocating a page per-mm leaves userland with access
      to only what it had access to previously, and compared to other
      solutions is relatively simple.
      
      When a thread requires a delay slot emulation, it is allocated a frame.
      A thread may only have one frame allocated at any one time, since it may
      only ever be executing one instruction at any one time. In order to
      ensure that we can free up allocated frame later, its index is recorded
      in struct thread_struct. In the typical case, after executing the delay
      slot instruction we'll execute a break instruction with the BRK_MEMU
      code. This traps back to the kernel & leads to a call to do_dsemulret
      which frees the allocated frame & moves the user PC back to the
      instruction that would have executed following the emulated branch.
      In some cases the delay slot instruction may be invalid, such as a
      branch, or may trigger an exception. In these cases the BRK_MEMU break
      instruction will not be hit. In order to ensure that frames are freed
      this patch introduces dsemul_thread_cleanup() and calls it to free any
      allocated frame upon thread exit. If the instruction generated an
      exception & leads to a signal being delivered to the thread, or indeed
      if a signal simply happens to be delivered to the thread whilst it is
      executing from the struct emuframe, then we need to take care to exit
      the frame appropriately. This is done by either rolling back the user PC
      to the branch or advancing it to the continuation PC prior to signal
      delivery, using dsemul_thread_rollback(). If this were not done then a
      sigreturn would return to the struct emuframe, and if that frame had
      meanwhile been used in response to an emulated branch instruction within
      the signal handler then we would execute the wrong user code.
      
      Whilst a user could theoretically place something like a compact branch
      to self in a delay slot and cause their thread to become stuck in an
      infinite loop with the frame never being deallocated, this would:
      
        - Only affect the users single process.
      
        - Be architecturally invalid since there would be a branch in the
          delay slot, which is forbidden.
      
        - Be extremely unlikely to happen by mistake, and provide a program
          with no more ability to harm the system than a simple infinite loop
          would.
      
      If a thread requires a delay slot emulation & no frame is available to
      it (ie. the process has enough other threads that all frames are
      currently in use) then the thread joins a waitqueue. It will sleep until
      a frame is freed by another thread in the process.
      
      Since we now know whether a thread has an allocated frame due to our
      tracking of its index, the cookie field of struct emuframe is removed as
      we can be more certain whether we have a valid frame. Since a thread may
      only ever have a single frame at any given time, the epc field of struct
      emuframe is also removed & the PC to continue from is instead stored in
      struct thread_struct. Together these changes simplify & shrink struct
      emuframe somewhat, allowing twice as many frames to fit into the page
      allocated for them.
      
      The primary benefit of this patch is that we are now free to mark the
      user stack non-executable where that is possible.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13764/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      432c6bac
  11. 05 7月, 2016 2 次提交
  12. 28 5月, 2016 1 次提交
  13. 13 5月, 2016 6 次提交