12 Feb, 2019
2 commits
-
Limit the dma mask to be 32bit, because that
the imx8 doesn't have the 64bit dma capapbility
although it is 64bit soc.Signed-off-by: Richard Zhu
Reviewed-by: Frank Li -
Some DMA operation APIs are not exported, so when load driver as module,
there will error saying some APIs can not be found.
This patch exported these DMA related APIs.Signed-off-by: Shawn Xiao
26 Jan, 2019
1 commit
-
[ Upstream commit 33309ecda0070506c49182530abe7728850ebe78 ]
The dcache_by_line_op macro suffers from a couple of small problems:
First, the GAS directives that are currently being used rely on
assembler behavior that is not documented, and probably not guaranteed
to produce the correct behavior going forward. As a result, we end up
with some undefined symbols in cache.o:$ nm arch/arm64/mm/cache.o
...
U civac
...
U cvac
U cvap
U cvauThis is due to the fact that the comparisons used to select the
operation type in the dcache_by_line_op macro are comparing symbols
not strings, and even though it seems that GAS is doing the right
thing here (undefined symbols by the same name are equal to each
other), it seems unwise to rely on this.Second, when patching in a DC CVAP instruction on CPUs that support it,
the fallback path consists of a DC CVAU instruction which may be
affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE.Solve these issues by unrolling the various maintenance routines and
using the conditional directives that are documented as operating on
strings. To avoid the complexity of nested alternatives, we move the
DC CVAP patching to __clean_dcache_area_pop, falling back to a branch
to __clean_dcache_area_poc if DCPOP is not supported by the CPU.Reported-by: Ard Biesheuvel
Suggested-by: Robin Murphy
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
21 Dec, 2018
1 commit
-
commit 3238c359acee4ab57f15abb5a82b8ab38a661ee7 upstream.
We need to invalidate the caches *before* clearing the buffer via the
non-cacheable alias, else in the worst case __dma_flush_area() may
write back dirty lines over the top of our nice new zeros.Fixes: dd65a941f6ba ("arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag")
Cc: # 4.18.x-
Acked-by: Will Deacon
Signed-off-by: Robin Murphy
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman
04 Nov, 2018
1 commit
-
[ Upstream commit 469ed9d823b7d240d6b9574f061ded7c3834c167 ]
In the contiguous bit hugetlb break-before-make code we assume that all
hugetlb pages are young.In fact, remove_migration_pte is able to place an old hugetlb pte so
this assumption is not valid.This patch fixes the contiguous hugetlb scanning code to preserve young
ptes.Fixes: d8bdcff28764 ("arm64: hugetlb: Add break-before-make logic for contiguous entries")
Signed-off-by: Steve Capper
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
05 Sep, 2018
1 commit
-
commit 5ad356eabc47d26a92140a0c4b20eba471c10de3 upstream.
ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
before seeing if the PFN is valid. This leads to false positives when
some of the upper bits are set, but the lower bits match a valid PFN.For example, the following userspace code looks up a bogus entry in
/proc/kpageflags:int pagemap = open("/proc/self/pagemap", O_RDONLY);
int pageflags = open("/proc/kpageflags", O_RDONLY);
uint64_t pfn, val;lseek64(pagemap, [...], SEEK_SET);
read(pagemap, &pfn, sizeof(pfn));
if (pfn & (1UL << 63)) { /* valid PFN */
pfn &= ((1UL << 55) - 1); /* clear flag bits */
pfn |= (1UL << 55);
lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET);
read(pageflags, &val, sizeof(val));
}On ARM64 this causes the userspace process to crash with SIGSEGV rather
than reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as
valid, and stable_page_flags() will try to access an address between the
user and kernel address ranges.Fixes: c1cc1552616d ("arm64: MMU initialisation")
Cc: stable@vger.kernel.org
Signed-off-by: Greg Hackmann
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2018
1 commit
-
[ Upstream commit dd65a941f6ba473a5cb9d013d57fa43b48450a04 ]
dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
they should be cleared on allocation. In case of IOMMU-based dma-mapping
implementation such buffer clearing was missing in the code path for
DMA_ATTR_FORCE_CONTIGUOUS flag handling, because dma_alloc_from_contiguous()
doesn't honor __GFP_ZERO flag. This patch fixes this issue. For more
information on clearing buffers allocated by dma_alloc_* functions,
see commit 6829e274a623 ("arm64: dma-mapping: always clear allocated
buffers").Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
Signed-off-by: Marek Szyprowski
Signed-off-by: Catalin Marinas
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
18 Aug, 2018
1 commit
-
commit 785a19f9d1dd8a4ab2d0633be4656653bd3de1fc upstream.
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4. CPU may hit an exception because the old pmd entry is still in TLB,
which leads to a kernel panic.Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.[toshi.kani@hpe.com: merge changes, rewrite patch description]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya
Signed-off-by: Toshi Kani
Signed-off-by: Thomas Gleixner
Cc: mhocko@suse.com
Cc: akpm@linux-foundation.org
Cc: hpa@zytor.com
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon
Cc: Joerg Roedel
Cc: stable@vger.kernel.org
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "H. Peter Anvin"
Cc:
Link: https://lkml.kernel.org/r/20180627141348.21777-3-toshi.kani@hpe.com
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2018
1 commit
-
commit 7b0eb6b41a08fa1fa0d04b1c53becd62b5fbfaee upstream.
Arnd reports the following arm64 randconfig build error with the PSI
patches that add another page flag:/git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init':
/git/arm-soc/include/linux/compiler.h:357:38: error: call to
'__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON
failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)The additional page flag causes other information stored in
page->flags to get bumped into their own struct page member:#if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT
Tested-by: Arnd Bergmann
Cc: stable@vger.kernel.org
Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below the linear region")
Signed-off-by: Johannes Weiner
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2018
1 commit
-
Commit 6d99b68933fbcf51f84fcbba49246ce1209ec193 upstream.
Now that KVM uses tpidr_el2 in the same way as Linux's cpu_offset in
tpidr_el1, merge the two. This saves KVM from save/restoring tpidr_el1
on VHE hosts, and allows future code to blindly access per-cpu variables
without triggering world-switch.Signed-off-by: James Morse
Reviewed-by: Christoffer Dall
Reviewed-by: Catalin Marinas
Signed-off-by: Catalin Marinas
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
1 commit
-
commit 71c8fc0c96abf8e53e74ed4d891d671e585f9076 upstream.
When rewriting swapper using nG mappings, we must performance cache
maintenance around each page table access in order to avoid coherency
problems with the host's cacheable alias under KVM. To ensure correct
ordering of the maintenance with respect to Device memory accesses made
with the Stage-1 MMU disabled, DMBs need to be added between the
maintenance and the corresponding memory access.This patch adds a missing DMB between writing a new page table entry and
performing a clean+invalidate on the same line.Fixes: f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap swapper using nG mappings")
Cc: # 4.16.x-
Acked-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman
16 May, 2018
1 commit
-
commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream.
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to skip enabling the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected. There are some other cores suffering from this
errata, which could be added to the midr_list to trigger the work
around.Cc: Catalin Marinas
Cc: ckadabi@codeaurora.org
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2018
1 commit
-
commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
create pud/pmd mappings. A kernel panic was observed on arm64 systems
with Cortex-A75 in the following steps as described by Hanjun Guo.1. ioremap a 4K size, valid page table will build,
2. iounmap it, pte0 will set to 0;
3. ioremap the same address with 2M size, pgd/pmd is unchanged,
then set the a new value for pmd;
4. pte0 is leaked;
5. CPU may meet exception because the old pmd is still in TLB,
which will lead to kernel panic.This panic is not reproducible on x86. INVLPG, called from iounmap,
purges all levels of entries associated with purged address on x86. x86
still has memory leak.The patch changes the ioremap path to free unmapped page table(s) since
doing so in the unmap path has the following issues:- The iounmap() path is shared with vunmap(). Since vmap() only
supports pte mappings, making vunmap() to free a pte page is an
overhead for regular vmap users as they do not need a pte page freed
up.- Checking if all entries in a pte page are cleared in the unmap path
is racy, and serializing this check is expensive.- The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
purge.Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
clear a given pud/pmd entry and free up a page for the lower level
entries.This patch implements their stub functions on x86 and arm64, which work
as workaround.[akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
Reported-by: Lei Li
Signed-off-by: Toshi Kani
Cc: Catalin Marinas
Cc: Wang Xuefeng
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Michal Hocko
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Borislav Petkov
Cc: Matthew Wilcox
Cc: Chintan Pandya
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
15 Mar, 2018
1 commit
-
commit 753e8abc36b2c966caea075db0c845563c8a19bf upstream.
The routine pgattr_change_is_safe() was extended in commit 4e6020565596
("arm64: mm: Permit transitioning from Global to Non-Global without BBM")
to permit changing the nG attribute from not set to set, but did so in a
way that inadvertently disallows such changes if other permitted attribute
changes take place at the same time. So update the code to take this into
account.Fixes: 4e6020565596 ("arm64: mm: Permit transitioning from Global to ...")
Cc: # 4.14.x-
Acked-by: Mark Rutland
Reviewed-by: Marc Zyngier
Acked-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman
28 Feb, 2018
1 commit
-
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.Cc: #v4.14
Reported-by: Nicolas Dechesne
Signed-off-by: Ard Biesheuvel
Acked-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2018
1 commit
-
commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream.
When KASAN is enabled, the swapper page table contains many identical
mappings of the zero page, which can lead to a stall during boot whilst
the G -> nG code continually walks the same page table entries looking
for global mappings.This patch sets the nG bit (bit 11, which is IGNORED) in table entries
after processing the subtree so we can easily skip them if we see them
a second time.Tested-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman
17 Feb, 2018
17 commits
-
Commit 30d88c0e3ace upstream.
It is possible to take an IRQ from EL0 following a branch to a kernel
address in such a way that the IRQ is prioritised over the instruction
abort. Whilst an attacker would need to get the stars to align here,
it might be sufficient with enough calibration so perform BP hardening
in the rare case that we see a kernel address in the ELR when handling
an IRQ from EL0.Reported-by: Dan Hettena
Reviewed-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 5dfc6ed27710 upstream.
Software-step and PC alignment fault exceptions have higher priority than
instruction abort exceptions, so apply the BP hardening hooks there too
if the user PC appears to reside in kernel space.Reported-by: Dan Hettena
Reviewed-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit a8e4c0a919ae upstream.
We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
which has the unexpected consequence of being triggered on every
exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
even if no context switch actually occured.This is a bit suboptimal, and it would be more logical to only
invalidate the branch predictor when we actually switch to
a different mm.In order to solve this, move the call to arm64_apply_bp_hardening()
into check_and_switch_context(), where we're guaranteed to pick
a different mm context.Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 0f15adbb2861 upstream.
Aliasing attacks against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.This patch adds initial skeleton code behind a new Kconfig option to
enable implementation-specific mitigations against these attacks for
CPUs that are affected.Co-developed-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 95e3de3590e3 upstream.
We will soon need to invoke a CPU-specific function pointer after changing
page tables, so move post_ttbr_update_workaround out into C code to make
this possible.Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 51369e398d0d upstream.
Currently, USER_DS represents an exclusive limit while KERNEL_DS is
inclusive. In order to do some clever trickery for speculation-safe
masking, we need them both to behave equivalently - there aren't enough
bits to make KERNEL_DS exclusive, so we have precisely one option. This
also happens to correct a longstanding false negative for a range
ending on the very top byte of kernel memory.Mark Rutland points out that we've actually got the semantics of
addresses vs. segments muddled up in most of the places we need to
amend, so shuffle the {USER,KERNEL}_DS definitions around such that we
can correct those properly instead of just pasting "-1"s everywhere.Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 439e70e27a51 upstream.
The identity map is mapped as both writeable and executable by the
SWAPPER_MM_MMUFLAGS and this is relied upon by the kpti code to manage
a synchronisation flag. Update the .pushsection flags to reflect the
actual mapping attributes.Reported-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit f992b4dfd58b upstream.
Defaulting to global mappings for kernel space is generally good for
performance and appears to be necessary for Cavium ThunderX. If we
subsequently decide that we need to enable kpti, then we need to rewrite
our existing page table entries to be non-global. This is fiddly, and
made worse by the possible use of contiguous mappings, which require
a strict break-before-make sequence.Since the enable callback runs on each online CPU from stop_machine
context, we can have all CPUs enter the idmap, where secondaries can
wait for the primary CPU to rewrite swapper with its MMU off. It's all
fairly horrible, but at least it only runs once.Tested-by: Marc Zyngier
Reviewed-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 4e6020565596 upstream.
Break-before-make is not needed when transitioning from Global to
Non-Global mappings, provided that the contiguous hint is not being used.Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 6b88a32c7af6 upstream.
With ARM64_SW_TTBR0_PAN enabled, the exception entry code checks the
active ASID to decide whether user access was enabled (non-zero ASID)
when the exception was taken. On return from exception, if user access
was previously disabled, it re-instates TTBR0_EL1 from the per-thread
saved value (updated in switch_mm() or efi_set_pgd()).Commit 7655abb95386 ("arm64: mm: Move ASID from TTBR0 to TTBR1") makes a
TTBR0_EL1 + ASID switching non-atomic. Subsequently, commit 27a921e75711
("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN") changes the
__uaccess_ttbr0_disable() function and asm macro to first write the
reserved TTBR0_EL1 followed by the ASID=0 update in TTBR1_EL1. If an
exception occurs between these two, the exception return code will
re-instate a valid TTBR0_EL1. Similar scenario can happen in
cpu_switch_mm() between setting the reserved TTBR0_EL1 and the ASID
update in cpu_do_switch_mm().This patch reverts the entry.S check for ASID == 0 to TTBR0_EL1 and
disables the interrupts around the TTBR0_EL1 and ASID switching code in
__uaccess_ttbr0_disable(). It also ensures that, when returning from the
EFI runtime services, efi_set_pgd() doesn't leave a non-zero ASID in
TTBR1_EL1 by using uaccess_ttbr0_{enable,disable}.The accesses to current_thread_info()->ttbr0 are updated to use
READ_ONCE/WRITE_ONCE.As a safety measure, __uaccess_ttbr0_enable() always masks out any
existing non-zero ASID TTBR1_EL1 before writing in the new ASID.Fixes: 27a921e75711 ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN")
Acked-by: Will Deacon
Reported-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
Reviewed-by: James Morse
Tested-by: James Morse
Co-developed-by: Marc Zyngier
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 6c27c4082f4f upstream.
The literal pool entry for identifying the vectors base is the only piece
of information in the trampoline page that identifies the true location
of the kernel.This patch moves it into a page-aligned region of the .rodata section
and maps this adjacent to the trampoline text via an additional fixmap
entry, which protects against any accidental leakage of the trampoline
contents.Suggested-by: Ard Biesheuvel
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 51a0048beb44 upstream.
The exception entry trampoline needs to be mapped at the same virtual
address in both the trampoline page table (which maps nothing else)
and also the kernel page table, so that we can swizzle TTBR1_EL1 on
exceptions from and return to EL0.This patch maps the trampoline at a fixed virtual address in the fixmap
area of the kernel virtual address space, which allows the kernel proper
to be randomized with respect to the trampoline when KASLR is enabled.Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 0c8ea531b774 upstream.
In preparation for separate kernel/user ASIDs, allocate them in pairs
for each mm_struct. The bottom bit distinguishes the two: if it is set,
then the ASID will map only userspace.Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 27a921e75711 upstream.
With the ASID now installed in TTBR1, we can re-enable ARM64_SW_TTBR0_PAN
by ensuring that we switch to a reserved ASID of zero when disabling
user access and restore the active user ASID on the uaccess enable path.Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 158d495899ce upstream.
The post_ttbr0_update_workaround hook applies to any change to TTBRx_EL1.
Since we're using TTBR1 for the ASID, rename the hook to make it clearer
as to what it's doing.Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 85d13c001497 upstream.
The pre_ttbr0_update_workaround hook is called prior to context-switching
TTBR0 because Falkor erratum E1003 can cause TLB allocation with the wrong
ASID if both the ASID and the base address of the TTBR are updated at
the same time.With the ASID sitting safely in TTBR1, we no longer update things
atomically, so we can remove the pre_ttbr0_update_workaround macro as
it's no longer required. The erratum infrastructure and documentation
is left around for #E1003, as it will be required by the entry
trampoline code in a future patch.Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman -
Commit 7655abb95386 upstream.
In preparation for mapping kernelspace and userspace with different
ASIDs, move the ASID to TTBR1 and update switch_mm to context-switch
TTBR0 via an invalid mapping (the zero page).Reviewed-by: Mark Rutland
Tested-by: Laura Abbott
Tested-by: Shanker Donthineni
Signed-off-by: Will Deacon
Signed-off-by: Ard Biesheuvel
Signed-off-by: Greg Kroah-Hartman
20 Dec, 2017
2 commits
-
commit 1d08a044cf12aee37dfd54837558e3295287b343 upstream.
In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather
than VA_START) for the init_mm. This means that any reported W&X
addresses are offset by VA_START, which is clearly wrong and can make
them appear like userspace addresses.Fix this by telling the ptdump code that we're walking init_mm starting
at VA_START. We don't need to update the addr_markers, since these are
still valid bounds regardless.Fixes: 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable pages")
Signed-off-by: Mark Rutland
Cc: Kees Cook
Cc: Laura Abbott
Reported-by: Timur Tabi
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.This patch moves the initialisation of high_memory before it used.
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
02 Oct, 2017
1 commit
-
Currently data_abort_decode() dumps the ISS field as a decimal value
with a '0x' prefix, which is somewhat misleading.Fix it to print as hexadecimal, as was intended.
Fixes: 1f9b8936f36f4a8e ("arm64: Decode information from ESR upon mem faults")
Reviewed-by: Dave Martin
Reviewed-by: Julien Thierry
Acked-by: Will Deacon
Signed-off-by: Mark Rutland
Signed-off-by: Catalin Marinas
29 Sep, 2017
1 commit
-
We currently route pte translation faults via do_page_fault, which elides
the address check against TASK_SIZE before invoking the mm fault handling
code. However, this can cause issues with the path walking code in
conjunction with our word-at-a-time implementation because
load_unaligned_zeropad can end up faulting in kernel space if it reads
across a page boundary and runs into a page fault (e.g. by attempting to
read from a guard region).In the case of such a fault, load_unaligned_zeropad has registered a
fixup to shift the valid data and pad with zeroes, however the abort is
reported as a level 3 translation fault and we dispatch it straight to
do_page_fault, despite it being a kernel address. This results in calling
a sleeping function from atomic context:BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313
in_atomic(): 0, irqs_disabled(): 0, pid: 10290
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[...]
[] ___might_sleep+0x134/0x144
[] __might_sleep+0x7c/0x8c
[] do_page_fault+0x140/0x330
[] do_mem_abort+0x54/0xb0
Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0)
[...]
[] el1_da+0x18/0x78
[] path_parentat+0x44/0x88
[] filename_parentat+0x5c/0xd8
[] filename_create+0x4c/0x128
[] SyS_mkdirat+0x50/0xc8
[] el0_svc_naked+0x24/0x28
Code: 36380080 d5384100 f9400800 9402566d (d4210000)
---[ end trace 2d01889f2bca9b9f ]---Fix this by dispatching all translation faults to do_translation_faults,
which avoids invoking the page fault logic for faults on kernel addresses.Cc:
Reported-by: Ankit Jain
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
06 Sep, 2017
1 commit
-
Pull arm64 updates from Catalin Marinas:
- VMAP_STACK support, allowing the kernel stacks to be allocated in the
vmalloc space with a guard page for trapping stack overflows. One of
the patches introduces THREAD_ALIGN and changes the generic
alloc_thread_stack_node() to use this instead of THREAD_SIZE (no
functional change for other architectures)- Contiguous PTE hugetlb support re-enabled (after being reverted a
couple of times). We now have the semantics agreed in the generic mm
layer together with API improvements so that the architecture code
can detect between contiguous and non-contiguous huge PTEs- Initial support for persistent memory on ARM: DC CVAP instruction
exposed to user space (HWCAP) and the in-kernel pmem API implemented- raid6 improvements for arm64: faster algorithm for the delta syndrome
and implementation of the recovery routines using Neon- FP/SIMD refactoring and removal of support for Neon in interrupt
context. This is in preparation for full SVE support- PTE accessors converted from inline asm to cmpxchg so that we can use
LSE atomics if available (ARMv8.1)- Perf support for Cortex-A35 and A73
- Non-urgent fixes and cleanups
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (75 commits)
arm64: cleanup {COMPAT_,}SET_PERSONALITY() macro
arm64: introduce separated bits for mm_context_t flags
arm64: hugetlb: Cleanup setup_hugepagesz
arm64: Re-enable support for contiguous hugepages
arm64: hugetlb: Override set_huge_swap_pte_at() to support contiguous hugepages
arm64: hugetlb: Override huge_pte_clear() to support contiguous hugepages
arm64: hugetlb: Handle swap entries in huge_pte_offset() for contiguous hugepages
arm64: hugetlb: Add break-before-make logic for contiguous entries
arm64: hugetlb: Spring clean huge pte accessors
arm64: hugetlb: Introduce pte_pgprot helper
arm64: hugetlb: set_huge_pte_at Add WARN_ON on !pte_present
arm64: kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores
arm64: dma-mapping: Mark atomic_pool as __ro_after_init
arm64: dma-mapping: Do not pass data to gen_pool_set_algo()
arm64: Remove the !CONFIG_ARM64_HW_AFDBM alternative code paths
arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()
arm64: Move PTE_RDONLY bit handling out of set_pte_at()
kvm: arm64: Convert kvm_set_s2pte_readonly() from inline asm to cmpxchg()
arm64: Convert pte handling from inline asm to using (cmp)xchg
arm64: neon/efi: Make EFI fpsimd save/restore variables static
...
23 Aug, 2017
1 commit
-
When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.Cc: Catalin Marinas
Cc: Laura Abbott
Cc: stable@vger.kernel.org
Reviewed-by: Steve Capper
Tested-by: Steve Capper
Reviewed-by: James Morse
Tested-by: James Morse
Signed-off-by: Mark Rutland
Signed-off-by: Will Deacon