* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Wei Xu @ 2018-06-20 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620162845.GD27776@arm.com>
Hi Will,
On 2018/6/21 0:28, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 12:25:05AM +0800, Wei Xu wrote:
>> Hi James,
>>
>> On 2018/6/20 23:54, James Morse wrote:
>>> Hi Wei,
>>>
>>> On 20/06/18 16:52, Wei Xu wrote:
>>>> On 2018/6/20 22:42, Will Deacon wrote:
>>>>> Hmm, I wonder if this is at all related to RAS, since we've just enabled
>>>>> that and if we take a fault whilst rewriting swapper then we're going to
>>>>> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n in the guest?
>>>> I will try it now.
>>> It's not just the Kconfig symbol, could you also revert:
>>>
>>> f751daa4f9d3 ("arm64: Unconditionally enable IESB on exception entry/return for
>>> firmware-first")
>>>
>>>
>>> (reverts and build cleanly on 4.17)
>> Thanks to point out this!
>> I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
>> But I still got the stack overflow issue sometimes.
>> Do you have more hint?
> [...]
>
>> [ 0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
>> [ 0.081727] pc : el1_sync+0x0/0xb0
>> [ 0.085217] lr : kpti_install_ng_mappings+0x120/0x214
> Please run:
>
> $ ./scripts/faddr2line vmlinux kpti_install_ng_mappings+0x120/0x214
Thanks for your kindly guide :)
The output is as below:
joyx at Turing-Arch-b:~/plinth-kernel-v200$ ./scripts/faddr2line
../kernel-dev.build/vmlinux kpti_install_ng_mappings+0x120/0x214
kpti_install_ng_mappings+0x120/0x214:
cpu_set_reserved_ttbr0 at arch/arm64/include/asm/mmu_context.h:52
47 /*
48 * Set TTBR0 to empty_zero_page. No translations will be
possible via TTBR0.
49 */
50 static inline void cpu_set_reserved_ttbr0(void)
51 {
52 unsigned long ttbr =
phys_to_ttbr(__pa_symbol(empty_zero_page));
53
54 write_sysreg(ttbr, ttbr0_el1);
55 isb();
56 }
57
(inlined by) cpu_uninstall_idmap at
arch/arm64/include/asm/mmu_context.h:123
118 */
119 static inline void cpu_uninstall_idmap(void)
120 {
121 struct mm_struct *mm = current->active_mm;
122
123 cpu_set_reserved_ttbr0();
124 local_flush_tlb_all();
125 cpu_set_default_tcr_t0sz();
126
127 if (mm != &init_mm && !system_uses_ttbr0_pan())
128 cpu_switch_mm(mm->pgd, mm);
(inlined by) kpti_install_ng_mappings at
arch/arm64/kernel/cpufeature.c:922
917
918 remap_fn = (void
*)__pa_symbol(idmap_kpti_install_ng_mappings);
919
920 cpu_install_idmap();
921 remap_fn(cpu, num_online_cpus(),
__pa_symbol(swapper_pg_dir));
922 cpu_uninstall_idmap();
923
924 if (!cpu)
925 kpti_applied = true;
926
927 return;
Thanks!
Best Regards,
Wei
> as the GDB output wasn't helpful (it only showed local variable
> declarations?!).
>
> Will
>
> .
>
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Will Deacon @ 2018-06-20 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5B2A7FE1.5040607@hisilicon.com>
On Thu, Jun 21, 2018 at 12:25:05AM +0800, Wei Xu wrote:
> Hi James,
>
> On 2018/6/20 23:54, James Morse wrote:
> >Hi Wei,
> >
> >On 20/06/18 16:52, Wei Xu wrote:
> >>On 2018/6/20 22:42, Will Deacon wrote:
> >>>Hmm, I wonder if this is at all related to RAS, since we've just enabled
> >>>that and if we take a fault whilst rewriting swapper then we're going to
> >>>get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n in the guest?
> >>I will try it now.
> >It's not just the Kconfig symbol, could you also revert:
> >
> >f751daa4f9d3 ("arm64: Unconditionally enable IESB on exception entry/return for
> >firmware-first")
> >
> >
> >(reverts and build cleanly on 4.17)
>
> Thanks to point out this!
> I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
> But I still got the stack overflow issue sometimes.
> Do you have more hint?
[...]
> [ 0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
> [ 0.081727] pc : el1_sync+0x0/0xb0
> [ 0.085217] lr : kpti_install_ng_mappings+0x120/0x214
Please run:
$ ./scripts/faddr2line vmlinux kpti_install_ng_mappings+0x120/0x214
as the GDB output wasn't helpful (it only showed local variable
declarations?!).
Will
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Wei Xu @ 2018-06-20 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ebfabb8f-dcd9-3fb4-3655-368a882d8f09@arm.com>
Hi James,
On 2018/6/20 23:54, James Morse wrote:
> Hi Wei,
>
> On 20/06/18 16:52, Wei Xu wrote:
>> On 2018/6/20 22:42, Will Deacon wrote:
>>> Hmm, I wonder if this is at all related to RAS, since we've just enabled
>>> that and if we take a fault whilst rewriting swapper then we're going to
>>> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n in the guest?
>> I will try it now.
> It's not just the Kconfig symbol, could you also revert:
>
> f751daa4f9d3 ("arm64: Unconditionally enable IESB on exception entry/return for
> firmware-first")
>
>
> (reverts and build cleanly on 4.17)
Thanks to point out this!
I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
But I still got the stack overflow issue sometimes.
Do you have more hint?
Thanks!
The log is as below:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x480fd010]
[ 0.000000] Linux version 4.17.0-45865-g2b31fe7-dirty
(joyx at Turing-Arch-b) (gcc version 4.9.1 20140505 (prerelease)
(crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)) #10
SMP PREEMPT Wed Jun 20 23:59:05 CST 2018
[ 0.000000] Machine model: linux,dummy-virt
[ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x000000007f000000
[ 0.000000] NUMA: No NUMA configuration found
[ 0.000000] NUMA: Faking a node at [mem
0x0000000000000000-0x000000007fffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x7efeb300-0x7efecdff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000040000000-0x000000007fffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000040000000-0x000000007fffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000040000000-0x000000007fffffff]
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: Trusted OS migration not required
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] random: get_random_bytes called from
start_kernel+0xa8/0x418 with crng_init=0
[ 0.000000] percpu: Embedded 24 pages/cpu @ (ptrval)
s57984 r8192 d32128 u98304
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: detected: Kernel page table isolation
(KPTI)
[ 0.000000] CPU features: detected: Hardware dirty bit management
[ 0.000000] Built 1 zonelists, mobility grouping on. Total
pages: 258048
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: rdinit=init console=ttyAMA0
earlycon=pl011,0x9000000
[ 0.000000] Memory: 968436K/1048576K available (10044K kernel
code, 1328K rwdata, 4840K rodata, 1216K init, 409K bss, 63756K reserved,
16384K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1,
Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=128 to
nr_cpu_ids=1.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16,
nr_cpu_ids=1
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: no VLPI support, no direct LPI support
[ 0.000000] ITS [mem 0x08080000-0x0809ffff]
[ 0.000000] ITS at 0x0000000008080000: allocated 8192 Devices
@7d830000 (indirect, esz 8, psz 64K, shr 1)
[ 0.000000] ITS at 0x0000000008080000: allocated 8192 Interrupt
Collections @7d840000 (flat, esz 8, psz 64K, shr 1)
[ 0.000000] GIC: using LPI property table @0x000000007d850000
[ 0.000000] ITS: Allocated 1792 chunks for LPIs
[ 0.000000] GICv3: CPU0: found redistributor 0 region
0:0x00000000080a0000
[ 0.000000] CPU0: using LPI pending table @0x000000007d860000
[ 0.000000] GIC: PPI11 is secure or misconfigured
[ 0.000000] arch_timer: WARNING: Invalid trigger for IRQ3,
assuming level low
[ 0.000000] arch_timer: WARNING: Please fix your firmware
[ 0.000000] arch_timer: cp15 timer(s) running at 100.00MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask:
0xffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[ 0.000001] sched_clock: 56 bits at 100MHz, resolution 10ns,
wraps every 4398046511100ns
[ 0.000843] Console: colour dummy device 80x25
[ 0.001401] Calibrating delay loop (skipped), value calculated
using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[ 0.002453] pid_max: default: 32768 minimum: 301
[ 0.002941] Security Framework initialized
[ 0.003517] Dentry cache hash table entries: 131072 (order: 8,
1048576 bytes)
[ 0.004317] Inode-cache hash table entries: 65536 (order: 7,
524288 bytes)
[ 0.005018] Mount-cache hash table entries: 2048 (order: 2,
16384 bytes)
[ 0.005791] Mountpoint-cache hash table entries: 2048 (order: 2,
16384 bytes)
[ 0.025893] ASID allocator initialised with 32768 entries
[ 0.029901] Hierarchical SRCU implementation.
[ 0.034274] Platform MSI: its domain created
[ 0.034749] PCI/MSI: /intc/its domain created
[ 0.035317] EFI services will not be available.
[ 0.037930] smp: Bringing up secondary CPUs ...
[ 0.038396] smp: Brought up 1 node, 1 CPU
[ 0.038810] SMP: Total of 1 processors activated.
[ 0.039285] CPU features: detected: GIC system register CPU
interface
[ 0.039930] CPU features: detected: Privileged Access Never
[ 0.040488] CPU features: detected: User Access Override
[ 0.042421] Insufficient stack space to handle exception!
[ 0.042423] ESR: 0x96000046 -- DABT (current EL)
[ 0.043730] FAR: 0xffff0000093a80e0
[ 0.044714] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
[ 0.051113] IRQ stack: [0xffff000008000000..0xffff000008004000]
[ 0.057610] Overflow stack: [0xffff80003efce2f0..0xffff80003efcf2f0]
[ 0.064003] CPU: 0 PID: 12 Comm: migration/0 Not tainted
4.17.0-45865-g2b31fe7-dirty #10
[ 0.072201] Hardware name: linux,dummy-virt (DT)
[ 0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
[ 0.081727] pc : el1_sync+0x0/0xb0
[ 0.085217] lr : kpti_install_ng_mappings+0x120/0x214
[ 0.090284] sp : ffff0000093a80e0
[ 0.093654] x29: ffff0000093abce0 x28: ffff000008ea9000
[ 0.099071] x27: ffff000008ea9000 x26: ffff0000091f7000
[ 0.104488] x25: ffff00000906d000 x24: ffff000009191000
[ 0.109798] x23: ffff000008ea9000 x22: 0000000041190000
[ 0.115217] x21: ffff0000091f7000 x20: 0000000000000000
[ 0.120633] x19: ffff000009190000 x18: 000000003455d99d
[ 0.125943] x17: 0000000000000001 x16: 00f8000040ffff13
[ 0.131358] x15: 000000007eff6000 x14: 000000007eff6000
[ 0.136773] x13: 00f800007fe00f11 x12: 000000007eff8000
[ 0.142082] x11: 000000007eff8000 x10: 0000000000000000
[ 0.147501] x9 : 000000007eff9000 x8 : 000000007eff9000
[ 0.152920] x7 : 0000000000000000 x6 : 00000000411f8000
[ 0.158230] x5 : 00000000411f8000 x4 : 0000000040a443d4
[ 0.163646] x3 : 00000000411f7000 x2 : 00000000411f7000
[ 0.169061] x1 : ffff00000906d7b0 x0 : ffff80003da61c00
[ 0.174372] Kernel panic - not syncing: kernel stack overflow
[ 0.180264] CPU: 0 PID: 12 Comm: migration/0 Not tainted
4.17.0-45865-g2b31fe7-dirty #10
[ 0.188348] Hardware name: linux,dummy-virt (DT)
[ 0.193046] Call trace:
[ 0.195572] dump_backtrace+0x0/0x180
[ 0.199304] show_stack+0x14/0x1c
[ 0.202677] dump_stack+0x90/0xb0
[ 0.206152] panic+0x138/0x2a0
[ 0.209182] __stack_chk_fail+0x0/0x18
[ 0.213029] handle_bad_stack+0x118/0x124
[ 0.217120] __bad_stack+0x88/0x8c
[ 0.220607] el1_sync+0x0/0xb0
[ 0.223738] Unable to handle kernel paging request at virtual
address ffff0000093abce0
[ 0.231704] Mem abort info:
[ 0.234586] ESR = 0x96000006
[ 0.237714] Exception class = DABT (current EL), IL = 32 bits
[ 0.243628] SET = 0, FnV = 0
[ 0.246758] EA = 0, S1PTW = 0
[ 0.250001] Data abort info:
[ 0.253000] ISV = 0, ISS = 0x00000006
[ 0.256859] CM = 0, WnR = 0
[ 0.259871] swapper pgtable: 4k pages, 48-bit VAs, pgdp
= (ptrval)
[ 0.266862] [ffff0000093abce0] pgd=00000000411f8803,
pud=00000000411f9803, pmd=0000000000000000
[ 0.275659] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 0.281213] Modules linked in:
[ 0.284447] CPU: 0 PID: 12 Comm: migration/0 Not tainted
4.17.0-45865-g2b31fe7-dirty #10
[ 0.292534] Hardware name: linux,dummy-virt (DT)
[ 0.297229] pstate: 204003c5 (nzCv DAIF +PAN -UAO)
[ 0.302053] pc : unwind_frame+0x28/0xc8
[ 0.306022] lr : dump_backtrace+0x12c/0x180
[ 0.310245] sp : ffff80003efcf000
[ 0.313616] x29: ffff80003efcf000 x28: ffff80003da61c00
[ 0.319033] x27: ffff000008ea9000 x26: ffff0000091f7000
[ 0.324348] x25: ffff00000906d000 x24: ffff0000093a80e0
[ 0.329764] x23: 0000000000000000 x22: ffff000008dbae28
[ 0.335179] x21: 0000000000000000 x20: ffff000009049000
[ 0.340488] x19: ffff80003da61c00 x18: 000000003455d99d
[ 0.345906] x17: 0000000000000001 x16: 00f8000040ffff13
[ 0.351322] x15: 000000007eff6000 x14: 3031232079747269
[ 0.356633] x13: 0000000000000000 x12: cc26f77952f87e00
[ 0.362046] x11: ffffffffffffffff x10: 0000000000000076
[ 0.367466] x9 : ffff0000085aea28 x8 : ffff80003efcec90
[ 0.372880] x7 : 0000000000000000 x6 : ffff0000091befe1
[ 0.378190] x5 : 0000000000000000 x4 : ffff0000093ac000
[ 0.383605] x3 : ffff0000093a8000 x2 : ffff0000093abce0
[ 0.389021] x1 : ffff80003efcf048 x0 : ffff80003da61c00
[ 0.394330] Process migration/0 (pid: 12, stack limit =
0x (ptrval))
[ 0.401427] Call trace:
[ 0.403852] unwind_frame+0x28/0xc8
[ 0.407455] show_stack+0x14/0x1c
[ 0.410828] dump_stack+0x90/0xb0
[ 0.414201] panic+0x138/0x2a0
[ 0.417329] __stack_chk_fail+0x0/0x18
[ 0.421177] handle_bad_stack+0x118/0x124
[ 0.425273] __bad_stack+0x88/0x8c
[ 0.428762] el1_sync+0x0/0xb0
[ 0.431891] Unable to handle kernel paging request at virtual
address ffff0000093abce0
[ 0.439851] Mem abort info:
[ 0.442734] ESR = 0x96000006
[ 0.445861] Exception class = DABT (current EL), IL = 32 bits
[ 0.451774] SET = 0, FnV = 0
[ 0.454900] EA = 0, S1PTW = 0
[ 0.458142] Data abort info:
[ 0.461144] ISV = 0, ISS = 0x00000006
[ 0.465001] CM = 0, WnR = 0
[ 0.468013] swapper pgtable: 4k pages, 48-bit VAs, pgdp
= (ptrval)
[ 0.474996] [ffff0000093abce0] pgd=00000000411f8803,
pud=00000000411f9803, pmd=0000000000000000
Best Regards,
Wei
>
> Thanks,
>
> James
>
> .
>
^ permalink raw reply
* [PATCH 3/3] arm64: IPI each CPU after invalidating the I-cache for kernel mappings
From: Alexander Van Brunt @ 2018-06-20 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529412495-17525-4-git-send-email-will.deacon@arm.com>
> When invalidating the instruction cache for a kernel mapping via
> flush_icache_range(), it is also necessary to flush the pipeline for
> other CPUs so that instructions fetched into the pipeline before the
> I-cache invalidation are discarded. For example, if module 'foo' is
> unloaded and then module 'bar' is loaded into the same area of memory,
> a CPU could end up executing instructions from 'foo' when branching into
> 'bar' if these instructions were fetched into the pipeline before 'foo'
> was unloaded.
I don't think this fixes the problem. If a CPU is executing 'foo', takes an IPI, and returns to find itself executing in the middle of 'bar' there is still a problem because the code changed. All this patch does is synchronize when two CPUs see 'foo' change to 'bar'.
^ permalink raw reply
* [PATCH v4 05/19] dt-bindings: sram: sunxi: Add A33 binding for the C1 SRAM region
From: Rob Herring @ 2018-06-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-6-paul.kocialkowski@bootlin.com>
On Mon, Jun 18, 2018 at 04:58:29PM +0200, Paul Kocialkowski wrote:
> This introduces a dedicated binding for the C1 SRAM region for the A33
> sunxi platform.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 02/19] dt-bindings: sram: sunxi: Add A10 binding for the C1 SRAM region
From: Rob Herring @ 2018-06-20 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-3-paul.kocialkowski@bootlin.com>
On Mon, Jun 18, 2018 at 04:58:26PM +0200, Paul Kocialkowski wrote:
> This introduces a dedicated binding for the C1 SRAM region for the A10
> sunxi platform.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: James Morse @ 2018-06-20 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5B2A7832.4010502@hisilicon.com>
Hi Wei,
On 20/06/18 16:52, Wei Xu wrote:
> On 2018/6/20 22:42, Will Deacon wrote:
>> Hmm, I wonder if this is at all related to RAS, since we've just enabled
>> that and if we take a fault whilst rewriting swapper then we're going to
>> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n in the guest?
>
> I will try it now.
It's not just the Kconfig symbol, could you also revert:
f751daa4f9d3 ("arm64: Unconditionally enable IESB on exception entry/return for
firmware-first")
(reverts and build cleanly on 4.17)
Thanks,
James
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Wei Xu @ 2018-06-20 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620144257.GB27776@arm.com>
Hi Will,
On 2018/6/20 22:42, Will Deacon wrote:
> Hi Wei,
>
> On Wed, Jun 20, 2018 at 10:18:00PM +0800, Wei Xu wrote:
>> We have observed KVM guest sometimes failed to boot because of kernel stack
>> overflow if KPTI is enabled on a hisilicon arm64 platform.
>>
>> We also tested with different kernel version and found it is only
>> happened if the KPTI and KVM(enable-kvm & cpu=host) are enabled on the
>> guest.
>> The detail result is as below table.
>>
>> +---------+----------+--------+------------+-------------------+
>> | host |host KPTI | guest | guest KPTI | kvm guest |
>> | kernel |enabled | kernel | enabled | booting result |
>> +---------+----------+--------+------------+-------------------+
>> | 4.17 | Y | 4.17 | Y | stack overflow |
>> +---------+----------+--------+------------+-------------------+
>> | 4.17 | Y | 4.16 | NA | OK |
>> +---------+----------+--------+------------+-------------------+
>> | 4.16 | NA | 4.17 | Y | stack overflow |
>> +---------+----------+--------+------------+-------------------+
>> | 4.16 | NA | 4.16 | NA | OK |
>> +---------+----------+--------+------------+-------------------+
>>
>> A simple walk-around is adding this platform into the "kpti_safe_list".
>> But it does not resolve the issue indeed.
>> Could you please share any hint how to resolve this kind issue?
>> Thanks!
>>
>> Another issue we found is "kpti_install_ng_mappings" will be invoked
>> even "kpti=off" has been added in the kernel command line. Is that expected?
>> This is because "kpti" is not a *early* param that "init_cpu_features" will
>> be invoked before parsing the param.
> That sounds like a straightforward bug, which means we should use
> early_param instead of __setup. I assume that doesn't fix your crash,
> though?
Thanks for you quick response!
It can fix our crash but just another walk-around.
>> The command we are using to run the guest is as:
>>
>> ./qemu-system-aarch64 -machine virt,kernel_irqchip=on,gic-version=3 -cpu
>> host
>> -enable-kvm -smp 1 -m 1024 -kernel ./Image -initrd
>> ../mini-rootfs-arm64.cpio.gz
>> -nographic -append "rdinit=init console=ttyAMA0
>> earlycon=pl011,0x9000000"
>>
>> The log is as below:
>>
>> [ 0.000000] Booting Linux on physical CPU 0x0000000000
>> [0x480fd010]
>> [ 0.000000] Linux version 4.17.0-45864-g29dcea8-dirty
>> (joyx at Turing-Arch-b) (gcc version 4.9.1 20140505 (prerelease) (crosstool-NG
>> linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)) #6 SMP PREEMPT Fri Jun
>> 15 21:39:52 CST 2018
> ^^^ This is reproducible with vanilla v4.17 and defconfig, right?
Yes.
>
>> [ 0.038859] SMP: Total of 1 processors activated.
>> [ 0.039338] CPU features: detected: GIC system register CPU
>> interface
>> [ 0.039988] CPU features: detected: Privileged Access Never
>> [ 0.040560] CPU features: detected: User Access Override
>> [ 0.041093] CPU features: detected: RAS Extension Support
>> [ 0.042947] Insufficient stack space to handle exception!
>> [ 0.042949] ESR: 0x96000046 -- DABT (current EL)
>> [ 0.043963] FAR: 0xffff0000093a80e0
>> [ 0.045794] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
>> [ 0.052181] IRQ stack: [0xffff000008000000..0xffff000008004000]
>> [ 0.058572] Overflow stack:
>> [0xffff80003efce2f0..0xffff80003efcf2f0]
>> [ 0.065068] CPU: 0 PID: 12 Comm: migration/0 Not tainted
>> 4.17.0-45864-g29dcea8-dirty #6
>> [ 0.073138] Hardware name: linux,dummy-virt (DT)
>> [ 0.077831] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
>> [ 0.082661] pc : el1_sync+0x0/0xb0
>> [ 0.086152] lr : kpti_install_ng_mappings+0x120/0x214
> Can you use scripts/faddr2line to find out which line of code the lr is
> pointing at, please? It would be interesting to know if we managed to
> install the idmap.
I did not use addr2line before but with gdb we can get same info as below:
(gdb) list *kpti_install_ng_mappings+0x120/0x214
0xffff000008091d70 is in kpti_install_ng_mappings
(/home/joyx/plinth-kernel-v200/arch/arm64/kernel/cpufeature.c:907).
902 return !has_cpuid_feature(entry, scope);
903 }
904
905 static void
906 kpti_install_ng_mappings(const struct arm64_cpu_capabilities
*__unused)
907 {
908 typedef void (kpti_remap_fn)(int, int, phys_addr_t);
909 extern kpti_remap_fn idmap_kpti_install_ng_mappings;
910 kpti_remap_fn *remap_fn;
911
> Hmm, I wonder if this is at all related to RAS, since we've just enabled
> that and if we take a fault whilst rewriting swapper then we're going to
> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n in the guest?
I will try it now.
Thanks!
Best Regards,
Wei
> Will
>
> .
>
^ permalink raw reply
* [PATCH v5 1/5] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-06-20 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-2-codrin.ciubotariu@microchip.com>
On Mon, Jun 18, 2018 at 05:12:35PM +0300, Codrin Ciubotariu wrote:
> The I2S mux clock can be used to select the I2S input clock. The
> available parents are the peripheral and the generated clocks.
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
>
> Changes in v5:
> - specified clock's parent;
> - added a newline before adding the clock's compatible string;
>
> .../devicetree/bindings/clock/at91-clock.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
Well, since Alexandre promises all this is going to get re-worked soon:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: kpti: Use early_param for kpti= command-line option
From: Wei Xu @ 2018-06-20 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529508227-24331-1-git-send-email-will.deacon@arm.com>
Hi Will,
On 2018/6/20 16:23, Will Deacon wrote:
> We inspect __kpti_forced early on as part of the cpufeature enable
> callback which remaps the swapper page table using non-global entries.
>
> Ensure that __kpti_forced has been updated to reflect the kpti=
> command-line option before we start using it.
>
> Reported-by: Wei Xu <xuwei5@hisilicon.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/cpufeature.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index d2856b129097..112b071e793f 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -937,7 +937,7 @@ static int __init parse_kpti(char *str)
> __kpti_forced = enabled ? 1 : -1;
> return 0;
> }
> -__setup("kpti=", parse_kpti);
> +early_param("kpti=", parse_kpti);
%s/kpti=/kpti
Thanks!
Best Regards,
Wei
> #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>
> #ifdef CONFIG_ARM64_HW_AFDBM
>
^ permalink raw reply
* [PATCH] arm64: kpti: Use early_param for kpti= command-line option
From: Will Deacon @ 2018-06-20 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620154032.kwhvuwibustjqmwz@armageddon.cambridge.arm.com>
On Wed, Jun 20, 2018 at 04:40:32PM +0100, Catalin Marinas wrote:
> On Wed, Jun 20, 2018 at 04:23:47PM +0100, Will Deacon wrote:
> > We inspect __kpti_forced early on as part of the cpufeature enable
> > callback which remaps the swapper page table using non-global entries.
> >
> > Ensure that __kpti_forced has been updated to reflect the kpti=
> > command-line option before we start using it.
> >
> > Reported-by: Wei Xu <xuwei5@hisilicon.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Does it need a fixes tag?
>
> Fixes: ea1e3de85e94 ("arm64: entry: Add fake CPU feature for unmapping the kernel at EL0")
Perhaps, but really this is just a performance optimisation for the kpti=off
case where we don't actually need to put the nG mappings down.
Will
^ permalink raw reply
* [PATCH v4 15/19] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver
From: Paul Kocialkowski @ 2018-06-20 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620154009.GA26099@rob-hp-laptop>
Hi,
On Wed, 2018-06-20 at 09:40 -0600, Rob Herring wrote:
> On Mon, Jun 18, 2018 at 04:58:39PM +0200, Paul Kocialkowski wrote:
> > This adds a device-tree binding document that specifies the properties
> > used by the Sunxi-Cedurs VPU driver, as well as examples.
> >
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> >
> > create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
>
> You are missing a '---' line so this is going to end up in the commit
> msg.
Yes, I can't really explain how this happened. It seems related to
exporting patches with --summary.
> Please add acked/reviewed bys when posting new versions.
Oh, sorry for forgetting that. The bindings are indeed exactly the same
as the ones your reviewed and acked already.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180620/8efc735c/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: kpti: Use early_param for kpti= command-line option
From: Catalin Marinas @ 2018-06-20 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529508227-24331-1-git-send-email-will.deacon@arm.com>
On Wed, Jun 20, 2018 at 04:23:47PM +0100, Will Deacon wrote:
> We inspect __kpti_forced early on as part of the cpufeature enable
> callback which remaps the swapper page table using non-global entries.
>
> Ensure that __kpti_forced has been updated to reflect the kpti=
> command-line option before we start using it.
>
> Reported-by: Wei Xu <xuwei5@hisilicon.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Does it need a fixes tag?
Fixes: ea1e3de85e94 ("arm64: entry: Add fake CPU feature for unmapping the kernel at EL0")
--
Catalin
^ permalink raw reply
* [PATCH v4 15/19] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver
From: Rob Herring @ 2018-06-20 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-16-paul.kocialkowski@bootlin.com>
On Mon, Jun 18, 2018 at 04:58:39PM +0200, Paul Kocialkowski wrote:
> This adds a device-tree binding document that specifies the properties
> used by the Sunxi-Cedurs VPU driver, as well as examples.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
You are missing a '---' line so this is going to end up in the commit
msg.
Please add acked/reviewed bys when posting new versions.
Rob
^ permalink raw reply
* [PATCH 2/3] arm64: Remove unnecessary ISBs from set_{pte, pmd, pud}
From: Catalin Marinas @ 2018-06-20 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529412495-17525-3-git-send-email-will.deacon@arm.com>
On Tue, Jun 19, 2018 at 01:48:14PM +0100, Will Deacon wrote:
> Commit 7f0b1bf04511 ("arm64: Fix barriers used for page table modifications")
> fixed a reported issue with fixmap page-table entries not being visible
> to the walker due to a missing DSB instruction. At the same time, it added
> ISB instructions to the arm64 set_{pte,pmd,pud} functions, which are not
> required by the architecture and make little sense in isolation.
>
> Remove the redundant ISBs.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Steve Capper <steve.capper@linaro.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Since I no longer remember the reason I added the ISBs in the first
place:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v4 7/7] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile | 11 +++++++++++
.../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++++++
tools/testing/selftests/arm64/tags_test.c | 19 +++++++++++++++++++
4 files changed, 43 insertions(+)
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
new file mode 100644
index 000000000000..e8fae8d61ed6
--- /dev/null
+++ b/tools/testing/selftests/arm64/.gitignore
@@ -0,0 +1 @@
+tags_test
diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
new file mode 100644
index 000000000000..a61b2e743e99
--- /dev/null
+++ b/tools/testing/selftests/arm64/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+
+# ARCH can be overridden by the user for cross compiling
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
+ifneq (,$(filter $(ARCH),aarch64 arm64))
+TEST_GEN_PROGS := tags_test
+TEST_PROGS := run_tags_test.sh
+endif
+
+include ../lib.mk
diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
new file mode 100755
index 000000000000..745f11379930
--- /dev/null
+++ b/tools/testing/selftests/arm64/run_tags_test.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+echo "--------------------"
+echo "running tags test"
+echo "--------------------"
+./tags_test
+if [ $? -ne 0 ]; then
+ echo "[FAIL]"
+else
+ echo "[PASS]"
+fi
diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
new file mode 100644
index 000000000000..1452ed7d33f9
--- /dev/null
+++ b/tools/testing/selftests/arm64/tags_test.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <sys/utsname.h>
+
+#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
+#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
+ SHIFT_TAG(tag))
+
+int main(void)
+{
+ struct utsname utsname;
+ void *ptr = &utsname;
+ void *tagged_ptr = (void *)SET_TAG(ptr, 0x42);
+ int err = uname(tagged_ptr);
+ return err;
+}
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 6/7] arm64: update Documentation/arm64/tagged-pointers.txt
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
Add a note that work on passing tagged user pointers to the kernel via
syscalls has started, but might not be complete yet.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
Documentation/arm64/tagged-pointers.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index a25a99e82bb1..361481283f00 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -35,8 +35,9 @@ Using non-zero address tags in any of these locations may result in an
error code being returned, a (fatal) signal being raised, or other modes
of failure.
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
+Some initial work for supporting non-zero address tags passed to the
+kernel via system calls has been done, but the kernel doesn't provide
+any guarantees at this point. Using a non-zero address tag for sp is
strongly discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 5/7] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index b53e1b5d80f4..97467cd2bc59 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -106,6 +106,8 @@ long strncpy_from_user(char *dst, const char __user *src, long count)
if (unlikely(count <= 0))
return 0;
+ src = untagged_addr(src);
+
max_addr = user_addr_max();
src_addr = (unsigned long)src;
if (likely(src_addr < max_addr)) {
diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
index 60d0bbda8f5e..8b5f56466e00 100644
--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -108,6 +108,8 @@ long strnlen_user(const char __user *str, long count)
if (unlikely(count <= 0))
return 0;
+ str = untagged_addr(str);
+
max_addr = user_addr_max();
src_addr = (unsigned long)str;
if (likely(src_addr < max_addr)) {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 4/7] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Here we also need to handle the case of tagged user
pointers.
Add untagging to gup.c functions that use user pointers for vma lookup.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/gup.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index b70d7ba7cc13..5bb351c91989 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -666,6 +666,8 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (!nr_pages)
return 0;
+ start = untagged_addr(start);
+
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
/*
@@ -820,6 +822,8 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
struct vm_area_struct *vma;
int ret, major = 0;
+ address = untagged_addr(address);
+
if (unlocked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 3/7] arm64: untag user addresses in access_ok and __uaccess_mask_ptr
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers in access_ok and in __uaccess_mask_ptr,
before performing access validity checks.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 2d6451cbaa86..fa7318d3d7d5 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -105,7 +105,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
#define untagged_addr(addr) \
((__typeof__(addr))sign_extend64((__u64)(addr), 55))
-#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok(type, addr, size) \
+ __range_ok(untagged_addr(addr), size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
@@ -237,7 +238,8 @@ static inline void uaccess_enable_not_uao(void)
/*
* Sanitise a uaccess pointer such that it becomes NULL if above the
- * current addr_limit.
+ * current addr_limit. In case the pointer is tagged (has the top byte set),
+ * untag the pointer before checking.
*/
#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
@@ -245,10 +247,11 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
void __user *safe_ptr;
asm volatile(
- " bics xzr, %1, %2\n"
+ " bics xzr, %3, %2\n"
" csel %0, %1, xzr, eq\n"
: "=&r" (safe_ptr)
- : "r" (ptr), "r" (current_thread_info()->addr_limit)
+ : "r" (ptr), "r" (current_thread_info()->addr_limit),
+ "r" (untagged_addr(ptr))
: "cc");
csdb();
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 2/7] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel (like the mm subsystem), the untagged_addr
macro should be defined for all architectures.
Define it as a noop for other architectures besides arm64.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
include/linux/uaccess.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1cdd47..c045b4eff95e 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -13,6 +13,10 @@
#include <asm/uaccess.h>
+#ifndef untagged_addr
+#define untagged_addr(addr) addr
+#endif
+
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
* and get rid of their private instances of copy_{to,from}_user() and
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 1/7] arm64: add type casts to untagged_addr macro
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1529507994.git.andreyknvl@google.com>
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index e66b0fca99c2..2d6451cbaa86 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -102,7 +102,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
* up with a tagged userland pointer. Clear the tag to get a sane pointer to
* pass on to access_ok(), for instance.
*/
-#define untagged_addr(addr) sign_extend64(addr, 55)
+#define untagged_addr(addr) \
+ ((__typeof__(addr))sign_extend64((__u64)(addr), 55))
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
To: linux-arm-kernel
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.
We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Changes in v4:
- Added a selftest for checking that passing tagged pointers to the
kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).
Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.
Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.
Changes in v1:
- Rebased onto 4.17-rc1.
Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped ?mm, arm64: untag user addresses in memory syscalls?.
- Rebased onto 3eb2ce82 (4.16-rc7).
Andrey Konovalov (7):
arm64: add type casts to untagged_addr macro
uaccess: add untagged_addr definition for other arches
arm64: untag user addresses in access_ok and __uaccess_mask_ptr
mm, arm64: untag user addresses in mm/gup.c
lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
arm64: update Documentation/arm64/tagged-pointers.txt
selftests, arm64: add a selftest for passing tagged pointers to kernel
Documentation/arm64/tagged-pointers.txt | 5 +++--
arch/arm64/include/asm/uaccess.h | 14 +++++++++-----
include/linux/uaccess.h | 4 ++++
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
mm/gup.c | 4 ++++
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile | 11 +++++++++++
.../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++++++
tools/testing/selftests/arm64/tags_test.c | 19 +++++++++++++++++++
10 files changed, 67 insertions(+), 7 deletions(-)
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply
* [PATCH] arm64: kpti: Use early_param for kpti= command-line option
From: Will Deacon @ 2018-06-20 15:23 UTC (permalink / raw)
To: linux-arm-kernel
We inspect __kpti_forced early on as part of the cpufeature enable
callback which remaps the swapper page table using non-global entries.
Ensure that __kpti_forced has been updated to reflect the kpti=
command-line option before we start using it.
Reported-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/cpufeature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d2856b129097..112b071e793f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -937,7 +937,7 @@ static int __init parse_kpti(char *str)
__kpti_forced = enabled ? 1 : -1;
return 0;
}
-__setup("kpti=", parse_kpti);
+early_param("kpti=", parse_kpti);
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
#ifdef CONFIG_ARM64_HW_AFDBM
--
2.1.4
^ permalink raw reply related
* [PATCH 5/6] dmaengine: xilinx_dma: autodetect whether the HW supports scatter-gather
From: Andrea Merello @ 2018-06-20 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DM6PR02MB436181CD5544B0FA95318077C7770@DM6PR02MB4361.namprd02.prod.outlook.com>
On Wed, Jun 20, 2018 at 4:43 PM, Radhey Shyam Pandey <radheys@xilinx.com> wrote:
>> -----Original Message-----
>> From: dmaengine-owner at vger.kernel.org [mailto:dmaengine-
>> owner at vger.kernel.org] On Behalf Of Andrea Merello
>> Sent: Wednesday, June 20, 2018 2:07 PM
>> To: vkoul at kernel.org; dan.j.williams at intel.com; Michal Simek
>> <michals@xilinx.com>; Appana Durga Kedareswara Rao
>> <appanad@xilinx.com>; dmaengine at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
>> Andrea Merello <andrea.merello@gmail.com>
>> Subject: [PATCH 5/6] dmaengine: xilinx_dma: autodetect whether the HW
>> supports scatter-gather
>>
>> The HW can be either direct-access or scatter-gather version. These are
>> SW incompatible.
>>
>> The driver can handle both version: a DT property was used to
>> tell the driver whether to assume the HW is is scatter-gather mode.
>>
>> This patch makes the driver to autodetect this information. The DT
>> property is not required anymore.
>>
>> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
>> ---
>> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
>> index bdbc8ba9092a..8c6e818e596f 100644
>> --- a/drivers/dma/xilinx/xilinx_dma.c
>> +++ b/drivers/dma/xilinx/xilinx_dma.c
>> @@ -86,6 +86,7 @@
>> #define XILINX_DMA_DMASR_DMA_DEC_ERR BIT(6)
>> #define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
>> #define XILINX_DMA_DMASR_DMA_INT_ERR BIT(4)
>> +#define XILINX_DMA_DMASR_SG_MASK BIT(3)
>> #define XILINX_DMA_DMASR_IDLE BIT(1)
>> #define XILINX_DMA_DMASR_HALTED BIT(0)
>> #define XILINX_DMA_DMASR_DELAY_MASK GENMASK(31, 24)
>> @@ -407,7 +408,6 @@ struct xilinx_dma_config {
>> * @dev: Device Structure
>> * @common: DMA device structure
>> * @chan: Driver specific DMA channel
>> - * @has_sg: Specifies whether Scatter-Gather is present or not
>> * @mcdma: Specifies whether Multi-Channel is present or not
>> * @flush_on_fsync: Flush on frame sync
>> * @ext_addr: Indicates 64 bit addressing is supported by dma device
>> @@ -426,7 +426,6 @@ struct xilinx_dma_device {
>> struct device *dev;
>> struct dma_device common;
>> struct xilinx_dma_chan
>> *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
>> - bool has_sg;
>> bool mcdma;
>> u32 flush_on_fsync;
>> bool ext_addr;
>> @@ -2391,7 +2390,6 @@ static int xilinx_dma_chan_probe(struct
>> xilinx_dma_device *xdev,
>>
>> chan->dev = xdev->dev;
>> chan->xdev = xdev;
>> - chan->has_sg = xdev->has_sg;
>> chan->desc_pendingcount = 0x0;
>> chan->ext_addr = xdev->ext_addr;
>> /* This variable ensures that descriptors are not
>> @@ -2488,6 +2486,13 @@ static int xilinx_dma_chan_probe(struct
>> xilinx_dma_device *xdev,
>> chan->stop_transfer = xilinx_dma_stop_transfer;
>> }
>>
>> + /* check if SG is enabled */
>> + if (dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
>> + XILINX_DMA_DMASR_SG_MASK)
> I think SGIncld mask is only applicable for AXI DMA and CDMA IP.
> For VDMA IP this bit is reserved.
OK. I can make it conditional wrt the IP type. As far as I can see
VDMA IP has not the two (SG vs no-SG) variant at all, so all should be
still OK.
> .
>> + chan->has_sg = true;
>> + dev_dbg(chan->dev, "ch %d: SG %s\n", chan->id,
>> + chan->has_sg ? "enabled" : "disabled");
>> +
>> /* Initialize the tasklet */
>> tasklet_init(&chan->tasklet, xilinx_dma_do_tasklet,
>> (unsigned long)chan);
>> @@ -2626,7 +2631,6 @@ static int xilinx_dma_probe(struct platform_device
>> *pdev)
>> return PTR_ERR(xdev->regs);
>>
>> /* Retrieve the DMA engine properties from the device tree */
>> -
> Unrelated change
Oops.. Sorry.
>
>> if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
>> xdev->mcdma = of_property_read_bool(node, "xlnx,mcdma");
>> err = of_property_read_u32(node, "xlnx,lengthregwidth",
>> --
>> 2.17.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox