Skip to content

L
linux
Switch branch/tag
  1. 18 Mar, 2022 1 commit
  3. 14 Mar, 2022 8 commits
  5. 07 Mar, 2022 6 commits
    • Xi Ruoyao's avatar
      mips: remove reference to "newer Loongson-3" · 3f059a7e
      Xi Ruoyao authored 
      Newest Loongson-3 processors have moved to use LoongArch architecture.
Sadly, the LL/SC issue is still existing on both latest Loongson-3
processors using MIPS64 (Loongson-3A4000) and LoongArch
(Loongson-3A5000).

As it's very unlikely there will be new Loongson-3 processors using
MIPS64, let's stop people from false hoping.
Signed-off-by: default avatarXi Ruoyao <xry111@mengyan1223.wang>
Cc: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      3f059a7e
    • Paul Cercueil's avatar
      mips: Always permit to build u-boot images · 34275ac2
      Paul Cercueil authored 
      The platforms where the kernel should be loaded above 0x8000.0000 do not
support loading u-boot images, that doesn't mean that we shouldn't be
able to generate them.

Additionally, since commit 79876cc1 ("MIPS: new Kconfig option
ZBOOT_LOAD_ADDRESS"), the $(zload-y) variable was no longer hardcoded,
which made it impossible to use the uzImage.bin target.

Fixes: 79876cc1 ("MIPS: new Kconfig option ZBOOT_LOAD_ADDRESS")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      34275ac2
    • Maciej W. Rozycki's avatar
      MIPS: Sanitise Cavium switch cases in TLB handler synthesizers · 6ddcba9d
      Maciej W. Rozycki authored 
      It makes no sense to fall through to `break'.  Therefore reorder the
switch statements so as to have the Cavium cases first, followed by the
default case, which improves readability and pacifies code analysis
tools.  No change in semantics, assembly produced is exactly the same.
Reported-by: default avatarkernel test robot <lkp@intel.com>
Signed-off-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
Fixes: bc431d21 ("MIPS: Fix fall-through warnings for Clang")
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      6ddcba9d
    • Maciej W. Rozycki's avatar
      DEC: Limit PMAX memory probing to R3k systems · 244eae91
      Maciej W. Rozycki authored 
      Recent tightening of the opcode table in binutils so as to consistently
disallow the assembly or disassembly of CP0 instructions not supported
by the processor architecture chosen has caused a regression like below:

arch/mips/dec/prom/locore.S: Assembler messages:
arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe'

in a piece of code used to probe for memory with PMAX DECstation models,
which have non-REX firmware.  Those computers always have an R2000 CPU
and consequently the exception handler used in memory probing uses the
RFE instruction, which those processors use.

While adding 64-bit support this code was correctly excluded for 64-bit
configurations, however it should have also been excluded for irrelevant
32-bit configurations.  Do this now then, and only enable PMAX memory
probing for R3k systems.
Reported-by: default avatarJan-Benedict Glaw <jbglaw@lug-owl.de>
Reported-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org # v2.6.12+
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      244eae91
    • Randy Dunlap's avatar
      mips: DEC: honor CONFIG_MIPS_FP_SUPPORT=n · 97bf0395
      Randy Dunlap authored 
      Include the DECstation interrupt handler in opting out of
FPU support.

Fixes a linker error:

mips-linux-ld: arch/mips/dec/int-handler.o: in function `fpu':
(.text+0x148): undefined reference to `handle_fpe_int'

Fixes: 183b40f9 ("MIPS: Allow FP support to be disabled")
Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Reported-by: default avatarkernel test robot <lkp@intel.com>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Maciej W. Rozycki <macro@orcam.me.uk>
Cc: linux-mips@vger.kernel.org
Acked-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      97bf0395
    • Alexander Lobakin's avatar
      MIPS: fix fortify panic when copying asm exception handlers · d17b6641
      Alexander Lobakin authored 
      With KCFLAGS="-O3", I was able to trigger a fortify-source
memcpy() overflow panic on set_vi_srs_handler().
Although O3 level is not supported in the mainline, under some
conditions that may've happened with any optimization settings,
it's just a matter of inlining luck. The panic itself is correct,
more precisely, 50/50 false-positive and not at the same time.
From the one side, no real overflow happens. Exception handler
defined in asm just gets copied to some reserved places in the
memory.
But the reason behind is that C code refers to that exception
handler declares it as `char`, i.e. something of 1 byte length.
It's obvious that the asm function itself is way more than 1 byte,
so fortify logics thought we are going to past the symbol declared.
The standard way to refer to asm symbols from C code which is not
supposed to be called from C is to declare them as
`extern const u8[]`. This is fully correct from any point of view,
as any code itself is just a bunch of bytes (including 0 as it is
for syms like _stext/_etext/etc.), and the exact size is not known
at the moment of compilation.
Adjust the type of the except_vec_vi_*() and related variables.
Make set_handler() take `const` as a second argument to avoid
cast-away warnings and give a little more room for optimization.
Signed-off-by: default avatarAlexander Lobakin <alobakin@pm.me>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      d17b6641
  7. 01 Mar, 2022 3 commits
  9. 23 Feb, 2022 1 commit
    • Kees Cook's avatar
      MIPS: Modernize READ_IMPLIES_EXEC · fbb1d4b3
      Kees Cook authored 
      I'm doing some thread necromancy of
https://lore.kernel.org/lkml/202007081624.82FA0CC1EA@keescook/

x86, arm64, and arm32 adjusted their READ_IMPLIES_EXEC logic to better
align with the safer defaults and the interactions with other mappings,
which I illustrated with this comment on x86:

/*
 * An executable for which elf_read_implies_exec() returns TRUE will
 * have the READ_IMPLIES_EXEC personality flag set automatically.
 *
 * The decision process for determining the results are:
 *
 *                 CPU: | lacks NX*  | has NX, ia32     | has NX, x86_64 |
 * ELF:                 |            |                  |                |
 * ---------------------|------------|------------------|----------------|
 * missing PT_GNU_STACK | exec-all   | exec-all         | exec-none      |
 * PT_GNU_STACK == RWX  | exec-stack | exec-stack       | exec-stack     |
 * PT_GNU_STACK == RW   | exec-none  | exec-none        | exec-none      |
 *
 *  exec-all  : all PROT_READ user mappings are executable, except when
 *              backed by files on a noexec-filesystem.
 *  exec-none : only PROT_EXEC user mappings are executable.
 *  exec-stack: only the stack and PROT_EXEC user mappings are
 *  executable.
 *
 *  *this column has no architectural effect: NX markings are ignored by
 *   hardware, but may have behavioral effects when "wants X" collides with
 *   "cannot be X" constraints in memory permission flags, as in
 *   https://lkml.kernel.org/r/20190418055759.GA3155@mellanox.com
 *
 */

For MIPS, the "lacks NX" above is the "!cpu_has_rixi" check. On x86,
we decided that the READ_IMPLIES_EXEC flag needed to reflect the
expectations, not the architectural behavior due to bad interactions
as noted above, as always returning "1" on non-NX hardware breaks
some mappings.

The other part of the issue is "what does the MIPS toolchain do for
PT_GNU_STACK?" The answer seems to be "by default, include PT_GNU_STACK,
but mark it executable" (likely due to concerns over non-NX hardware):

$ mipsel-linux-gnu-gcc -o hello_world hello_world.c
$ llvm-readelf -lW hellow_world | grep GNU_STACK
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10

Given that older hardware doesn't support non-executable memory, it
seems safe to make the "PT_GNU_STACK is absent" logic mean "assume
non-executable", but this might break very old software running on
modern MIPS. This situation matches the ia32-on-x86_64 logic x86
uses (which assumes needing READ_IMPLIES_EXEC in that situation). But
modern toolchains on modern MIPS hardware should follow a safer default
(assume NX stack).

A follow-up to this change would be to switch the MIPS toolchain to emit
a non-executable PT_GNU_STACK, as this seems to be unneeded.

Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Cc: Juxin Gao <gaojuxin@loongson.cn>
Cc: linux-mips@vger.kernel.org
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      fbb1d4b3
  11. 22 Feb, 2022 6 commits
  13. 09 Feb, 2022 1 commit
    • Nathan Chancellor's avatar
      MIPS: Malta: Enable BLK_DEV_INITRD · c47c7ab9
      Nathan Chancellor authored 
      This configuration is useful for boot testing malta_defconfig in QEMU
with just a simple cpio initrd, instead of a full ext4 rootfs.

This results in an increase of ~164KB of vmlinux (with GCC 11.2.0):

$ diskus vmlinux.before
11.19 MB (11,194,368 bytes)

$ diskus vmlinux.after
11.36 MB (11,358,208 bytes)

This size increase comes from the fact that usr/Kconfig is sourced when
CONFIG_BLK_DEV_INITRD is enabled, which defaults to supporting several
decompression algorithms for compressed initrds. This seems like a
reasonable tradeoff but these configurations could be disabled in the
future if there are complaints about the size increase.
Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      c47c7ab9
  15. 07 Feb, 2022 4 commits
  17. 06 Feb, 2022 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7