Re: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
On Sat, 2 Dec 2023 at 09:49, Justin Chen wrote:
>
>
>
> On 12/1/23 10:53 PM, Ard Biesheuvel wrote:
> > On Fri, 1 Dec 2023 at 23:59, Justin Chen wrote:
> >>
> >>
> >>
> >> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> >>> On Fri, 1 Dec 2023 09:25:59 -0800
> >>> Justin Chen wrote:
> >>>
> >>>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> >>>>> that there are no gaps between the stack frames is invalid.
> >>>>
> >>>> Thanks for the assistance. The gap between the stack frame depends on
> >>>> the function. Most do not have a gap. Some have 8 (as shown above), some
> >>>> have 12. A single assumption here is not going to work. I'm having a
> >>>> hard time finding out the reasoning for this gap. I tried disabling a
> >>>> bunch of gcc flags as well as -O2 and the gap still exists.
> >>>
> >>> That code was originally added because of some strange things that gcc did
> >>> with mcount (for example, it made a copy of the stack frame that it passed
> >>> to mcount, where the function graph tracer replaced the copy of the return
> >>> stack making the shadow stack go out of sync and crash). This was very
> >>> hard
> >>> to debug and I added this code to detect it if it happened again.
> >>>
> >>> Well it's been over a decade since that happened (2009).
> >>>
> >>> 71e308a239c09 ("function-graph: add stack frame test")
> >>>
> >>> I'm happy assuming that the compiler folks are aware of our tricks with
> >>> hijacking return calls and I don't expect it to happen again. We can just
> >>> rip out those checks. That is, if it's only causing false positives, I
> >>> don't think it's worth keeping around.
> >>>
> >>> Has it detected any real issues on the Arm platforms?
> >>>
> >>> -- Steve
> >>
> >> I am not familiar enough to make a call. But from my limited testing
> >> with ARM, I didn't see any issues. If you would like me to, I can submit
> >> a patch to remove the check entirely. Or maybe only disable it for ARM?
> >>
> >
> > Please try the fix I proposed first.
>
> Just tested it. Seems to do the trick.
Thanks
> Either solution works for me.
>
Given that this discussion is taking place in the context of the
report of an issue identified by GRAPH_FP_TEST, I don't see how
removing that would be a reasonable conclusion.
> FWIW I also experimented with LLVM, looks like function_graph just
> crashes regardless of the issue being discussed. The disassemble of
> LLVM[1] does something completely different.
>
LLVM does not support CONFIG_UNWINDER_FRAME_POINTER so the fact that
the prologue looks different is expected.
In the case below, the FP {r11} is correctly made to point to a {r11,
lr} tuple on the stack, so the codegen is correct AFAICT. But IIRC we
rely on unwind information for ftrace in this case, not the frame
pointer.
Could you be more specific about the crash?
>
> [1]
> LLVM dump
> c0c6faa0 :
> c0c6faa0: f0 4f 2d e9 push{r4, r5, r6, r7, r8, r9, r10, r11, lr}
> c0c6faa4: 1c b0 8d e2 add r11, sp, #28
> c0c6faa8: ac d0 4d e2 sub sp, sp, #172
> c0c6faac: 00 70 a0 e1 mov r7, r0
> c0c6fab0: c8 0c 04 e3 movwr0, #19656
> c0c6fab4: 80 02 4c e3 movtr0, #49792
> c0c6fab8: 03 50 a0 e1 mov r5, r3
> c0c6fabc: 00 00 90 e5 ldr r0, [r0]
> c0c6fac0: 02 a0 a0 e1 mov r10, r2
> c0c6fac4: 20 00 0b e5 str r0, [r11, #-32]
> c0c6fac8: 00 40 2d e9 stmdb sp!, {lr}
> c0c6facc: 4b 8b d6 eb bl 0xc0212800 <__gnu_mcount_nc> @ imm =
> #-10867412
Re: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
On Fri, 1 Dec 2023 at 23:59, Justin Chen wrote:
>
>
>
> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> > On Fri, 1 Dec 2023 09:25:59 -0800
> > Justin Chen wrote:
> >
> >>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> >>> that there are no gaps between the stack frames is invalid.
> >>
> >> Thanks for the assistance. The gap between the stack frame depends on
> >> the function. Most do not have a gap. Some have 8 (as shown above), some
> >> have 12. A single assumption here is not going to work. I'm having a
> >> hard time finding out the reasoning for this gap. I tried disabling a
> >> bunch of gcc flags as well as -O2 and the gap still exists.
> >
> > That code was originally added because of some strange things that gcc did
> > with mcount (for example, it made a copy of the stack frame that it passed
> > to mcount, where the function graph tracer replaced the copy of the return
> > stack making the shadow stack go out of sync and crash). This was very hard
> > to debug and I added this code to detect it if it happened again.
> >
> > Well it's been over a decade since that happened (2009).
> >
> >71e308a239c09 ("function-graph: add stack frame test")
> >
> > I'm happy assuming that the compiler folks are aware of our tricks with
> > hijacking return calls and I don't expect it to happen again. We can just
> > rip out those checks. That is, if it's only causing false positives, I
> > don't think it's worth keeping around.
> >
> > Has it detected any real issues on the Arm platforms?
> >
> > -- Steve
>
> I am not familiar enough to make a call. But from my limited testing
> with ARM, I didn't see any issues. If you would like me to, I can submit
> a patch to remove the check entirely. Or maybe only disable it for ARM?
>
Please try the fix I proposed first.
Re: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
On Fri, 1 Dec 2023 at 00:48, Justin Chen wrote:
>
> Hello,
>
> Ran into an odd bug that I am unsure what the solution is. Tested a few
> kernels versions and they all fail the same.
>
> FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
> enable HAVE_FUNCTION_GRAPH_FP_TEST"). This test fails when
> UNWINDER_FRAME_POINTER is enabled. Enable function_graph tracer and you
> should see a failure similar to below.
>
> [ 63.817239] [ cut here ]
> [ 63.822006] WARNING: CPU: 3 PID: 1185 at kernel/trace/fgraph.c:195
> ftrace_return_to_handler+0x228/0x374
> [ 63.831645] Bad frame pointer: expected d1e0df40, received d1e0df48
> [ 63.831645] from func packet_setsockopt return to c0b558f4
> [ 63.843801] Modules linked in: bdc udc_core
> [ 63.848246] CPU: 3 PID: 1185 Comm: udhcpc Not tainted
> 6.1.53-0.1pre-gf0bc552d12f8 #33
> [ 63.856209] Hardware name: Broadcom STB (Flattened Device Tree)
> [ 63.862227] Backtrace:
> [ 63.864761] dump_backtrace from show_stack+0x20/0x24
> [ 63.869982] r7:c031cd8c r6:0009 r5:0013 r4:c11c7fac
> [ 63.875736] show_stack from dump_stack_lvl+0x48/0x54
> [ 63.880929] dump_stack_lvl from dump_stack+0x18/0x1c
> [ 63.886111] r5:00c3 r4:c11bd92c
> [ 63.889764] dump_stack from __warn+0x88/0x130
> [ 63.894339] __warn from warn_slowpath_fmt+0x140/0x198
> [ 63.899631] r8:d1e0deac r7:c11bd958 r6:c031cd8c r5:c11bd92c r4:
> [ 63.906431] warn_slowpath_fmt from ftrace_return_to_handler+0x228/0x374
> [ 63.913294] r8:c3a8d840 r7:0002 r6:d1e0df48 r5:c2377a94 r4:c269a400
> [ 63.920095] ftrace_return_to_handler from return_to_handler+0xc/0x18
> [ 63.926699] r8:c0cd8ed0 r7:0008 r6:c418c500 r5:0004 r4:0107
> [ 63.933500] __sys_setsockopt from return_to_handler+0x0/0x18
> [ 63.939415] r8:c02002bc r7:0126 r6:0003 r5: r4:0004
> [ 63.946217] sys_setsockopt from return_to_handler+0x0/0x18
> [ 63.952053] ---[ end trace ]---
>
> Sure enough the top of the parent stack is off by 8. (Tested with
> gcc6.3/gcc8.3/gcc12.3)
> 6dcc :
> 6dcc: e1a0c00dmov ip, sp
> 6dd0: e24dd008sub sp, sp, #8 <==
> 6dd4: e92ddff0push{r4, r5, r6, r7, r8, r9, sl,
> fp, ip, lr, pc}
> 6dd8: e24cb00csub fp, ip, #12
> 6ddc: e24dd06csub sp, sp, #108@ 0x6c
> 6de0: e52de004push{lr}@ (str lr, [sp,
> #-4]!)
> 6de4: ebfebl 0 <__gnu_mcount_nc>
>
> I'm not quite sure why gcc is putting this extra 8 byte frame (maybe
> some optimization?), but it isn't being accounted for thus the
> FUNCTION_GRAPH_FP_TEST for arm fails. Note that only some functions do
> this. Function graph works with FUNCTION_GRAPH_FP_TEST disabled, so it
> looks the test is hitting false positives.
>
Thanks for the report.
It appears the sub instruction at 0x6dd0 correctly accounts for the
extra 8 bytes, so the frame pointer is valid. So it is our assumption
that there are no gaps between the stack frames is invalid.
Could you try the following change please?
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -235,8 +235,12 @@
return;
if (IS_ENABLED(CONFIG_UNWINDER_FRAME_POINTER)) {
- /* FP points one word below parent's top of stack */
- frame_pointer += 4;
+ /*
+* The top of stack of the parent is recorded in the stack
+* frame at offset [fp, #-8].
+*/
+ get_kernel_nofault(frame_pointer,
+ (unsigned long *)(frame_pointer - 8));
} else {
struct stackframe frame = {
.fp = frame_pointer,
Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote:
>
> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
> wrote:
> >
> >
> >
> > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > > wrote:
> > >>
> > >> Hi,
> > >
> > > Greg or Sasha won't know what to do with this. Not sure who follows
> > > the stable list either. Quentin sent the patch, but is not the author.
> > > Given the patch in question is about consistency between EFI memory
> > > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > > help (Ard B for starters).
> >
> > Ok thanks for the tips. I add Ard in the loop.
>
> Sigh. If it was only Ard I was suggesting I would have done that
> myself. Now everyone on the patch in question and relevant lists are
> Cc'ed.
>
Thanks for the cc.
> >
> > Ard, let me know if other people have to be directly added or if I have
> > to resend to another mailing list.
> >
> > thanks
> > alex
> >
> > >
> > >>
> > >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> > >> reserved-memory regions are no more "reserved" and make part of the
> > >> kernel System RAM. This causes allocation failure for devices which try
> > >> to take a reserved-memory region.
> > >>
> > >> It has been introduced by the following path:
> > >>
> > >> "fdt: Properly handle "no-map" field in the memory region
> > >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> > >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> > >>
Why was this backported? It doesn't look like a bugfix to me.
> > >> Reverting this patch it's fine.
> > >>
> > >> I add part of my DT (something is maybe wrong inside):
> > >>
> > >> memory@c000 {
> > >> reg = <0xc000 0x2000>;
> > >> };
> > >>
> > >> reserved-memory {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> ranges;
> > >>
> > >> gpu_reserved: gpu@d400 {
> > >> reg = <0xd400 0x400>;
> > >> no-map;
> > >> };
> > >> };
> > >>
> > >> Sorry if this issue has already been raised and discussed.
> > >>
Could you explain why it fails? The region is clearly part of system
memory, and tagged as no-map, so the patch in itself is not
unreasonable. However, we obviously have code that relies on how the
region is represented in /proc/iomem, so it would be helpful to get
some insight into why this is the case.
In any case, the mere fact that this causes a regression should be
sufficient justification to revert/withdraw it from v5.4, as I don't
see a reason why it was merged there in the first place. (It has no
fixes tag or cc:stable)
Re: [PATCH v2] arm64: vdso: remove commas between macro name and arguments
On Fri, 16 Apr 2021 at 22:35, Jian Cai wrote: > > LLVM's integrated assembler does not support using commas separating > the name and arguments in .macro. However, only spaces are used in the > manual page. This replaces commas between macro names and the subsequent > arguments with space in calls to clock_gettime_return to make it > compatible with IAS. > > Link: > https://sourceware.org/binutils/docs/as/Macro.html#Macro > https://github.com/ClangBuiltLinux/linux/issues/1349 > > Suggested-by: Ard Biesheuvel Please remove this tag - the only thing I suggested was to drop part of the original patch. > Signed-off-by: Jian Cai > --- > > Changes v1 -> v2: > Keep the comma in the macro definition to be consistent with other > definitions. > > arch/arm64/kernel/vdso/gettimeofday.S | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kernel/vdso/gettimeofday.S > b/arch/arm64/kernel/vdso/gettimeofday.S > index 856fee6d3512..b6faf8b5d1fe 100644 > --- a/arch/arm64/kernel/vdso/gettimeofday.S > +++ b/arch/arm64/kernel/vdso/gettimeofday.S > @@ -227,7 +227,7 @@ realtime: > seqcnt_check fail=realtime > get_ts_realtime res_sec=x10, res_nsec=x11, \ > clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > monotonic: > @@ -250,7 +250,7 @@ monotonic: > clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9 > > add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > monotonic_raw: > @@ -271,7 +271,7 @@ monotonic_raw: > clock_nsec=x15, nsec_to_sec=x9 > > add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > realtime_coarse: > -- > 2.31.1.368.gbe11c130af-goog >
Re: [PATCH] arm64: vdso: remove commas between macro name and arguments
On Fri, 16 Apr 2021 at 20:16, Jian Cai wrote: > > LLVM's integrated assembler does not support using commas separating > the name and arguments in .macro. However, only spaces are used in the > manual page. This replaces commas between macro names and the subsequent > arguments with space in calls to clock_gettime_return to make it > compatible with IAS. > > Link: > https://sourceware.org/binutils/docs/as/Macro.html#Macro > Signed-off-by: Jian Cai > --- > arch/arm64/kernel/vdso/gettimeofday.S | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/kernel/vdso/gettimeofday.S > b/arch/arm64/kernel/vdso/gettimeofday.S > index 856fee6d3512..7ee685d9adfc 100644 > --- a/arch/arm64/kernel/vdso/gettimeofday.S > +++ b/arch/arm64/kernel/vdso/gettimeofday.S > @@ -122,7 +122,7 @@ x_tmp .reqx8 > 9998: > .endm > > - .macro clock_gettime_return, shift=0 > + .macro clock_gettime_return shift=0 Are you sure the definition needs to be changed as well? The majority of GAS macros in arch/arm64 (if not all) use a comma after the identifier, so I would prefer not to deviate from that arbitrarily. Just look at $ git grep -E \.macro\\s+\\S+, arch/arm64/*.S > .if \shift == 1 > lsr x11, x11, x12 > .endif > @@ -227,7 +227,7 @@ realtime: > seqcnt_check fail=realtime > get_ts_realtime res_sec=x10, res_nsec=x11, \ > clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > monotonic: > @@ -250,7 +250,7 @@ monotonic: > clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9 > > add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > monotonic_raw: > @@ -271,7 +271,7 @@ monotonic_raw: > clock_nsec=x15, nsec_to_sec=x9 > > add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9 > - clock_gettime_return, shift=1 > + clock_gettime_return shift=1 > > ALIGN > realtime_coarse: > -- > 2.31.1.368.gbe11c130af-goog > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
>
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved region just before the memory is freed from memblock to the buddy
> > page allocator.
> >
> > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > values set by the memory map initialization which makes it necessary to
> > have a special treatment for such pages in pfn_valid() and
> > pfn_valid_within().
>
> I assume these pages are never given to the buddy, because we don't have
> a direct mapping. So to the kernel, it's essentially just like a memory
> hole with benefits.
>
> I can spot that we want to export such memory like any special memory
> thingy/hole in /proc/iomem -- "reserved", which makes sense.
>
> I would assume that MEMBLOCK_NOMAP is a special type of *reserved*
> memory. IOW, that for_each_reserved_mem_range() should already succeed
> on these as well -- we should mark anything that is MEMBLOCK_NOMAP
> implicitly as reserved. Or are there valid reasons not to do so? What
> can anyone do with that memory?
>
> I assume they are pretty much useless for the kernel, right? Like other
> reserved memory ranges.
>
On ARM, we need to know whether any physical regions that do not
contain system memory contain something with device semantics or not.
One of the examples is ACPI tables: these are in reserved memory, and
so they are not covered by the linear region. However, when the ACPI
core ioremap()s an arbitrary memory region, we don't know whether it
is mapping a memory region or a device region unless we keep track of
this in some way. (Device mappings require device attributes, but
firmware tables require memory attributes, as they might be accessed
using misaligned reads)
>
> >
> > Split out initialization of the reserved pages to a function with a
> > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> > reserved regions and mark struct pages for the NOMAP regions as
> > PageReserved.
> >
> > Signed-off-by: Mike Rapoport
> > ---
> > mm/memblock.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..6b7ea9d86310 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2002,6 +2002,26 @@ static unsigned long __init
> > __free_memory_core(phys_addr_t start,
> > return end_pfn - start_pfn;
> > }
> >
> > +static void __init memmap_init_reserved_pages(void)
> > +{
> > + struct memblock_region *region;
> > + phys_addr_t start, end;
> > + u64 i;
> > +
> > + /* initialize struct pages for the reserved regions */
> > + for_each_reserved_mem_range(i, , )
> > + reserve_bootmem_region(start, end);
> > +
> > + /* and also treat struct pages for the NOMAP regions as PageReserved
> > */
> > + for_each_mem_region(region) {
> > + if (memblock_is_nomap(region)) {
> > + start = region->base;
> > + end = start + region->size;
> > + reserve_bootmem_region(start, end);
> > + }
> > + }
> > +}
> > +
> > static unsigned long __init free_low_memory_core_early(void)
> > {
> > unsigned long count = 0;
> > @@ -2010,8 +2030,7 @@ static unsigned long __init
> > free_low_memory_core_early(void)
> >
> > memblock_clear_hotplug(0, -1);
> >
> > - for_each_reserved_mem_range(i, , )
> > - reserve_bootmem_region(start, end);
> > + memmap_init_reserved_pages();
> >
> > /*
> >* We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> >
>
>
> --
> Thanks,
>
> David / dhildenb
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
On Tue, 13 Apr 2021 at 07:43, Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
> arch/arm64/include/asm/assembler.h
>
> between commits:
>
> 27248fe1abb2 ("arm64: assembler: remove conditional NEON yield macros")
> 13150149aa6d ("arm64: fpsimd: run kernel mode NEON with softirqs disabled")
>
> from the arm64 tree
Those patches are on a topic branch 'for-next/neon-softirqs-disabled'
in the arm64 tree, so probably best to just pull that into kvm-arm and
fix the conflicts there.
> and commits:
>
> 8f4de66e247b ("arm64: asm: Provide set_sctlr_el2 macro")
> 755db23420a1 ("KVM: arm64: Generate final CTR_EL0 value when running in
> Protected mode")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/include/asm/assembler.h
> index ab569b0b45fc,34ddd8a0f3dd..
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@@ -15,7 -15,7 +15,8 @@@
> #include
>
> #include
> +#include
> + #include
> #include
> #include
> #include
> @@@ -701,25 -705,95 +714,33 @@@ USER(\label, ic ivau, \tmp2)
> // inval
> isb
> .endm
>
> + .macro set_sctlr_el1, reg
> + set_sctlr sctlr_el1, \reg
> + .endm
> +
> + .macro set_sctlr_el2, reg
> + set_sctlr sctlr_el2, \reg
> + .endm
> +
> -/*
> - * Check whether to yield to another runnable task from kernel mode NEON
> code
> - * (which runs with preemption disabled).
> - *
> - * if_will_cond_yield_neon
> - *// pre-yield patchup code
> - * do_cond_yield_neon
> - *// post-yield patchup code
> - * endif_yield_neon
> - *
> - * where is optional, and marks the point where execution will
> resume
> - * after a yield has been performed. If omitted, execution resumes right
> after
> - * the endif_yield_neon invocation. Note that the entire sequence, including
> - * the provided patchup code, will be omitted from the image if
> - * CONFIG_PREEMPTION is not defined.
> - *
> - * As a convenience, in the case where no patchup code is required, the
> above
> - * sequence may be abbreviated to
> - *
> - * cond_yield_neon
> - *
> - * Note that the patchup code does not support assembler directives that
> change
> - * the output section, any use of such directives is undefined.
> - *
> - * The yield itself consists of the following:
> - * - Check whether the preempt count is exactly 1 and a reschedule is also
> - * needed. If so, calling of preempt_enable() in kernel_neon_end() will
> - * trigger a reschedule. If it is not the case, yielding is pointless.
> - * - Disable and re-enable kernel mode NEON, and branch to the yield fixup
> - * code.
> - *
> - * This macro sequence may clobber all CPU state that is not guaranteed by
> the
> - * AAPCS to be preserved across an ordinary function call.
> - */
> -
> - .macro cond_yield_neon, lbl
> - if_will_cond_yield_neon
> - do_cond_yield_neon
> - endif_yield_neon\lbl
> - .endm
> -
> - .macro if_will_cond_yield_neon
> -#ifdef CONFIG_PREEMPTION
> - get_current_taskx0
> - ldr x0, [x0, #TSK_TI_PREEMPT]
> - sub x0, x0, #PREEMPT_DISABLE_OFFSET
> - cbz x0, .Lyield_\@
> - /* fall through to endif_yield_neon */
> - .subsection 1
> -.Lyield_\@ :
> -#else
> - .section".discard.cond_yield_neon", "ax"
> -#endif
> - .endm
> -
> - .macro do_cond_yield_neon
> - bl kernel_neon_end
> - bl kernel_neon_begin
> - .endm
> -
> - .macro endif_yield_neon, lbl
> - .ifnb \lbl
> - b \lbl
> - .else
> - b .Lyield_out_\@
> - .endif
> - .previous
> -.Lyield_out_\@ :
> - .endm
> -
> /*
> - * Check whether preempt-disabled code should yield as soon as it
> - * is able. This is the case if re-enabling preemption a single
> - * time results in a preempt count of zero, and the TIF_NEED_RESCHED
> - * flag is set. (Note that the latter is stored negated in the
> - * top word of the thread_info::preempt_count field)
> + * Check whether preempt/bh-disabled asm code should yield as soon as
> + * it is able. This is the case if we are currently running in task
> + * context, and either a softirq is pending, or the TIF_NEED_RESCHED
> + * flag is set and re-enabling
Re: [PATCH v6 1/1] use crc32 instead of md5 for hibernation e820 integrity check
On Mon, 12 Apr 2021 at 21:51, Chris von Recklinghausen wrote: > > On 4/12/21 3:27 PM, Ard Biesheuvel wrote: > > On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote: > >> On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote: > >>> On 4/12/21 1:45 PM, Eric Biggers wrote: > >>>> On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote: > >>>>> Suspend fails on a system in fips mode because md5 is used for the e820 > >>>>> integrity check and is not available. Use crc32 instead. > >>>>> > >>>>> This patch changes the integrity check algorithm from md5 to crc32. > >>>>> > >>>>> The purpose of the integrity check is to detect possible differences > >>>>> between the memory map used at the time when the hibernation image is > >>>>> about to be loaded into memory and the memory map used at the image > >>>>> creation time, because it is generally unsafe to load the image if the > >>>>> current memory map doesn't match the one used when it was created. so > >>>>> it is not intended as a cryptographic integrity check. > >>>> This still doesn't actually explain why a non-cryptographic checksum is > >>>> sufficient. "Detection of possible differences" could very well require > >>>> cryptographic authentication; it depends on whether malicious changes > >>>> need to be > >>>> detected or not. > >>> Hi Eric, > >>> > >>> The cases that the commit comments for 62a03defeabd mention are the same > >>> as > >>> for this patch, e.g. > >>> > >>> 1. Without this patch applied, it is possible that BIOS has > >>> provided an inconsistent memory map, but the resume kernel is > >>> still > >>> able to restore the image anyway(e.g, E820_RAM region is the > >>> superset > >>> of the previous one), although the system might be unstable. So > >>> this > >>> patch tries to treat any inconsistent e820 as illegal. > >>> > >>> 2. Another case is, this patch replies on comparing the e820_saved, > >>> but > >>> currently the e820_save might not be strictly the same across > >>> hibernation, even if BIOS has provided consistent e820 map - In > >>> theory mptable might modify the BIOS-provided e820_saved > >>> dynamically > >>> in early_reserve_e820_mpc_new, which would allocate a buffer from > >>> E820_RAM, and marks it from E820_RAM to E820_RESERVED). > >>> This is a potential and rare case we need to deal with in OS in > >>> the future. > >>> > >>> Maybe they should be added to the comments with this patch as well? In any > >>> case, the above comments only mention detecting consequences of BIOS > >>> issues/actions on the e820 map and not intrusions from attackers requiring > >>> cryptographic protection. Does that seem to be a reasonable explanation to > >>> you? If so I can add these to the commit comments. > >>> > >>> I'll make the other changes you suggest below. > >>> > >>> Thanks, > >>> > >> Those details are still missing the high-level point. Is this just meant > >> to > >> detect non-malicious changes (presumably caused by BIOS bugs), or is it > >> meant to > >> detect malicious changes? That's all that really needs to be mentioned. > >> > > This is not about BIOS bugs. Hibernation is deep suspend/resume > > grafted onto cold boot, and it is perfectly legal for the firmware to > > present a different memory map to the OS after a cold boot. It is > > Linux that decides that it can restore the entire system state from a > > swap file, and carry on as if the cold boot was just a [firmware > > assisted] suspend/resume. > > > > So forging collisions is *not* a concern here. Let's avoid accidental > > or malicious, as those adjectives seem to confuse some people. The > > bottom line is that there is no need to protect against deliberate > > attempts to hide the fact that the memory map has changed, and so > > there is no reason to use cryptographic hashes here. > > > How about : > > The check is intended to differentiate between a resume (which expects > an identical e820 map to the one saved in suspend), and a cold boot > (which need not have an identical e820 map to that saved in suspend if > any was done at all). It is not necessary here to protect against > deliberate attempts to hide the fact that the memory map has changed, so > crc32 is sufficient for detection. > Almost. Hibernation always occurs after a cold boot, but usually, the E820 memory map happens to be the same. How about """ The check is intended to detect whether the E820 memory map provided by the firmware after cold boot unexpectedly differs from the one that was in use when the hibernation image was created. In this case, the hibernation image cannot be restored, as it may cover memory regions that are no longer available to the OS. A non-cryptographic hash such as CRC-32 is sufficient to detect such inadvertent deviations. """
Re: [PATCH v6 1/1] use crc32 instead of md5 for hibernation e820 integrity check
On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote: > > On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote: > > On 4/12/21 1:45 PM, Eric Biggers wrote: > > > On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote: > > > > Suspend fails on a system in fips mode because md5 is used for the e820 > > > > integrity check and is not available. Use crc32 instead. > > > > > > > > This patch changes the integrity check algorithm from md5 to crc32. > > > > > > > > The purpose of the integrity check is to detect possible differences > > > > between the memory map used at the time when the hibernation image is > > > > about to be loaded into memory and the memory map used at the image > > > > creation time, because it is generally unsafe to load the image if the > > > > current memory map doesn't match the one used when it was created. so > > > > it is not intended as a cryptographic integrity check. > > > This still doesn't actually explain why a non-cryptographic checksum is > > > sufficient. "Detection of possible differences" could very well require > > > cryptographic authentication; it depends on whether malicious changes > > > need to be > > > detected or not. > > > > Hi Eric, > > > > The cases that the commit comments for 62a03defeabd mention are the same as > > for this patch, e.g. > > > > 1. Without this patch applied, it is possible that BIOS has > >provided an inconsistent memory map, but the resume kernel is still > >able to restore the image anyway(e.g, E820_RAM region is the superset > >of the previous one), although the system might be unstable. So this > >patch tries to treat any inconsistent e820 as illegal. > > > > 2. Another case is, this patch replies on comparing the e820_saved, but > >currently the e820_save might not be strictly the same across > >hibernation, even if BIOS has provided consistent e820 map - In > >theory mptable might modify the BIOS-provided e820_saved dynamically > >in early_reserve_e820_mpc_new, which would allocate a buffer from > >E820_RAM, and marks it from E820_RAM to E820_RESERVED). > >This is a potential and rare case we need to deal with in OS in > >the future. > > > > Maybe they should be added to the comments with this patch as well? In any > > case, the above comments only mention detecting consequences of BIOS > > issues/actions on the e820 map and not intrusions from attackers requiring > > cryptographic protection. Does that seem to be a reasonable explanation to > > you? If so I can add these to the commit comments. > > > > I'll make the other changes you suggest below. > > > > Thanks, > > > > Those details are still missing the high-level point. Is this just meant to > detect non-malicious changes (presumably caused by BIOS bugs), or is it meant > to > detect malicious changes? That's all that really needs to be mentioned. > This is not about BIOS bugs. Hibernation is deep suspend/resume grafted onto cold boot, and it is perfectly legal for the firmware to present a different memory map to the OS after a cold boot. It is Linux that decides that it can restore the entire system state from a swap file, and carry on as if the cold boot was just a [firmware assisted] suspend/resume. So forging collisions is *not* a concern here. Let's avoid accidental or malicious, as those adjectives seem to confuse some people. The bottom line is that there is no need to protect against deliberate attempts to hide the fact that the memory map has changed, and so there is no reason to use cryptographic hashes here.
Re: [PATCH v2 1/1] efi/dev-path-parser: Switch to use for_each_acpi_dev_match()
On Sun, 4 Apr 2021 at 20:12, Andy Shevchenko wrote:
>
> Switch to use for_each_acpi_dev_match() instead of home grown analogue.
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> v2: fixed refcounting
> (example from which I took the v1 approach has been broken, fix is sent
> :-)
Queued up in efi/next, thanks
> drivers/firmware/efi/dev-path-parser.c | 49 ++
> 1 file changed, 18 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/firmware/efi/dev-path-parser.c
> b/drivers/firmware/efi/dev-path-parser.c
> index 5c9625e552f4..10d4457417a4 100644
> --- a/drivers/firmware/efi/dev-path-parser.c
> +++ b/drivers/firmware/efi/dev-path-parser.c
> @@ -12,52 +12,39 @@
> #include
> #include
>
> -struct acpi_hid_uid {
> - struct acpi_device_id hid[2];
> - char uid[11]; /* UINT_MAX + null byte */
> -};
> -
> -static int __init match_acpi_dev(struct device *dev, const void *data)
> -{
> - struct acpi_hid_uid hid_uid = *(const struct acpi_hid_uid *)data;
> - struct acpi_device *adev = to_acpi_device(dev);
> -
> - if (acpi_match_device_ids(adev, hid_uid.hid))
> - return 0;
> -
> - if (adev->pnp.unique_id)
> - return !strcmp(adev->pnp.unique_id, hid_uid.uid);
> - else
> - return !strcmp("0", hid_uid.uid);
> -}
> -
> static long __init parse_acpi_path(const struct efi_dev_path *node,
>struct device *parent, struct device
> **child)
> {
> - struct acpi_hid_uid hid_uid = {};
> + char hid[ACPI_ID_LEN], uid[11]; /* UINT_MAX + null byte */
> + struct acpi_device *adev;
> struct device *phys_dev;
>
> if (node->header.length != 12)
> return -EINVAL;
>
> - sprintf(hid_uid.hid[0].id, "%c%c%c%04X",
> + sprintf(hid, "%c%c%c%04X",
> 'A' + ((node->acpi.hid >> 10) & 0x1f) - 1,
> 'A' + ((node->acpi.hid >> 5) & 0x1f) - 1,
> 'A' + ((node->acpi.hid >> 0) & 0x1f) - 1,
> node->acpi.hid >> 16);
> - sprintf(hid_uid.uid, "%u", node->acpi.uid);
> -
> - *child = bus_find_device(_bus_type, NULL, _uid,
> -match_acpi_dev);
> - if (!*child)
> + sprintf(uid, "%u", node->acpi.uid);
> +
> + for_each_acpi_dev_match(adev, hid, NULL, -1) {
> + if (adev->pnp.unique_id && !strcmp(adev->pnp.unique_id, uid))
> + break;
> + if (!adev->pnp.unique_id && node->acpi.uid == 0)
> + break;
> + acpi_dev_put(adev);
> + }
> + if (!adev)
> return -ENODEV;
>
> - phys_dev = acpi_get_first_physical_node(to_acpi_device(*child));
> + phys_dev = acpi_get_first_physical_node(adev);
> if (phys_dev) {
> - get_device(phys_dev);
> - put_device(*child);
> - *child = phys_dev;
> - }
> + *child = get_device(phys_dev);
> + acpi_dev_put(adev);
> + } else
> + *child = >dev;
>
> return 0;
> }
> --
> 2.31.1
>
Re: static_branch/jump_label vs branch merging
On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra wrote:
>
> Hi!
>
> Given code like:
>
> DEFINE_STATIC_KEY_FALSE(sched_schedstats);
>
> #define schedstat_enabled()
> static_branch_unlikely(_schedstats)
> #define schedstat_set(var, val) do { if (schedstat_enabled()) { var =
> (val); } } while (0)
> #define __schedstat_set(var, val) do { var = (val); } while (0)
>
> void foo(void)
> {
> struct task_struct *p = current;
>
> schedstat_set(p->se.statistics.wait_start, 0);
> schedstat_set(p->se.statistics.sleep_start, 0);
> schedstat_set(p->se.statistics.block_start, 0);
> }
>
> Where the static_branch_unlikely() ends up being:
>
> static __always_inline bool arch_static_branch(struct static_key * const key,
> const bool branch)
> {
> asm_volatile_goto("1:"
> ".byte " __stringify(BYTES_NOP5) "\n\t"
> ".pushsection __jump_table, \"aw\" \n\t"
> _ASM_ALIGN "\n\t"
> ".long 1b - ., %l[l_yes] - . \n\t"
> _ASM_PTR "%c0 + %c1 - .\n\t"
> ".popsection \n\t"
> : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
> l_yes:
> return true;
> }
>
> The compiler gives us code like:
>
> a290 :
> a290: 65 48 8b 04 25 00 00 00 00 mov%gs:0x0,%rax a295:
> R_X86_64_32S current_task
> a299: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> a29e: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> a2a3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> a2a8: c3 retq
> a2a9: 48 c7 80 28 01 00 00 00 00 00 00movq
> $0x0,0x128(%rax)
> a2b4: eb e8 jmpa29e
> a2b6: 48 c7 80 58 01 00 00 00 00 00 00movq
> $0x0,0x158(%rax)
> a2c1: eb e0 jmpa2a3
> a2c3: 48 c7 80 70 01 00 00 00 00 00 00movq
> $0x0,0x170(%rax)
> a2ce: c3 retq
>
>
> Now, in this case I can easily rewrite foo like:
>
> void foo2(void)
> {
> struct task_struct *p = current;
>
> if (schedstat_enabled()) {
> __schedstat_set(p->se.statistics.wait_start, 0);
> __schedstat_set(p->se.statistics.sleep_start, 0);
> __schedstat_set(p->se.statistics.block_start, 0);
> }
> }
>
> Which gives the far more reasonable:
>
> a2d0 :
> a2d0: 65 48 8b 04 25 00 00 00 00 mov%gs:0x0,%rax a2d5:
> R_X86_64_32S current_task
> a2d9: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> a2de: c3 retq
> a2df: 48 c7 80 28 01 00 00 00 00 00 00movq
> $0x0,0x128(%rax)
> a2ea: 48 c7 80 58 01 00 00 00 00 00 00movq
> $0x0,0x158(%rax)
> a2f5: 48 c7 80 70 01 00 00 00 00 00 00movq
> $0x0,0x170(%rax)
> a300: c3 retq
>
> But I've found a few sites where this isn't so trivial.
>
> Is there *any* way in which we can have the compiler recognise that the
> asm_goto only depends on its arguments and have it merge the branches
> itself?
>
> I do realize that asm-goto being volatile this is a fairly huge ask, but
> I figured I should at least raise the issue, if only to raise awareness.
>
Wouldn't that require the compiler to interpret the contents of the asm() block?
Re: [PATCH v5 14/18] arm64: add __nocfi to functions that jump to a physical address
On Tue, 6 Apr 2021 at 13:54, Mark Rutland wrote: > > [adding Ard for EFI runtime services bits] > > On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote: > > Disable CFI checking for functions that switch to linear mapping and > > make an indirect call to a physical address, since the compiler only > > understands virtual addresses and the CFI check for such indirect calls > > would always fail. > > What does physical vs virtual have to do with this? Does the address > actually matter, or is this just a general thing that when calling an > assembly function we won't have a trampoline that the caller expects? > > I wonder if we need to do something with asmlinkage here, perhaps? > > I didn't spot anything in the seriues handling EFI runtime services > calls, and I strongly suspect we need to do something for those, unless > they're handled implicitly by something else. > All indirect EFI calls are routed via a asm helper that I originally added to check whether x18 was corrupted by the firmware. So from the caller side, we should be fine. All callees are addresses that are provided by the firmware via tables in memory, so I would assume that this addresses the callee side as well. AFAICT, it is never left up to the compiler to emit these indirect calls, or take the address of a firmware routine. But a test would be nice :-) > > Signed-off-by: Sami Tolvanen > > Reviewed-by: Kees Cook > > --- > > arch/arm64/include/asm/mmu_context.h | 2 +- > > arch/arm64/kernel/cpu-reset.h| 8 > > arch/arm64/kernel/cpufeature.c | 2 +- > > 3 files changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/arch/arm64/include/asm/mmu_context.h > > b/arch/arm64/include/asm/mmu_context.h > > index 386b96400a57..d3cef9133539 100644 > > --- a/arch/arm64/include/asm/mmu_context.h > > +++ b/arch/arm64/include/asm/mmu_context.h > > @@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void) > > * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible > > PGD, > > * avoiding the possibility of conflicting TLB entries being allocated. > > */ > > -static inline void cpu_replace_ttbr1(pgd_t *pgdp) > > +static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp) > > Given these are inlines, what's the effect when these are inlined into a > function that would normally use CFI? Does CFI get supressed for the > whole function, or just the bit that got inlined? > > Is there an attribute that we could place on a function pointer to tell > the compiler to not check calls via that pointer? If that existed we'd > be able to scope this much more tightly. > I agree that it would be very helpful to be able to define a function pointer type that is exempt from CFI checks.
Re: Fix hibernation in FIPS mode?
On Thu, 1 Apr 2021 at 15:54, Chris von Recklinghausen
wrote:
>
> On 4/1/21 9:38 AM, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >> On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> >>> On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> >>>> On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> >>>>> On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> >>>>>> On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui
> >>>>>> wrote:
> >>>>>>> Hi,
> >>>>>>> MD5 was marked incompliant with FIPS in 2009:
> >>>>>>> a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed
> >>>>>>> in fips mode")
> >>>>>>> a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
> >>>>>>>
> >>>>>>> But hibernation_e820_save() is still using MD5, and fails in FIPS mode
> >>>>>>> due to the 2018 patch:
> >>>>>>> 749fa17093ff ("PM / hibernate: Check the success of generating md5
> >>>>>>> digest before hibernation")
> >>>>>>>
> >>>>>>> As a result, hibernation doesn't work when FIPS is on.
> >>>>>>>
> >>>>>>> Do you think if hibernation_e820_save() should be changed to use a
> >>>>>>> FIPS-compliant algorithm like SHA-1?
> >>>>>> I would say yes, it should.
> >>>>>>
> >>>>>>> PS, currently it looks like FIPS mode is broken in the mainline:
> >>>>>>> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
> >>>>> FYI, SHA-1 is not a good choice, it is only permitted in HMAC
> >>>>> constructions and only for specified uses. If you need to change
> >>>>> algorithm you should go straight to SHA-2 or SHA-3 based hashes.
> >>>>>
> >>>> What is the reason for using a [broken] cryptographic hash here? if
> >>>> this is just an integrity check, better use CRC32
> > Not really.
> >
> > CRC32 is not really sufficient for integrity checking here AFAICS. It
> > might be made a fallback option if MD5 is not available, but making it
> > the default would be somewhat over the top IMO.
>
>
> Would ghash be a better choice? It produces the same size digest as md5.
>
No, ghash is a MAC not a hash. It should only ever be used with GCM
and nowhere else.
> Does anyone have any other suggestions of algorithms to try?
>
Just use crc32
Re: Fix hibernation in FIPS mode?
On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >
> > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > >
> > > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > > > On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > > > > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > > > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > > MD5 was marked incompliant with FIPS in 2009:
> > > > > > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged
> > > > > > > fips_allowed in fips mode")
> > > > > > > a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
> > > > > > >
> > > > > > > But hibernation_e820_save() is still using MD5, and fails in FIPS
> > > > > > > mode
> > > > > > > due to the 2018 patch:
> > > > > > > 749fa17093ff ("PM / hibernate: Check the success of generating
> > > > > > > md5 digest before hibernation")
> > > > > > >
> > > > > > > As a result, hibernation doesn't work when FIPS is on.
> > > > > > >
> > > > > > > Do you think if hibernation_e820_save() should be changed to use a
> > > > > > > FIPS-compliant algorithm like SHA-1?
> > > > > >
> > > > > > I would say yes, it should.
> > > > > >
> > > > > > > PS, currently it looks like FIPS mode is broken in the mainline:
> > > > > > > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
> > > > >
> > > > > FYI, SHA-1 is not a good choice, it is only permitted in HMAC
> > > > > constructions and only for specified uses. If you need to change
> > > > > algorithm you should go straight to SHA-2 or SHA-3 based hashes.
> > > > >
> > > >
> > > > What is the reason for using a [broken] cryptographic hash here? if
> > > > this is just an integrity check, better use CRC32
>
> Not really.
>
> CRC32 is not really sufficient for integrity checking here AFAICS. It
> might be made a fallback option if MD5 is not available, but making it
> the default would be somewhat over the top IMO.
>
> > > If the integrity check is used exclusively to verify there were no
> > > accidental changes and is not used as a security measure, by all means
> > > I agree that using crc32 is a better idea.
> > >
> >
> > Looking at 62a03defeabd58f74e07ca030d6c21e069d4d88e which introduced
> > this, it is only a best effort check which is simply omitted if md5
> > happens to be unavailable, so there is definitely no need for crypto
> > here.
>
> Yes, it is about integrity checking only. No, CRC32 is not equivalent
> to MD5 in that respect AFAICS.
>
There are two possibilities:
- we care about an adversary attempting to forge a collision, in which
case you need a cryptographic hash which is not broken;
- we only care about integrity, in which case crypto is overkill, and
CRC32 is sufficient. (Note that the likelihood of an honest,
inadvertent modification not being caught by CRC32 is 1 in 4 billion)
MD5 does not meet either requirement, given that it is known to be
broken, and overkill for simple integrity checks. MD5 should be phased
out and removed, and moving this code onto the correct abstraction
would be a reasonable step towards that goal.
Re: [PATCH 1/1] use crc32 instead of md5 for hibernation e820 integrity check
On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
> >
> > Fixes: 62a03defeabd ("PM / hibernate: Verify the consistent of e820 memory
> > map
> >by md5 digest")
> > Signed-off-by: Chris von Recklinghausen
> > ---
> > arch/x86/power/hibernate.c | 31 +--
> > 1 file changed, 17 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> > index cd3914fc9f3d..6a3f4e32e49c 100644
> > --- a/arch/x86/power/hibernate.c
> > +++ b/arch/x86/power/hibernate.c
> > @@ -55,31 +55,31 @@ int pfn_is_nosave(unsigned long pfn)
> > }
> >
> >
> > -#define MD5_DIGEST_SIZE 16
> > +#define CRC32_DIGEST_SIZE 16
> >
> > struct restore_data_record {
> > unsigned long jump_address;
> > unsigned long jump_address_phys;
> > unsigned long cr3;
> > unsigned long magic;
> > - u8 e820_digest[MD5_DIGEST_SIZE];
> > + u8 e820_digest[CRC32_DIGEST_SIZE];
> > };
>
> No.
>
> CRC32 was used here before and it was deemed insufficient.
>
Why? The git commit log does not have an explanation of this.
> Please find a different way to address this issue.
>
> > -#if IS_BUILTIN(CONFIG_CRYPTO_MD5)
> > +#if IS_BUILTIN(CONFIG_CRYPTO_CRC32)
> > /**
> > - * get_e820_md5 - calculate md5 according to given e820 table
> > + * get_e820_crc32 - calculate crc32 according to given e820 table
> > *
> > * @table: the e820 table to be calculated
> > - * @buf: the md5 result to be stored to
> > + * @buf: the crc32 result to be stored to
> > */
> > -static int get_e820_md5(struct e820_table *table, void *buf)
> > +static int get_e820_crc32(struct e820_table *table, void *buf)
> > {
> > struct crypto_shash *tfm;
> > struct shash_desc *desc;
> > int size;
> > int ret = 0;
> >
> > - tfm = crypto_alloc_shash("md5", 0, 0);
> > + tfm = crypto_alloc_shash("crc32", 0, 0);
> > if (IS_ERR(tfm))
> > return -ENOMEM;
> >
> > @@ -107,24 +107,24 @@ static int get_e820_md5(struct e820_table *table,
> > void *buf)
> >
> > static int hibernation_e820_save(void *buf)
> > {
> > - return get_e820_md5(e820_table_firmware, buf);
> > + return get_e820_crc32(e820_table_firmware, buf);
> > }
> >
> > static bool hibernation_e820_mismatch(void *buf)
> > {
> > int ret;
> > - u8 result[MD5_DIGEST_SIZE];
> > + u8 result[CRC32_DIGEST_SIZE];
> >
> > - memset(result, 0, MD5_DIGEST_SIZE);
> > + memset(result, 0, CRC32_DIGEST_SIZE);
> > /* If there is no digest in suspend kernel, let it go. */
> > - if (!memcmp(result, buf, MD5_DIGEST_SIZE))
> > + if (!memcmp(result, buf, CRC32_DIGEST_SIZE))
> > return false;
> >
> > - ret = get_e820_md5(e820_table_firmware, result);
> > + ret = get_e820_crc32(e820_table_firmware, result);
> > if (ret)
> > return true;
> >
> > - return memcmp(result, buf, MD5_DIGEST_SIZE) ? true : false;
> > + return memcmp(result, buf, CRC32_DIGEST_SIZE) ? true : false;
> > }
> > #else
> > static int hibernation_e820_save(void *buf)
> > @@ -134,7 +134,7 @@ static int hibernation_e820_save(void *buf)
> >
> > static bool hibernation_e820_mismatch(void *buf)
> > {
> > - /* If md5 is not builtin for restore kernel, let it go. */
> > + /* If crc32 is not builtin for restore kernel, let it go. */
> > return false;
> > }
> > #endif
> > @@ -160,6 +160,9 @@ int arch_hibernation_header_save(void *addr, unsigned
> > int max_size)
> > rdr->jump_address = (unsigned long)restore_registers;
> > rdr->jump_address_phys = __pa_symbol(restore_registers);
> >
> > + /* crc32 digest size is 4 but digest buffer size is 16 so zero it
> > all */
> > + memset(rdr->e820_digest, 0, CRC32_DIGEST_SIZE);
> > +
> > /*
> > * The restore code fixes up CR3 and CR4 in the following sequence:
> > *
> > --
> > 2.18.1
> >
Re: Fix hibernation in FIPS mode?
On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > > > Hi,
> > > > > MD5 was marked incompliant with FIPS in 2009:
> > > > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed
> > > > > in fips mode")
> > > > > a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
> > > > >
> > > > > But hibernation_e820_save() is still using MD5, and fails in FIPS mode
> > > > > due to the 2018 patch:
> > > > > 749fa17093ff ("PM / hibernate: Check the success of generating md5
> > > > > digest before hibernation")
> > > > >
> > > > > As a result, hibernation doesn't work when FIPS is on.
> > > > >
> > > > > Do you think if hibernation_e820_save() should be changed to use a
> > > > > FIPS-compliant algorithm like SHA-1?
> > > >
> > > > I would say yes, it should.
> > > >
> > > > > PS, currently it looks like FIPS mode is broken in the mainline:
> > > > > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
> > >
> > > FYI, SHA-1 is not a good choice, it is only permitted in HMAC
> > > constructions and only for specified uses. If you need to change
> > > algorithm you should go straight to SHA-2 or SHA-3 based hashes.
> > >
> >
> > What is the reason for using a [broken] cryptographic hash here? if
> > this is just an integrity check, better use CRC32
>
> If the integrity check is used exclusively to verify there were no
> accidental changes and is not used as a security measure, by all means
> I agree that using crc32 is a better idea.
>
Looking at 62a03defeabd58f74e07ca030d6c21e069d4d88e which introduced
this, it is only a best effort check which is simply omitted if md5
happens to be unavailable, so there is definitely no need for crypto
here.
Re: [PATCH 6/8] drivers: firmware: efi: libstub: enable generic commandline
(+ Arvind)
On Tue, 30 Mar 2021 at 19:57, Daniel Walker wrote:
>
> This adds code to handle the generic command line changes.
> The efi code appears that it doesn't benefit as much from this design
> as it could.
>
> For example, if you had a prepend command line with "nokaslr" then
> you might be helpful to re-enable it in the boot loader or dts,
> but there appears to be no way to re-enable kaslr or some of the
> other options.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Daniel Walker
> ---
> .../firmware/efi/libstub/efi-stub-helper.c| 35 +++
> drivers/firmware/efi/libstub/efi-stub.c | 7
> drivers/firmware/efi/libstub/efistub.h| 1 +
> drivers/firmware/efi/libstub/x86-stub.c | 13 +--
> 4 files changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
> b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index aa8da0a49829..c155837cedc9 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include /* For CONSOLE_LOGLEVEL_* */
> +#include
> #include
> #include
>
> @@ -172,6 +173,40 @@ int efi_printk(const char *fmt, ...)
> return printed;
> }
>
> +/**
> + * efi_handle_cmdline() - handle adding in building parts of the command line
> + * @cmdline: kernel command line
> + *
> + * Add in the generic parts of the commandline and start the parsing of the
> + * command line.
> + *
> + * Return: status code
> + */
> +efi_status_t efi_handle_cmdline(char const *cmdline)
> +{
> + efi_status_t status;
> +
> + status = efi_parse_options(CMDLINE_PREPEND);
> + if (status != EFI_SUCCESS) {
> + efi_err("Failed to parse options\n");
> + return status;
> + }
Even though I am not a fan of the 'success handling' pattern,
duplicating the exact same error handling three times is not great
either. Could we reuse more of the code here?
> +
> + status = efi_parse_options(IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) ? "" :
> cmdline);
What is the point of calling efi_parse_options() with an empty string?
> + if (status != EFI_SUCCESS) {
> + efi_err("Failed to parse options\n");
> + return status;
> + }
> +
> + status = efi_parse_options(CMDLINE_APPEND);
> + if (status != EFI_SUCCESS) {
> + efi_err("Failed to parse options\n");
> + return status;
> + }
> +
> + return EFI_SUCCESS;
> +}
> +
> /**
> * efi_parse_options() - Parse EFI command line options
> * @cmdline: kernel command line
> diff --git a/drivers/firmware/efi/libstub/efi-stub.c
> b/drivers/firmware/efi/libstub/efi-stub.c
> index 26e69788f27a..760480248adf 100644
> --- a/drivers/firmware/efi/libstub/efi-stub.c
> +++ b/drivers/firmware/efi/libstub/efi-stub.c
> @@ -172,6 +172,12 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
> goto fail;
> }
>
> +#ifdef CONFIG_GENERIC_CMDLINE
> + status = efi_handle_cmdline(cmdline_ptr);
> + if (status != EFI_SUCCESS) {
> + goto fail_free_cmdline;
> + }
> +#else
> if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
> IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
Does this mean CONFIG_GENERIC_CMDLINE does not replace CMDLINE_EXTEND
/ CMDLINE_FORCE etc, but introduces yet another variant on top of
those?
That does not seem like an improvement to me. I think it is great that
you are cleaning this up, but only if it means we can get rid of the
old implementation.
> cmdline_size == 0) {
> @@ -189,6 +195,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
> goto fail_free_cmdline;
> }
> }
> +#endif
>
> efi_info("Booting Linux Kernel...\n");
>
> diff --git a/drivers/firmware/efi/libstub/efistub.h
> b/drivers/firmware/efi/libstub/efistub.h
> index cde0a2ef507d..07c7f9fdfffc 100644
> --- a/drivers/firmware/efi/libstub/efistub.h
> +++ b/drivers/firmware/efi/libstub/efistub.h
> @@ -800,6 +800,7 @@ efi_status_t efi_relocate_kernel(unsigned long
> *image_addr,
> unsigned long alignment,
> unsigned long min_addr);
>
> +efi_status_t efi_handle_cmdline(char const *cmdline);
> efi_status_t efi_parse_options(char const *cmdline);
>
> void efi_parse_option_graphics(char *option);
> diff --git a/drivers/firmware/efi/libstub/x86-stub.c
> b/drivers/firmware/efi/libstub/x86-stub.c
> index f14c4ff5839f..30ad8fb7122d 100644
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -673,6 +673,8 @@ unsigned long efi_main(efi_handle_t handle,
> unsigned long bzimage_addr = (unsigned long)startup_32;
> unsigned long buffer_start, buffer_end;
> struct setup_header *hdr = _params->hdr;
> +
Re: Fix hibernation in FIPS mode?
On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > Hi,
> > > MD5 was marked incompliant with FIPS in 2009:
> > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in
> > > fips mode")
> > > a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
> > >
> > > But hibernation_e820_save() is still using MD5, and fails in FIPS mode
> > > due to the 2018 patch:
> > > 749fa17093ff ("PM / hibernate: Check the success of generating md5 digest
> > > before hibernation")
> > >
> > > As a result, hibernation doesn't work when FIPS is on.
> > >
> > > Do you think if hibernation_e820_save() should be changed to use a
> > > FIPS-compliant algorithm like SHA-1?
> >
> > I would say yes, it should.
> >
> > > PS, currently it looks like FIPS mode is broken in the mainline:
> > > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
>
>
> FYI, SHA-1 is not a good choice, it is only permitted in HMAC
> constructions and only for specified uses. If you need to change
> algorithm you should go straight to SHA-2 or SHA-3 based hashes.
>
What is the reason for using a [broken] cryptographic hash here? if
this is just an integrity check, better use CRC32
Re: [PATCH 5.11 225/254] arm64/mm: define arch_get_mappable_range()
(+ Pavel)
On Mon, 29 Mar 2021 at 15:42, Greg Kroah-Hartman
wrote:
>
> On Mon, Mar 29, 2021 at 03:08:52PM +0200, Ard Biesheuvel wrote:
> > On Mon, 29 Mar 2021 at 12:12, Greg Kroah-Hartman
> > wrote:
> > >
> > > On Mon, Mar 29, 2021 at 03:05:25PM +0530, Naresh Kamboju wrote:
> > > > On Mon, 29 Mar 2021 at 14:10, Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > From: Anshuman Khandual
> > > > >
> > > > > [ Upstream commit 03aaf83fba6e5af08b5dd174c72edee9b7d9ed9b ]
> > > > >
> > > > > This overrides arch_get_mappable_range() on arm64 platform which will
> > > > > be
> > > > > used with recently added generic framework. It drops
> > > > > inside_linear_region() and subsequent check in arch_add_memory()
> > > > > which are
> > > > > no longer required. It also adds a VM_BUG_ON() check that would
> > > > > ensure
> > > > > that mhp_range_allowed() has already been called.
> > > > >
> > > > > Link:
> > > > > https://lkml.kernel.org/r/1612149902-7867-3-git-send-email-anshuman.khand...@arm.com
> > > > > Signed-off-by: Anshuman Khandual
> > > > > Reviewed-by: David Hildenbrand
> > > > > Reviewed-by: Catalin Marinas
> > > > > Cc: Will Deacon
> > > > > Cc: Ard Biesheuvel
> > > > > Cc: Mark Rutland
> > > > > Cc: Heiko Carstens
> > > > > Cc: Jason Wang
> > > > > Cc: Jonathan Cameron
> > > > > Cc: "Michael S. Tsirkin"
> > > > > Cc: Michal Hocko
> > > > > Cc: Oscar Salvador
> > > > > Cc: Pankaj Gupta
> > > > > Cc: Pankaj Gupta
> > > > > Cc: teawater
> > > > > Cc: Vasily Gorbik
> > > > > Cc: Wei Yang
> > > > > Signed-off-by: Andrew Morton
> > > > > Signed-off-by: Linus Torvalds
> > > > > Signed-off-by: Sasha Levin
> > > > > ---
> > > > > arch/arm64/mm/mmu.c | 15 +++
> > > > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > > > index 6f0648777d34..92b3be127796 100644
> > > > > --- a/arch/arm64/mm/mmu.c
> > > > > +++ b/arch/arm64/mm/mmu.c
> > > > > @@ -1443,16 +1443,19 @@ static void __remove_pgd_mapping(pgd_t
> > > > > *pgdir, unsigned long start, u64 size)
> > > > > free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> > > > > }
> > > > >
> > > > > -static bool inside_linear_region(u64 start, u64 size)
> > > > > +struct range arch_get_mappable_range(void)
> > > > > {
> > > > > + struct range mhp_range;
> > > > > +
> > > > > /*
> > > > > * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END
> > > > > - 1)]
> > > > > * accommodating both its ends but excluding PAGE_END. Max
> > > > > physical
> > > > > * range which can be mapped inside this linear mapping
> > > > > range, must
> > > > > * also be derived from its end points.
> > > > > */
> > > > > - return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> > > > > - (start + size - 1) <= __pa(PAGE_END - 1);
> > > > > + mhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
> > > > > + mhp_range.end = __pa(PAGE_END - 1);
> > > > > + return mhp_range;
> > > > > }
> > > > >
> > > > > int arch_add_memory(int nid, u64 start, u64 size,
> > > > > @@ -1460,11 +1463,7 @@ int arch_add_memory(int nid, u64 start, u64
> > > > > size,
> > > > > {
> > > > > int ret, flags = 0;
> > > > >
> > > > > - if (!inside_linear_region(start, size)) {
> > > > > - pr_err("[%llx %llx] is outside linear mapping
> > > > > region\n", start, start + size);
> > > > > - return -EINVAL;
> > > > > - }
> > > > > -
> > > > > + VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > > > &
Re: [PATCH 5.11 225/254] arm64/mm: define arch_get_mappable_range()
On Mon, 29 Mar 2021 at 12:12, Greg Kroah-Hartman
wrote:
>
> On Mon, Mar 29, 2021 at 03:05:25PM +0530, Naresh Kamboju wrote:
> > On Mon, 29 Mar 2021 at 14:10, Greg Kroah-Hartman
> > wrote:
> > >
> > > From: Anshuman Khandual
> > >
> > > [ Upstream commit 03aaf83fba6e5af08b5dd174c72edee9b7d9ed9b ]
> > >
> > > This overrides arch_get_mappable_range() on arm64 platform which will be
> > > used with recently added generic framework. It drops
> > > inside_linear_region() and subsequent check in arch_add_memory() which are
> > > no longer required. It also adds a VM_BUG_ON() check that would ensure
> > > that mhp_range_allowed() has already been called.
> > >
> > > Link:
> > > https://lkml.kernel.org/r/1612149902-7867-3-git-send-email-anshuman.khand...@arm.com
> > > Signed-off-by: Anshuman Khandual
> > > Reviewed-by: David Hildenbrand
> > > Reviewed-by: Catalin Marinas
> > > Cc: Will Deacon
> > > Cc: Ard Biesheuvel
> > > Cc: Mark Rutland
> > > Cc: Heiko Carstens
> > > Cc: Jason Wang
> > > Cc: Jonathan Cameron
> > > Cc: "Michael S. Tsirkin"
> > > Cc: Michal Hocko
> > > Cc: Oscar Salvador
> > > Cc: Pankaj Gupta
> > > Cc: Pankaj Gupta
> > > Cc: teawater
> > > Cc: Vasily Gorbik
> > > Cc: Wei Yang
> > > Signed-off-by: Andrew Morton
> > > Signed-off-by: Linus Torvalds
> > > Signed-off-by: Sasha Levin
> > > ---
> > > arch/arm64/mm/mmu.c | 15 +++
> > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 6f0648777d34..92b3be127796 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -1443,16 +1443,19 @@ static void __remove_pgd_mapping(pgd_t *pgdir,
> > > unsigned long start, u64 size)
> > > free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> > > }
> > >
> > > -static bool inside_linear_region(u64 start, u64 size)
> > > +struct range arch_get_mappable_range(void)
> > > {
> > > + struct range mhp_range;
> > > +
> > > /*
> > > * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END -
> > > 1)]
> > > * accommodating both its ends but excluding PAGE_END. Max
> > > physical
> > > * range which can be mapped inside this linear mapping range,
> > > must
> > > * also be derived from its end points.
> > > */
> > > - return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> > > - (start + size - 1) <= __pa(PAGE_END - 1);
> > > + mhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
> > > + mhp_range.end = __pa(PAGE_END - 1);
> > > + return mhp_range;
> > > }
> > >
> > > int arch_add_memory(int nid, u64 start, u64 size,
> > > @@ -1460,11 +1463,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
> > > {
> > > int ret, flags = 0;
> > >
> > > - if (!inside_linear_region(start, size)) {
> > > - pr_err("[%llx %llx] is outside linear mapping region\n",
> > > start, start + size);
> > > - return -EINVAL;
> > > - }
> > > -
> > > + VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > > if (rodata_full || debug_pagealloc_enabled())
> > > flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> >
> > The stable rc 5.10 and 5.11 builds failed for arm64 architecture
> > due to below warnings / errors,
> >
> > > Anshuman Khandual
> > > arm64/mm: define arch_get_mappable_range()
> >
> >
> > arch/arm64/mm/mmu.c: In function 'arch_add_memory':
> > arch/arm64/mm/mmu.c:1483:13: error: implicit declaration of function
> > 'mhp_range_allowed'; did you mean 'cpu_map_prog_allowed'?
> > [-Werror=implicit-function-declaration]
> > VM_BUG_ON(!mhp_range_allowed(start, size, true));
> >^
> > include/linux/build_bug.h:30:63: note: in definition of macro
> > 'BUILD_BUG_ON_INVALID'
> >#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e
> > ^
> > arch/arm64/mm/mmu.c:1483:2: note: in expansion of macro 'VM_BUG_ON'
> > VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > ^
> >
> > Build link,
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.11/DISTRO=lkft,MACHINE=juno,label=docker-buster-lkft/41/consoleText
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/DISTRO=lkft,MACHINE=dragonboard-410c,label=docker-buster-lkft/120/consoleFull
>
> thanks, will go drop this, and the patch that was after it in the
> series, from both trees and will push out a -rc2.
>
Why were these picked up in the first place? I don't see any fixes or
cc:stable tags, and the commit log clearly describes that the change
is preparatory work for enabling arm64 support into a recently
introduced generic framework.
--
Ard.
Re: [PATCH] efi/fdt: fix panic when no valid fdt found
On Wed, 24 Mar 2021 at 15:54, Changbin Du wrote:
>
> setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no
> valid fdt found then initial_boot_params will be null. So we
> should stop further fdt processing here. I encountered this
> issue on risc-v.
>
> Signed-off-by: Changbin Du
I'll queue this up, thanks.
> ---
> drivers/firmware/efi/fdtparams.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/firmware/efi/fdtparams.c
> b/drivers/firmware/efi/fdtparams.c
> index bb042ab7c2be..e901f8564ca0 100644
> --- a/drivers/firmware/efi/fdtparams.c
> +++ b/drivers/firmware/efi/fdtparams.c
> @@ -98,6 +98,9 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data
> *mm)
> BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
> BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(dt_params[0].params));
>
> + if (!fdt)
> + return 0;
> +
> for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> node = fdt_path_offset(fdt, dt_params[i].path);
> if (node < 0)
> --
> 2.30.2
>
Re: [PATCH] crypto: sm3 - use the more precise type u32 instead of unsigned int
On Fri, 26 Mar 2021 at 03:22, Tianjia Zhang
wrote:
>
> In the process of calculating the hash, use the more accurate type
> 'u32' instead of the original 'unsigned int' to avoid ambiguity.
>
> Signed-off-by: Tianjia Zhang
I don't see the point of this patch. u32 and unsigned int are always
the same type, regardless of architecture.
> ---
> crypto/sm3_generic.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/crypto/sm3_generic.c b/crypto/sm3_generic.c
> index 193c4584bd00..562e96f92f64 100644
> --- a/crypto/sm3_generic.c
> +++ b/crypto/sm3_generic.c
> @@ -36,17 +36,17 @@ static inline u32 p1(u32 x)
> return x ^ rol32(x, 15) ^ rol32(x, 23);
> }
>
> -static inline u32 ff(unsigned int n, u32 a, u32 b, u32 c)
> +static inline u32 ff(u32 n, u32 a, u32 b, u32 c)
> {
> return (n < 16) ? (a ^ b ^ c) : ((a & b) | (a & c) | (b & c));
> }
>
> -static inline u32 gg(unsigned int n, u32 e, u32 f, u32 g)
> +static inline u32 gg(u32 n, u32 e, u32 f, u32 g)
> {
> return (n < 16) ? (e ^ f ^ g) : ((e & f) | ((~e) & g));
> }
>
> -static inline u32 t(unsigned int n)
> +static inline u32 t(u32 n)
> {
> return (n < 16) ? SM3_T1 : SM3_T2;
> }
> @@ -54,7 +54,7 @@ static inline u32 t(unsigned int n)
> static void sm3_expand(u32 *t, u32 *w, u32 *wt)
> {
> int i;
> - unsigned int tmp;
> + u32 tmp;
>
> /* load the input */
> for (i = 0; i <= 15; i++)
> @@ -123,8 +123,8 @@ static void sm3_compress(u32 *w, u32 *wt, u32 *m)
>
> static void sm3_transform(struct sm3_state *sst, u8 const *src)
> {
> - unsigned int w[68];
> - unsigned int wt[64];
> + u32 w[68];
> + u32 wt[64];
>
> sm3_expand((u32 *)src, w, wt);
> sm3_compress(w, wt, sst->state);
> --
> 2.19.1.3.ge56e4f7
>
Re: [PATCH 0/3] Fix cross compiling x86 with clang
On Fri, 26 Mar 2021 at 01:04, Nathan Chancellor wrote: > > Hi all, > > This series fixes cross compiling x86 with clang, which was initially > brought up by John here: > > https://lore.kernel.org/r/cceb074c-861c-d716-5e19-834a8492f...@gmail.com/ > > I have picked up that patch and added the same fix in a couple of other > places where it is needed. > > I have tested this on an ARM based server with both defconfig and > allmodconfig, where the build now passes. > > Please let me know if there are any problems. > > Cheers, > Nathan > > John Millikin (1): > x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) > > Nathan Chancellor (2): > x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS > efi/libstub: Add $(CLANG_FLAGS) to x86 flags > Acked-by: Ard Biesheuvel > arch/x86/Makefile | 1 + > arch/x86/boot/compressed/Makefile | 1 + > drivers/firmware/efi/libstub/Makefile | 3 ++- > 3 files changed, 4 insertions(+), 1 deletion(-) > > > base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b > -- > 2.31.0 >
Re: [question] insert ko failed because count_plts return 0 when CONFIG_RANDOMIZE_BASE is not set
On Thu, 25 Mar 2021 at 07:22, chenjun (AM) wrote: > > 在 2021/3/24 16:29, Ard Biesheuvel 写道: > > On Wed, 24 Mar 2021 at 08:27, chenjun (AM) wrote: > >> > >> Hi > >> > >> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M) > >> can not be inserted. > >> > > > > How many large modules have you loaded already? The module region is > > only 128 MB, so if your modules are huge, you may run out of space. > > > > Please check the kernel VA address and the load address of the module, > > and check whether they are more than 128 MB apart. > > > > Thanks Ard > > I will check it. > > One more question, why is CONFIG_ARM64_MODULE_PLTS depended on > CONFIG_RANDOMIZE_BASE? > Because modules should never go out of branching range if the placement is not randomized and the total size of all modules does not exceed 128 MB.
Re: [PATCH] static_call: fix function type mismatch
On Thu, 25 Mar 2021 at 08:43, Peter Zijlstra wrote:
>
> On Thu, Mar 25, 2021 at 01:42:41AM +0100, Rasmus Villemoes wrote:
> > > Actually, it looks like I can't select PREEMPT_DYNAMIC> and tweaking
> > > Kconfig
> >
> > Ah, there's no prompt on the "bool" line, so it doesn't show up. That
> > seems to be a mistake, since there's an elaborate help text which says
> >
> > The runtime overhead is negligible with
> > HAVE_STATIC_CALL_INLINE enabled
> > but if runtime patching is not available for the specific
> > architecture
> > then the potential overhead should be considered.
> >
> > So it seems that it was meant to be "you can enable this if you really
> > want".
> >
> > to force enable it on arm64 results in a build error
>
> Right, PREEMPT_DYNAMIC really hard relies on HAVE_STATIC_CALL
>
> There's an implicit dependency in the select:
>
> config PREEMPT
> ...
> select PREEMPT_DYNAMIC if HAVE_PREEMPT_DYNAMIC
>
> > > ("implicit declaration of function 'static_call_mod'").
> >
> > Seems to be an omission in the last !HAVE_STATIC_CALL branch in
> > static_call_types.h, and there's also no
> > EXPORT_STATIC_CALL_TRAMP{,_GPL} in static_call.h for that case.
>
> That interface doesn't make sense for !HAVE_STATIC_CALL. It's impossible
> to not export the function pointer itself but still call it for
> !HAVE_STATIC_CALL.
I proposed an implementation for the indirect static call variety for
arm64 here [0] but we haven't yet decided whether it is needed, given
that indirect calls are mostly fine on arm64 (modulo CFI of course)
Maybe this helps?
[0]
https://lore.kernel.org/linux-arm-kernel/20201120082103.4840-1-a...@kernel.org/
Re: [question] insert ko failed because count_plts return 0 when CONFIG_RANDOMIZE_BASE is not set
On Wed, 24 Mar 2021 at 08:27, chenjun (AM) wrote:
>
> Hi
>
> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
> can not be inserted.
>
How many large modules have you loaded already? The module region is
only 128 MB, so if your modules are huge, you may run out of space.
Please check the kernel VA address and the load address of the module,
and check whether they are more than 128 MB apart.
> WARNING: CPU: 2 PID: 1998 at arch/arm64/kernel/module-plts.c:39
> module_emit_plt_entry+0x100/0x118
> ...
> Call trace:
> module_emit_plt_entry+0x100/0x118
> apply_relocate_add+0x34c/0x570
> ...
>
> I think the problem is that:
> in apply_relocate_add:
> case R_AARCH64_CALL26:
> ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 2, 26,
>AARCH64_INSN_IMM_26);
>
> if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> ovf == -ERANGE) {
> val = module_emit_plt_entry(me, sechdrs,
> loc, [i], sym); realoc_insn_imm return -ERANGE (because the ko is
> too big?)
>
> in module_emit_plt_entry:
> WARN_ON(pltsec->plt_num_entries > pltsec->plt_max_entries)
> pltsec->plt_max_entries is 0 if CONFIG_RANDOMIZE_BASE is not be set.
>
> a257e02 arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum
> #843419
>static unsigned int count_plts(Elf64_Sym *syms, Elf64_Rela *rela, int
> num,
> - Elf64_Word dstidx)
> + Elf64_Word dstidx, Elf_Shdr *dstsec)
>{
> ...
> switch (ELF64_R_TYPE(rela[i].r_info)) {
> case R_AARCH64_JUMP26:
> case R_AARCH64_CALL26:
> + if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> + break;
> +
>
> Why we need break if !IS_ENABLED(CONFIG_RANDOMIZE_BASE)? or any
> restrictions on ko?
>
> I comment out this part of the code. the ko could be inserted, and seems
> to work well. So is it a accepted way? or any solution for my case?
>
> --
> Regards
> Chen Jun
>
Re: [PATCH] init/Kconfig: Support sign module with SM3 hash algorithm
On Tue, 23 Mar 2021 at 09:36, Tianjia Zhang
wrote:
>
> The kernel module signature supports the option to use the SM3
> secure hash (OSCCA GM/T 0004-2012 SM3).
>
> Signed-off-by: Tianjia Zhang
A secure hash is not the same as a signature. Looking at the patch,
the asymmetric algorithm that is used to sign the SM3 digest is SM2,
is that correct? How does one create such signed modules?
In any case, please provide more context in the commit log on how this
is intended to be used.
> ---
> Documentation/admin-guide/module-signing.rst | 5 +++--
> crypto/asymmetric_keys/pkcs7_parser.c| 7 +++
> init/Kconfig | 5 +
> 3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/module-signing.rst
> b/Documentation/admin-guide/module-signing.rst
> index 7d7c7c8a545c..8d8980808b5b 100644
> --- a/Documentation/admin-guide/module-signing.rst
> +++ b/Documentation/admin-guide/module-signing.rst
> @@ -30,8 +30,8 @@ This facility uses X.509 ITU-T standard certificates to
> encode the public keys
> involved. The signatures are not themselves encoded in any industrial
> standard
> type. The facility currently only supports the RSA public key encryption
> standard (though it is pluggable and permits others to be used). The
> possible
> -hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and
> -SHA-512 (the algorithm is selected by data in the signature).
> +hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384,
> SHA-512,
> +and SM3 (the algorithm is selected by data in the signature).
>
>
> ==
> @@ -86,6 +86,7 @@ This has a number of options available:
> ``CONFIG_MODULE_SIG_SHA256``:menuselection:`Sign modules with
> SHA-256`
> ``CONFIG_MODULE_SIG_SHA384``:menuselection:`Sign modules with
> SHA-384`
> ``CONFIG_MODULE_SIG_SHA512``:menuselection:`Sign modules with
> SHA-512`
> + ``CONFIG_MODULE_SIG_SM3`` :menuselection:`Sign modules with SM3`
> ===
> ==
>
> The algorithm selected here will also be built into the kernel (rather
> diff --git a/crypto/asymmetric_keys/pkcs7_parser.c
> b/crypto/asymmetric_keys/pkcs7_parser.c
> index 967329e0a07b..6cf6c4552c11 100644
> --- a/crypto/asymmetric_keys/pkcs7_parser.c
> +++ b/crypto/asymmetric_keys/pkcs7_parser.c
> @@ -248,6 +248,9 @@ int pkcs7_sig_note_digest_algo(void *context, size_t
> hdrlen,
> case OID_sha224:
> ctx->sinfo->sig->hash_algo = "sha224";
> break;
> + case OID_sm3:
> + ctx->sinfo->sig->hash_algo = "sm3";
> + break;
> default:
> printk("Unsupported digest algo: %u\n", ctx->last_oid);
> return -ENOPKG;
> @@ -269,6 +272,10 @@ int pkcs7_sig_note_pkey_algo(void *context, size_t
> hdrlen,
> ctx->sinfo->sig->pkey_algo = "rsa";
> ctx->sinfo->sig->encoding = "pkcs1";
> break;
> + case OID_SM2_with_SM3:
> + ctx->sinfo->sig->pkey_algo = "sm2";
> + ctx->sinfo->sig->encoding = "raw";
> + break;
> default:
> printk("Unsupported pkey algo: %u\n", ctx->last_oid);
> return -ENOPKG;
> diff --git a/init/Kconfig b/init/Kconfig
> index 5f5c776ef192..fed9236078e4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -2202,6 +2202,10 @@ config MODULE_SIG_SHA512
> bool "Sign modules with SHA-512"
> select CRYPTO_SHA512
>
> +config MODULE_SIG_SM3
> + bool "Sign modules with SM3"
> + select CRYPTO_SM3
> +
> endchoice
>
> config MODULE_SIG_HASH
> @@ -2212,6 +2216,7 @@ config MODULE_SIG_HASH
> default "sha256" if MODULE_SIG_SHA256
> default "sha384" if MODULE_SIG_SHA384
> default "sha512" if MODULE_SIG_SHA512
> + default "sm3" if MODULE_SIG_SM3
>
> config MODULE_COMPRESS
> bool "Compress modules on installation"
> --
> 2.19.1.3.ge56e4f7
>
Re: [PATCH] crypto: poly1305: fix poly1305_core_setkey() declaration
On Mon, 22 Mar 2021 at 18:05, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> gcc-11 points out a mismatch between the declaration and the definition
> of poly1305_core_setkey():
>
> lib/crypto/poly1305-donna32.c:13:67: error: argument 2 of type ‘const u8[16]’
> {aka ‘const unsigned char[16]’} with mismatched bound
> [-Werror=array-parameter=]
>13 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8
> raw_key[16])
> |
> ~^~~
> In file included from lib/crypto/poly1305-donna32.c:11:
> include/crypto/internal/poly1305.h:21:68: note: previously declared as ‘const
> u8 *’ {aka ‘const unsigned char *’}
>21 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8
> *raw_key);
>
> This is harmless in principle, as the calling conventions are the same,
> but the more specific prototype allows better type checking in the
> caller.
>
> Change the declaration to match the actual function definition.
> The poly1305_simd_init() is a bit suspicious here, as it previously
> had a 32-byte argument type, but looks like it needs to take the
> 16-byte POLY1305_BLOCK_SIZE array instead.
>
This looks ok to me. For historical reasons, the Poly1305 integration
is based on an unkeyed shash, and both the Poly1305 key and nonce are
passed as ordinary input, prepended to the actual data.
poly1305_simd_init() takes only the key but not the nonce, so it
should only be passed 16 bytes.
> Fixes: 1c08a104360f ("crypto: poly1305 - add new 32 and 64-bit generic
> versions")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Ard Biesheuvel
> ---
> arch/arm/crypto/poly1305-glue.c| 2 +-
> arch/arm64/crypto/poly1305-glue.c | 2 +-
> arch/mips/crypto/poly1305-glue.c | 2 +-
> arch/x86/crypto/poly1305_glue.c| 6 +++---
> include/crypto/internal/poly1305.h | 3 ++-
> include/crypto/poly1305.h | 6 --
> lib/crypto/poly1305-donna32.c | 3 ++-
> lib/crypto/poly1305-donna64.c | 3 ++-
> lib/crypto/poly1305.c | 3 ++-
> 9 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/crypto/poly1305-glue.c b/arch/arm/crypto/poly1305-glue.c
> index 3023c1acfa19..c31bd8f7c092 100644
> --- a/arch/arm/crypto/poly1305-glue.c
> +++ b/arch/arm/crypto/poly1305-glue.c
> @@ -29,7 +29,7 @@ void __weak poly1305_blocks_neon(void *state, const u8
> *src, u32 len, u32 hibit)
>
> static __ro_after_init DEFINE_STATIC_KEY_FALSE(have_neon);
>
> -void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8 *key)
> +void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8
> key[POLY1305_KEY_SIZE])
> {
> poly1305_init_arm(>h, key);
> dctx->s[0] = get_unaligned_le32(key + 16);
> diff --git a/arch/arm64/crypto/poly1305-glue.c
> b/arch/arm64/crypto/poly1305-glue.c
> index 683de671741a..9c3d86e397bf 100644
> --- a/arch/arm64/crypto/poly1305-glue.c
> +++ b/arch/arm64/crypto/poly1305-glue.c
> @@ -25,7 +25,7 @@ asmlinkage void poly1305_emit(void *state, u8 *digest,
> const u32 *nonce);
>
> static __ro_after_init DEFINE_STATIC_KEY_FALSE(have_neon);
>
> -void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8 *key)
> +void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8
> key[POLY1305_KEY_SIZE])
> {
> poly1305_init_arm64(>h, key);
> dctx->s[0] = get_unaligned_le32(key + 16);
> diff --git a/arch/mips/crypto/poly1305-glue.c
> b/arch/mips/crypto/poly1305-glue.c
> index fc881b46d911..bc6110fb98e0 100644
> --- a/arch/mips/crypto/poly1305-glue.c
> +++ b/arch/mips/crypto/poly1305-glue.c
> @@ -17,7 +17,7 @@ asmlinkage void poly1305_init_mips(void *state, const u8
> *key);
> asmlinkage void poly1305_blocks_mips(void *state, const u8 *src, u32 len,
> u32 hibit);
> asmlinkage void poly1305_emit_mips(void *state, u8 *digest, const u32
> *nonce);
>
> -void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8 *key)
> +void poly1305_init_arch(struct poly1305_desc_ctx *dctx, const u8
> key[POLY1305_KEY_SIZE])
> {
> poly1305_init_mips(>h, key);
> dctx->s[0] = get_unaligned_le32(key + 16);
> diff --git a/arch/x86/crypto/poly1305_glue.c b/arch/x86/crypto/poly1305_glue.c
> index 646da46e8d10..1dfb8af48a3c 100644
> --- a/arch/x86/crypto/poly1305_glue.c
> +++ b/arch/x86/crypto/poly1305_glue.c
> @@ -16,7 +16,7 @@
> #include
>
> asmlinkage void poly1305_init_x86_64(void *ctx,
> -const u8 key[POLY1305_KEY_SIZE]);
> +const u8 key[POLY1305_BLOCK_SIZE]);
> asmlinkage void poly1305_blocks_x86_64(void *ctx
Re: [PATCH] arm64: stacktrace: don't trace arch_stack_walk()
On Mon, 22 Mar 2021 at 16:57, Ard Biesheuvel wrote:
>
> On Mon, 22 Mar 2021 at 14:26, Will Deacon wrote:
> >
> > On Fri, 19 Mar 2021 18:41:06 +, Mark Rutland wrote:
> > > We recently converted arm64 to use arch_stack_walk() in commit:
> > >
> > > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK")
> > >
> > > The core stacktrace code expects that (when tracing the current task)
> > > arch_stack_walk() starts a trace at its caller, and does not include
> > > itself in the trace. However, arm64's arch_stack_walk() includes itself,
> > > and so traces include one more entry than callers expect. The core
> > > stacktrace code which calls arch_stack_walk() tries to skip a number of
> > > entries to prevent itself appearing in a trace, and the additional entry
> > > prevents skipping one of the core stacktrace functions, leaving this in
> > > the trace unexpectedly.
> > >
> > > [...]
> >
> > Applied to arm64 (for-next/fixes), thanks!
> >
> > [1/1] arm64: stacktrace: don't trace arch_stack_walk()
> > https://git.kernel.org/arm64/c/c607ab4f916d
> >
>
> Ehm, did anyone check if the following caveat regarding
> __builtin_frame_address() applies on arm64? (from the GCC man page
> [0])
>
> """
> Calling this function with a nonzero argument can have unpredictable
> effects, including crashing the calling program. As a result, calls
> that are considered unsafe are diagnosed when the -Wframe-address
> option is in effect. Such calls should only be made in debugging
> situations.
> """
>
> [0] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
Never mind, failed to read the entire thread. Apologies ...
Re: [PATCH] arm64: stacktrace: don't trace arch_stack_walk()
On Mon, 22 Mar 2021 at 14:26, Will Deacon wrote:
>
> On Fri, 19 Mar 2021 18:41:06 +, Mark Rutland wrote:
> > We recently converted arm64 to use arch_stack_walk() in commit:
> >
> > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK")
> >
> > The core stacktrace code expects that (when tracing the current task)
> > arch_stack_walk() starts a trace at its caller, and does not include
> > itself in the trace. However, arm64's arch_stack_walk() includes itself,
> > and so traces include one more entry than callers expect. The core
> > stacktrace code which calls arch_stack_walk() tries to skip a number of
> > entries to prevent itself appearing in a trace, and the additional entry
> > prevents skipping one of the core stacktrace functions, leaving this in
> > the trace unexpectedly.
> >
> > [...]
>
> Applied to arm64 (for-next/fixes), thanks!
>
> [1/1] arm64: stacktrace: don't trace arch_stack_walk()
> https://git.kernel.org/arm64/c/c607ab4f916d
>
Ehm, did anyone check if the following caveat regarding
__builtin_frame_address() applies on arm64? (from the GCC man page
[0])
"""
Calling this function with a nonzero argument can have unpredictable
effects, including crashing the calling program. As a result, calls
that are considered unsafe are diagnosed when the -Wframe-address
option is in effect. Such calls should only be made in debugging
situations.
"""
[0] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
[tip: efi/urgent] efi: use 32-bit alignment for efi_guid_t literals
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: fb98cc0b3af2ba4d87301dff2b381b12eee35d7d
Gitweb:
https://git.kernel.org/tip/fb98cc0b3af2ba4d87301dff2b381b12eee35d7d
Author:Ard Biesheuvel
AuthorDate:Wed, 10 Mar 2021 08:33:19 +01:00
Committer: Ard Biesheuvel
CommitterDate: Fri, 19 Mar 2021 07:44:28 +01:00
efi: use 32-bit alignment for efi_guid_t literals
Commit 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") updated
the type definition of efi_guid_t to ensure that it always appears
sufficiently aligned (the UEFI spec is ambiguous about this, but given
the fact that its EFI_GUID type is defined in terms of a struct carrying
a uint32_t, the natural alignment is definitely >= 32 bits).
However, we missed the EFI_GUID() macro which is used to instantiate
efi_guid_t literals: that macro is still based on the guid_t type,
which does not have a minimum alignment at all. This results in warnings
such as
In file included from drivers/firmware/efi/mokvar-table.c:35:
include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
access [-Walign-mismatch]
status = get_var(L"SecureBoot", _GLOBAL_VARIABLE_GUID, NULL,
,
^
include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
access [-Walign-mismatch]
get_var(L"SetupMode", _GLOBAL_VARIABLE_GUID, NULL, ,
);
The distinction only matters on CPUs that do not support misaligned loads
fully, but 32-bit ARM's load-multiple instructions fall into that category,
and these are likely to be emitted by the compiler that built the firmware
for loading word-aligned 128-bit GUIDs from memory
So re-implement the initializer in terms of our own efi_guid_t type, so that
the alignment becomes a property of the literal's type.
Fixes: 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t")
Reported-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Link: https://github.com/ClangBuiltLinux/linux/issues/1327
Signed-off-by: Ard Biesheuvel
---
include/linux/efi.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 8710f57..6b5d36b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -72,8 +72,10 @@ typedef void *efi_handle_t;
*/
typedef guid_t efi_guid_t __aligned(__alignof__(u32));
-#define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \
- GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)
+#define EFI_GUID(a, b, c, d...) (efi_guid_t){ {
\
+ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff,
\
+ (b) & 0xff, ((b) >> 8) & 0xff,
\
+ (c) & 0xff, ((c) >> 8) & 0xff, d } }
/*
* Generic EFI table header
Re: [PATCH] firmware/efi: Fix a use after bug in efi_mem_reserve_persistent
On Wed, 10 Mar 2021 at 09:37, Lv Yunlong wrote:
>
> In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next
> use the unmapped rsv. Use the unmapped pages will cause segment
> fault.
>
> Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in
> unmapped memory")
> Signed-off-by: Lv Yunlong
Queued as a fix, thanks.
> ---
> drivers/firmware/efi/efi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index df3f9bcab581..4b7ee3fa9224 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -927,7 +927,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr,
> u64 size)
> }
>
> /* first try to find a slot in an existing linked list entry */
> - for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
> + for (prsv = efi_memreserve_root->next; prsv; ) {
> rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB);
> index = atomic_fetch_add_unless(>count, 1, rsv->size);
> if (index < rsv->size) {
> @@ -937,6 +937,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr,
> u64 size)
> memunmap(rsv);
> return efi_mem_reserve_iomem(addr, size);
> }
> + prsv = rsv->next;
> memunmap(rsv);
> }
>
> --
> 2.25.1
>
>
Re: [PATCH] Documentation: arm64/acpi : clarify arm64 support of IBFT
On Thu, 18 Mar 2021 at 12:29, Lorenzo Pieralisi
wrote:
>
> [+ Al, Ard]
>
> On Thu, Mar 18, 2021 at 10:44:33AM +, Will Deacon wrote:
> > [+Lorenzo]
> >
> > On Tue, Mar 16, 2021 at 12:50:41PM -0600, Tom Saeger wrote:
> > > In commit 94bccc340710 ("iscsi_ibft: make ISCSI_IBFT dependson ACPI
> > > instead
> > > of ISCSI_IBFT_FIND") Kconfig was disentangled to make ISCSI_IBFT selection
> > > not depend on x86.
> > >
> > > Update arm64 acpi documentation, changing IBFT support status from
> > > "Not Supported" to "Optional".
> > > Opportunistically re-flow paragraph for changed lines.
> > >
> > > Link:
> > > https://lore.kernel.org/lkml/1563475054-10680-1-git-send-email-thomas@oracle.com/
> > >
> > > Signed-off-by: Tom Saeger
> > > ---
> > > Documentation/arm64/acpi_object_usage.rst | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > Lorenzo, please could you ack the change below if you're happy with it?
> > If so, I can take it as a fix.
>
> I don't see any issue with this patch, more so given that the IBFT
> legacy discovery method was decoupled from the ACPI table method,
> so it looks sound on ARM64.
>
> However, I would like to get Al and Ard opinions on this to make sure
> there is not something I am missing (in particular wrt the rationale
> behind the "Not Supported" in the docs).
>
Both the original change and this documentation change look fine to me.
Acked-by: Ard Biesheuvel
Re: [PATCH] optee: enable apci support
On Thu, 18 Mar 2021 at 08:29, Ran Wang wrote:
>
> Hi Ard,
>
>
> On Wednesday, March 17, 2021 4:29 PM, Ard Biesheuvel wrote:
> >
> > On Wed, 17 Mar 2021 at 09:04, Jens Wiklander
> > wrote:
> > >
> > > On Fri, Mar 12, 2021 at 04:36:53PM +0800, Ran Wang wrote:
> > > > This patch add ACPI support for optee driver.
> > > >
> > > > Signed-off-by: Ran Wang
> > > > ---
> > > > drivers/tee/optee/core.c | 10 ++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > > > index cf4718c6d35d..8fb261f4b9db 100644
> > > > --- a/drivers/tee/optee/core.c
> > > > +++ b/drivers/tee/optee/core.c
> > > > @@ -5,6 +5,7 @@
> > > >
> > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -735,12 +736,21 @@ static const struct of_device_id
> > > > optee_dt_match[] = { }; MODULE_DEVICE_TABLE(of, optee_dt_match);
> > > >
> > > > +#ifdef CONFIG_ACPI
> > > > +static const struct acpi_device_id optee_acpi_match[] = {
> > > > + { "OPTEE01",},
> >
> > You cannot just invent ACPI HIDs like that. The 4 character prefix is a
> > vendor ID that is assigned by the UEFI forum, the 4 following digits are
> > up to the vendor to assign,
>
> Thanks for this info. Could you please show me where I can find the
> guide/example for this assign process?
>
I think it is better to ask around internally. As far as I know, NXP
already owns a ACPI/PNP vendor prefix.
> > > > + { },
> > > > +};
> > > > +MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
> >
> > dwc3_acpi_match ?? Does this even build?
>
> My bad, I was referring dwc3 code as an example, will correct it.
>
> But looks this typo didn’t trigger error in my unit-test.
>
Does your build have CONFIG_ACPI enabled?
> >
> > > > +#endif
> > > > +
> > > > static struct platform_driver optee_driver = {
> > > > .probe = optee_probe,
> > > > .remove = optee_remove,
> > > > .driver = {
> > > > .name = "optee",
> > > > .of_match_table = optee_dt_match,
> > > > + .acpi_match_table = ACPI_PTR(optee_acpi_match),
> > > > },
> > > > };
> > > > module_platform_driver(optee_driver);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > This looks simple enough. Ard, is this what you had in mind earlier?
> > >
> >
> > Not really.
> >
> > On SynQuacer, we use
> >
> > Device (TOS0) {
> > Name (_HID, "PRP0001")
> > Name (_UID, 0x0)
> > Name (_DSD, Package () {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package () {
> > Package (2) { "compatible", "linaro,optee-tz" },
> > Package (2) { "method", "smc" },
> > }
> > })
> > }
> >
> > which does not require any changes to Linux. So I don't think this patch is
> > needed at all tbh.
>
> Thanks for this example, but actually I failed to trigger kernel optee probe
> function by using
> above code in ACPI table.
>
> And I am curious how this 'compatible' properties be picked up by kernel when
> try to match driver in ACPI mode?
>
On SynQuacer,
$ cat /sys/devices/platform/PRP0001:00/firmware_node/modalias
of:Ntos0TClinaro,optee-tz
> My understanding is to get it done by feeding .acpi_match_table with
> something, right?
>
The PRP0001 HID is handled in a special way. Please grep the Linux
source if you are curious to understand how this is implemented.
Re: [PATCH] optee: enable apci support
On Wed, 17 Mar 2021 at 09:04, Jens Wiklander wrote:
>
> On Fri, Mar 12, 2021 at 04:36:53PM +0800, Ran Wang wrote:
> > This patch add ACPI support for optee driver.
> >
> > Signed-off-by: Ran Wang
> > ---
> > drivers/tee/optee/core.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > index cf4718c6d35d..8fb261f4b9db 100644
> > --- a/drivers/tee/optee/core.c
> > +++ b/drivers/tee/optee/core.c
> > @@ -5,6 +5,7 @@
> >
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -735,12 +736,21 @@ static const struct of_device_id optee_dt_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, optee_dt_match);
> >
> > +#ifdef CONFIG_ACPI
> > +static const struct acpi_device_id optee_acpi_match[] = {
> > + { "OPTEE01",},
You cannot just invent ACPI HIDs like that. The 4 character prefix is
a vendor ID that is assigned by the UEFI forum, the 4 following digits
are up to the vendor to assign,
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
dwc3_acpi_match ?? Does this even build?
> > +#endif
> > +
> > static struct platform_driver optee_driver = {
> > .probe = optee_probe,
> > .remove = optee_remove,
> > .driver = {
> > .name = "optee",
> > .of_match_table = optee_dt_match,
> > + .acpi_match_table = ACPI_PTR(optee_acpi_match),
> > },
> > };
> > module_platform_driver(optee_driver);
> > --
> > 2.25.1
> >
>
> This looks simple enough. Ard, is this what you had in mind earlier?
>
Not really.
On SynQuacer, we use
Device (TOS0) {
Name (_HID, "PRP0001")
Name (_UID, 0x0)
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "linaro,optee-tz" },
Package (2) { "method", "smc" },
}
})
}
which does not require any changes to Linux. So I don't think this
patch is needed at all tbh.
Re: [syzbot] kernel panic: corrupted stack end in openat
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:1e28eed1 Linux 5.12-rc3
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=167535e6d0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=e0cee1f53de33ca3
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=0b06ef9b44d00d600183
> > > userspace arch: arm
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+0b06ef9b44d00d600...@syzkaller.appspotmail.com
> >
> > +arm32 maintainer
> > I think this is a real stack overflow on arm32, the stack is indeed deep.
>
> Nice find. I see there was already a second report, so it seems to be
> reproducible as well.
> If you are able to trigger this reliably, you could try printing the frame
> pointer while unwinding to see what is actually going on:
>
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where,
> unsigned long from,
> unsigned long end = frame + 4 + sizeof(struct pt_regs);
>
> #ifdef CONFIG_KALLSYMS
> - printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
> - loglvl, where, (void *)where, from, (void *)from);
> + printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n",
> + loglvl, where, (void *)where, from, (void *)from, frame);
> #else
> printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
> loglvl, where, from);
>
> If that doesn't help, I could have a look at the binary to see which
> functions in the call chain take a lot of stack space, if any.
>
> Which exact compiler version do you use for building these
> kernels? I can try doing a build with the same commit and config.
>
> This one function is one that I have seen before when looking at build
> warnings with KASAN:
>
> > > [<8073772c>] (integrity_kernel_read) from [<8073a904>]
> > > (ima_calc_file_hash_tfm+0x178/0x228
> > > security/integrity/ima/ima_crypto.c:484)
> > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>]
> > > (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
> > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>]
> > > (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
>
> ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
> use up 512 bytes, but KASAN sometimes triples this number. However, I see
> you do not actually have KASAN enabled, so there is probably more to it.
>
FYI, as an aside, the SHASH_DESC_ON_STACK() issue was fixed in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=660d2062190db131d2feaf19914e90f868fe285c
(note that the size of SHASH_DESC_ON_STACK() accounts for two struct
shash_desc instances)
Re: [PATCH v6 3/5] ARM: implement support for SMCCC TRNG entropy source
On Wed, 6 Jan 2021 at 11:35, Andre Przywara wrote:
>
> From: Ard Biesheuvel
>
> Implement arch_get_random_seed_*() for ARM based on the firmware
> or hypervisor provided entropy source described in ARM DEN0098.
>
> This will make the kernel's random number generator consume entropy
> provided by this interface, at early boot, and periodically at
> runtime when reseeding.
>
> Cc: Linus Walleij
> Cc: Russell King
> Signed-off-by: Ard Biesheuvel
> [Andre: rework to be initialised by the SMCCC firmware driver]
> Signed-off-by: Andre Przywara
> Reviewed-by: Linus Walleij
I think this one could be dropped into rmk's patch tracker now, right?
> ---
> arch/arm/Kconfig | 4 ++
> arch/arm/include/asm/archrandom.h | 64 +++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 138248999df7..bfe642510b0a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1644,6 +1644,10 @@ config STACKPROTECTOR_PER_TASK
> Enable this option to switch to a different method that uses a
> different canary value for each task.
>
> +config ARCH_RANDOM
> + def_bool y
> + depends on HAVE_ARM_SMCCC_DISCOVERY
> +
> endmenu
>
> menu "Boot options"
> diff --git a/arch/arm/include/asm/archrandom.h
> b/arch/arm/include/asm/archrandom.h
> index a8e84ca5c2ee..f3e96a5b65f8 100644
> --- a/arch/arm/include/asm/archrandom.h
> +++ b/arch/arm/include/asm/archrandom.h
> @@ -2,9 +2,73 @@
> #ifndef _ASM_ARCHRANDOM_H
> #define _ASM_ARCHRANDOM_H
>
> +#ifdef CONFIG_ARCH_RANDOM
> +
> +#include
> +#include
> +
> +#define ARM_SMCCC_TRNG_MIN_VERSION 0x1UL
> +
> +extern bool smccc_trng_available;
> +
> +static inline bool __init smccc_probe_trng(void)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_VERSION, );
> + if ((s32)res.a0 < 0)
> + return false;
> + if (res.a0 >= ARM_SMCCC_TRNG_MIN_VERSION) {
> + /* double check that the 32-bit flavor is available */
> + arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_FEATURES,
> +ARM_SMCCC_TRNG_RND32,
> +);
> + if ((s32)res.a0 >= 0)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static inline bool __must_check arch_get_random_long(unsigned long *v)
> +{
> + return false;
> +}
> +
> +static inline bool __must_check arch_get_random_int(unsigned int *v)
> +{
> + return false;
> +}
> +
> +static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
> +{
> + struct arm_smccc_res res;
> +
> + if (smccc_trng_available) {
> + arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND32, 8 * sizeof(*v),
> );
> +
> + if (res.a0 != 0)
> + return false;
> +
> + *v = res.a3;
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
> +{
> + return arch_get_random_seed_long((unsigned long *)v);
> +}
> +
> +
> +#else /* !CONFIG_ARCH_RANDOM */
> +
> static inline bool __init smccc_probe_trng(void)
> {
> return false;
> }
>
> +#endif /* CONFIG_ARCH_RANDOM */
> #endif /* _ASM_ARCHRANDOM_H */
> --
> 2.17.1
>
Re: [PATCH] arm64: mm: fix runtime fallback to 48-bt VA when 52-bit VA is enabled
(+ James)
On Wed, 10 Mar 2021 at 13:41, Ard Biesheuvel wrote:
>
> On Wed, 10 Mar 2021 at 12:18, Will Deacon wrote:
> >
> > On Tue, Mar 09, 2021 at 07:32:16PM -0500, Mark Salter wrote:
> > > I ran into an early boot soft lockup on a Qualcomm Amberwing using a v5.11
> > > kernel configured for 52-bit VA. This turned into a panic with a v5.12-rc2
> > > kernel.
> > >
> > > The problem is that when we fall back to 48-bit VA, idmap_t0sz is not
> > > updated. Later, the kvm hypervisor uses idmap_t0sz to set its tcr_el2 and
> > > hangs (v5.11). After commit 1401bef703a4 ("arm64: mm: Always update
> > > TCR_EL1
> > > from __cpu_set_tcr_t0sz()"), the kernel panics when trying to use the
> > > idmap
> > > to call idmap_cpu_replace_ttbr1().
> > >
> > > Oddly, other systems (thunderX2 and Ampere eMag) which don't support
> > > 52-bit
> > > VA seem to handle the setting of an unsupported t0sz without any apparent
> > > problems. Indeed, if one reads back the tcr written with t0sz==12, the
> > > value read has t0sz==16. Not so with Amberwing.
> >
> > Nice, you have one of those elusive platforms!
> >
> > > Fixes: 90ec95cda91a ("arm64: mm: Introduce VA_BITS_MIN")
> > > Signed-off-by: Mark Salter
> > > ---
> > > arch/arm64/kernel/head.S | 10 +-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > index 66b0e0b66e31..2bcbbb26292e 100644
> > > --- a/arch/arm64/kernel/head.S
> > > +++ b/arch/arm64/kernel/head.S
> > > @@ -291,6 +291,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> > >*/
> > > adrpx0, idmap_pg_dir
> > > adrpx3, __idmap_text_start // __pa(__idmap_text_start)
> > > + mov x4, TCR_T0SZ(VA_BITS)
> > >
> > > #ifdef CONFIG_ARM64_VA_BITS_52
> > > mrs_s x6, SYS_ID_AA64MMFR2_EL1
> > > @@ -299,6 +300,13 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> > > cbnzx6, 1f
> > > #endif
> > > mov x5, #VA_BITS_MIN
> > > +#ifdef CONFIG_ARM64_VA_BITS_52
> > > + mov x4, TCR_T0SZ(VA_BITS_MIN)
> > > + adr_l x6, idmap_t0sz
> > > + str x4, [x6]
> > > + dmb sy
> > > + dc ivac, x6// Invalidate potentially stale
> > > cache line
> > > +#endif
> > > 1:
> > > adr_l x6, vabits_actual
> > > str x5, [x6]
> > > @@ -319,7 +327,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> > >*/
> > > adrpx5, __idmap_text_end
> > > clz x5, x5
> > > - cmp x5, TCR_T0SZ(VA_BITS) // default T0SZ small enough?
> > > + cmp x5, x4 // default T0SZ small enough?
> > > b.ge1f // .. then skip VA range extension
> >
> > Could we instead have the default value be 48-bit, and then avoid having
> > to update the variable in both cases? e.g. something along the lines of
> > the entirely untested diff below?
> >
>
> There is one other occurrence that needs to be updated. I will have a
> stab at fixing this along these lines, and there are a couple of other
> things that need cleaning up.
>
Actually, it seems like this breakage may have been introduced by
commit 1401bef703a48cf79c674215f702a1435362beae
Author: James Morse
Date: Mon Jan 25 14:19:12 2021 -0500
arm64: mm: Always update TCR_EL1 from __cpu_set_tcr_t0sz()
as before that patch, we would never actually load idmap_t0sz into TCR
on 52-bit VA kernels, AFAICT.
It seems to me that the sanest approach is to default to a 48-bit
idmap on 52-bit VA capable kernels (as Will suggests below). This
means that the notion of 'extended ID map' now also includes cases
where the ID map is smaller than the default VA_BITS range. However,
the number of levels is going to be the same, so it does not affect
the ID map page table population code in head.S.
Also, __cpu_uses_extended_idmap() no longer has any users anyway, so
we can remove it rather than bikeshed over a better name for it.
>
>
> > --->8
> >
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 66b0e0b66e31..fb795123896f 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -319,7 +319,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> > */
> > adrpx5, __idmap_text_end
> >
Re: [PATCH] arm64: mm: fix runtime fallback to 48-bt VA when 52-bit VA is enabled
On Wed, 10 Mar 2021 at 12:18, Will Deacon wrote:
>
> On Tue, Mar 09, 2021 at 07:32:16PM -0500, Mark Salter wrote:
> > I ran into an early boot soft lockup on a Qualcomm Amberwing using a v5.11
> > kernel configured for 52-bit VA. This turned into a panic with a v5.12-rc2
> > kernel.
> >
> > The problem is that when we fall back to 48-bit VA, idmap_t0sz is not
> > updated. Later, the kvm hypervisor uses idmap_t0sz to set its tcr_el2 and
> > hangs (v5.11). After commit 1401bef703a4 ("arm64: mm: Always update TCR_EL1
> > from __cpu_set_tcr_t0sz()"), the kernel panics when trying to use the idmap
> > to call idmap_cpu_replace_ttbr1().
> >
> > Oddly, other systems (thunderX2 and Ampere eMag) which don't support 52-bit
> > VA seem to handle the setting of an unsupported t0sz without any apparent
> > problems. Indeed, if one reads back the tcr written with t0sz==12, the
> > value read has t0sz==16. Not so with Amberwing.
>
> Nice, you have one of those elusive platforms!
>
> > Fixes: 90ec95cda91a ("arm64: mm: Introduce VA_BITS_MIN")
> > Signed-off-by: Mark Salter
> > ---
> > arch/arm64/kernel/head.S | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 66b0e0b66e31..2bcbbb26292e 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -291,6 +291,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> >*/
> > adrpx0, idmap_pg_dir
> > adrpx3, __idmap_text_start // __pa(__idmap_text_start)
> > + mov x4, TCR_T0SZ(VA_BITS)
> >
> > #ifdef CONFIG_ARM64_VA_BITS_52
> > mrs_s x6, SYS_ID_AA64MMFR2_EL1
> > @@ -299,6 +300,13 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> > cbnzx6, 1f
> > #endif
> > mov x5, #VA_BITS_MIN
> > +#ifdef CONFIG_ARM64_VA_BITS_52
> > + mov x4, TCR_T0SZ(VA_BITS_MIN)
> > + adr_l x6, idmap_t0sz
> > + str x4, [x6]
> > + dmb sy
> > + dc ivac, x6// Invalidate potentially stale cache
> > line
> > +#endif
> > 1:
> > adr_l x6, vabits_actual
> > str x5, [x6]
> > @@ -319,7 +327,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> >*/
> > adrpx5, __idmap_text_end
> > clz x5, x5
> > - cmp x5, TCR_T0SZ(VA_BITS) // default T0SZ small enough?
> > + cmp x5, x4 // default T0SZ small enough?
> > b.ge1f // .. then skip VA range extension
>
> Could we instead have the default value be 48-bit, and then avoid having
> to update the variable in both cases? e.g. something along the lines of
> the entirely untested diff below?
>
There is one other occurrence that needs to be updated. I will have a
stab at fixing this along these lines, and there are a couple of other
things that need cleaning up.
> --->8
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 66b0e0b66e31..fb795123896f 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -319,7 +319,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
> */
> adrpx5, __idmap_text_end
> clz x5, x5
> - cmp x5, TCR_T0SZ(VA_BITS) // default T0SZ small enough?
> + cmp x5, TCR_T0SZ(VA_BITS_MIN) // default T0SZ small enough?
> b.ge1f // .. then skip VA range extension
>
> adr_l x6, idmap_t0sz
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 3802cfbdd20d..4c5603c41870 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -40,7 +40,7 @@
> #define NO_BLOCK_MAPPINGS BIT(0)
> #define NO_CONT_MAPPINGS BIT(1)
>
> -u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
> +u64 idmap_t0sz = TCR_T0SZ(VA_BITS_MIN);
> u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
>
> u64 __section(".mmuoff.data.write") vabits_actual;
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] arm64: make STACKPROTECTOR_PER_TASK configurable.
On Tue, 9 Mar 2021 at 13:37, Michal Suchanek wrote: > > When using dummy-tools STACKPROTECTOR_PER_TASK is unconditionally > selected. This defeats the purpose of the all-enabled tool. > What is dummy-tools and why should we care about it? > Description copied from arm > > Cc: Masahiro Yamada > Signed-off-by: Michal Suchanek > --- > arch/arm64/Kconfig | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index a8ff7cd5f096..f59d391e31a4 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1549,9 +1549,20 @@ config RANDOMIZE_MODULE_REGION_FULL > config CC_HAVE_STACKPROTECTOR_SYSREG > def_bool $(cc-option,-mstack-protector-guard=sysreg > -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0) > > + > config STACKPROTECTOR_PER_TASK > - def_bool y > + bool "Use a unique stack canary value for each task" > depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_SYSREG > + default y > + help > + Due to the fact that GCC uses an ordinary symbol reference from > + which to load the value of the stack canary, this value can only > + change at reboot time on SMP systems, and all tasks running in the > + kernel's address space are forced to use the same canary value for > + the entire duration that the system is up. > + > + Enable this option to switch to a different method that uses a > + different canary value for each task. > > endmenu > > -- > 2.26.2 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 7/7] CMDLINE: x86: convert to generic builtin command line
On Tue, 9 Mar 2021 at 01:03, Daniel Walker wrote:
>
> This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
> option.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Ruslan Ruslichenko
> Signed-off-by: Ruslan Bilovol
> Signed-off-by: Daniel Walker
> ---
> arch/x86/Kconfig| 44 +
> arch/x86/kernel/setup.c | 18 ++
> drivers/firmware/efi/libstub/x86-stub.c | 2 +-
> 3 files changed, 4 insertions(+), 60 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 21f851179ff0..3950f9bf9855 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -115,6 +115,7 @@ config X86
> select EDAC_SUPPORT
> select GENERIC_CLOCKEVENTS_BROADCASTif X86_64 || (X86_32 &&
> X86_LOCAL_APIC)
> select GENERIC_CLOCKEVENTS_MIN_ADJUST
> + select GENERIC_CMDLINE
> select GENERIC_CMOS_UPDATE
> select GENERIC_CPU_AUTOPROBE
> select GENERIC_CPU_VULNERABILITIES
> @@ -2368,49 +2369,6 @@ choice
>
> endchoice
>
> -config CMDLINE_BOOL
> - bool "Built-in kernel command line"
> - help
> - Allow for specifying boot arguments to the kernel at
> - build time. On some systems (e.g. embedded ones), it is
> - necessary or convenient to provide some or all of the
> - kernel boot arguments with the kernel itself (that is,
> - to not rely on the boot loader to provide them.)
> -
> - To compile command line arguments into the kernel,
> - set this option to 'Y', then fill in the
> - boot arguments in CONFIG_CMDLINE.
> -
> - Systems with fully functional boot loaders (i.e. non-embedded)
> - should leave this option set to 'N'.
> -
> -config CMDLINE
> - string "Built-in kernel command string"
> - depends on CMDLINE_BOOL
> - default ""
> - help
> - Enter arguments here that should be compiled into the kernel
> - image and used at boot time. If the boot loader provides a
> - command line at boot time, it is appended to this string to
> - form the full kernel command line, when the system boots.
> -
> - However, you can use the CONFIG_CMDLINE_OVERRIDE option to
> - change this behavior.
> -
> - In most cases, the command line (whether built-in or provided
> - by the boot loader) should specify the device for the root
> - file system.
> -
> -config CMDLINE_OVERRIDE
> - bool "Built-in command line overrides boot loader arguments"
> - depends on CMDLINE_BOOL && CMDLINE != ""
> - help
> - Set this option to 'Y' to have the kernel ignore the boot loader
> - command line, and use ONLY the built-in command line.
> -
> - This is used to work around broken boot loaders. This should
> - be set to 'N' under normal conditions.
> -
> config MODIFY_LDT_SYSCALL
> bool "Enable the LDT (local descriptor table)" if EXPERT
> default y
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 740f3bdb3f61..e748c3e5c1ae 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * max_low_pfn_mapped: highest directly mapped pfn < 4 GB
> @@ -162,9 +163,6 @@ unsigned long saved_video_mode;
> #define RAMDISK_LOAD_FLAG 0x4000
>
> static char __initdata command_line[COMMAND_LINE_SIZE];
> -#ifdef CONFIG_CMDLINE_BOOL
> -static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
> -#endif
>
> #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> struct edd edd;
> @@ -884,19 +882,7 @@ void __init setup_arch(char **cmdline_p)
> bss_resource.start = __pa_symbol(__bss_start);
> bss_resource.end = __pa_symbol(__bss_stop)-1;
>
> -#ifdef CONFIG_CMDLINE_BOOL
> -#ifdef CONFIG_CMDLINE_OVERRIDE
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> - if (builtin_cmdline[0]) {
> - /* append boot loader cmdline to builtin */
> - strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> - strlcat(builtin_cmdline, boot_command_line,
> COMMAND_LINE_SIZE);
> - strlcpy(boot_command_line, builtin_cmdline,
> COMMAND_LINE_SIZE);
> - }
> -#endif
> -#endif
> -
> + cmdline_add_builtin(boot_command_line, NULL, COMMAND_LINE_SIZE);
> strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
> *cmdline_p = command_line;
>
> diff --git a/drivers/firmware/efi/libstub/x86-stub.c
> b/drivers/firmware/efi/libstub/x86-stub.c
> index f14c4ff5839f..9538c9d4a0bc 100644
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -736,7 +736,7 @@ unsigned long efi_main(efi_handle_t handle,
> }
>
> #ifdef CONFIG_CMDLINE_BOOL
Does this CMDLINE_BOOL check need to be dropped as well?
[tip: efi/urgent] efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 9e9888a0fe97b9501a40f717225d2bef7100a2c1
Gitweb:
https://git.kernel.org/tip/9e9888a0fe97b9501a40f717225d2bef7100a2c1
Author:Ard Biesheuvel
AuthorDate:Fri, 05 Mar 2021 10:21:05 +01:00
Committer: Ard Biesheuvel
CommitterDate: Sun, 07 Mar 2021 09:31:02 +01:00
efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
The EFI_RT_PROPERTIES_TABLE contains a mask of runtime services that are
available after ExitBootServices(). This mostly does not concern the EFI
stub at all, given that it runs before that. However, there is one call
that is made at runtime, which is the call to SetVirtualAddressMap()
(which is not even callable at boot time to begin with)
So add the missing handling of the RT_PROP table to ensure that we only
call SetVirtualAddressMap() if it is not being advertised as unsupported
by the firmware.
Cc: # v5.10+
Tested-by: Shawn Guo
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/efi-stub.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/firmware/efi/libstub/efi-stub.c
b/drivers/firmware/efi/libstub/efi-stub.c
index ec2f398..26e6978 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -96,6 +96,18 @@ static void install_memreserve_table(void)
efi_err("Failed to install memreserve config table!\n");
}
+static u32 get_supported_rt_services(void)
+{
+ const efi_rt_properties_table_t *rt_prop_table;
+ u32 supported = EFI_RT_SUPPORTED_ALL;
+
+ rt_prop_table = get_efi_config_table(EFI_RT_PROPERTIES_TABLE_GUID);
+ if (rt_prop_table)
+ supported &= rt_prop_table->runtime_services_supported;
+
+ return supported;
+}
+
/*
* EFI entry point for the arm/arm64 EFI stubs. This is the entrypoint
* that is described in the PE/COFF header. Most of the code is the same
@@ -250,6 +262,10 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
(prop_tbl->memory_protection_attribute &
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA);
+ /* force efi_novamap if SetVirtualAddressMap() is unsupported */
+ efi_novamap |= !(get_supported_rt_services() &
+EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP);
+
/* hibernation expects the runtime regions to stay in the same place */
if (!IS_ENABLED(CONFIG_HIBERNATION) && !efi_nokaslr &&
!flat_va_mapping) {
/*
Re: [PATCH] crypto: aegis128 - Move simd prototypes into aegis.h
On Mon, 8 Mar 2021 at 06:42, Herbert Xu wrote:
>
> On Sun, Feb 28, 2021 at 03:14:55AM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4
> > commit: a4397635afea5d127548d64e0055ed471ef2d5be crypto: aegis128 - provide
> > a SIMD implementation based on NEON intrinsics
> > date: 1 year, 6 months ago
> > config: arm64-randconfig-r035-20210226 (attached as .config)
> > compiler: aarch64-linux-gcc (GCC) 9.3.0
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4397635afea5d127548d64e0055ed471ef2d5be
> > git remote add linus
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > git fetch --no-tags linus master
> > git checkout a4397635afea5d127548d64e0055ed471ef2d5be
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> > ARCH=arm64
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> crypto/aegis128-neon.c:17:6: warning: no previous prototype for
> > >> 'crypto_aegis128_have_simd' [-Wmissing-prototypes]
> > 17 | bool crypto_aegis128_have_simd(void)
> > | ^
>
> ---8<---
> This patch fixes missing prototype warnings in crypto/aegis128-neon.c.
>
> Fixes: a4397635afea ("crypto: aegis128 - provide a SIMD...")
> Reported-by: kernel test robot
> Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
>
> diff --git a/crypto/aegis.h b/crypto/aegis.h
> index 6920ebe77679..6ef9c174c973 100644
> --- a/crypto/aegis.h
> +++ b/crypto/aegis.h
> @@ -21,9 +21,28 @@ union aegis_block {
> u8 bytes[AEGIS_BLOCK_SIZE];
> };
>
> +struct aegis_state;
> +
> +extern int aegis128_have_aes_insn;
> +
> #define AEGIS_BLOCK_ALIGN (__alignof__(union aegis_block))
> #define AEGIS_ALIGNED(p) IS_ALIGNED((uintptr_t)p, AEGIS_BLOCK_ALIGN)
>
> +bool crypto_aegis128_have_simd(void);
> +void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
> +void crypto_aegis128_init_simd(struct aegis_state *state,
> + const union aegis_block *key,
> + const u8 *iv);
> +void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> + const u8 *src, unsigned int size);
> +void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> + const u8 *src, unsigned int size);
> +int crypto_aegis128_final_simd(struct aegis_state *state,
> + union aegis_block *tag_xor,
> + unsigned int assoclen,
> + unsigned int cryptlen,
> + unsigned int authsize);
> +
> static __always_inline void crypto_aegis_block_xor(union aegis_block *dst,
>const union aegis_block
> *src)
> {
> diff --git a/crypto/aegis128-core.c b/crypto/aegis128-core.c
> index 89dc1c559689..c4f1bfa1d04f 100644
> --- a/crypto/aegis128-core.c
> +++ b/crypto/aegis128-core.c
> @@ -58,21 +58,6 @@ static bool aegis128_do_simd(void)
> return false;
> }
>
> -bool crypto_aegis128_have_simd(void);
> -void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
> -void crypto_aegis128_init_simd(struct aegis_state *state,
> - const union aegis_block *key,
> - const u8 *iv);
> -void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> - const u8 *src, unsigned int size);
> -void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> - const u8 *src, unsigned int size);
> -int crypto_aegis128_final_simd(struct aegis_state *state,
> - union aegis_block *tag_xor,
> - unsigned int assoclen,
> - unsigned int cryptlen,
> - unsigned int authsize);
> -
> static void crypto_aegis128_update(struct aegis
Re: [PATCH] efi: memmap insertion should adjust the vaddr as well
On Wed, 24 Feb 2021 at 19:43, Kairui Song wrote:
>
> Currently when efi_memmap_insert is called, only the
> physical memory addresses are re-calculated. The virt
> addresses of the split entries are untouched.
>
> If any later operation depends on the virt_addaress info, things
> will go wrong. One case it may fail is kexec on x86, after kexec,
> efi is already in virtual mode, kernel simply do fixed mapping
> reuse the recorded virt address. If the virt address is incorrect,
> the mapping will be invalid.
>
> Update the virt_addaress as well when inserting a memmap entry to
> fix this potential issue.
>
> Signed-off-by: Kairui Song
> ---
> drivers/firmware/efi/memmap.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 2ff1883dc788..de5c545b2074 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -292,7 +292,7 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> {
> u64 m_start, m_end, m_attr;
> efi_memory_desc_t *md;
> - u64 start, end;
> + u64 start, end, virt_offset;
> void *old, *new;
>
> /* modifying range */
> @@ -321,6 +321,11 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> start = md->phys_addr;
> end = md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1;
>
> + if (md->virt_addr)
> + virt_offset = md->virt_addr - md->phys_addr;
> + else
> + virt_offset = -1;
> +
Should we take EFI_MEMORY_RUNTIME into account here? I don't think we
should expect to see non-zero virtual addresses if that attribute is
missing.
> if (m_start <= start && end <= m_end)
> md->attribute |= m_attr;
>
> @@ -337,6 +342,8 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> md->phys_addr = m_end + 1;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> + if (virt_offset != -1)
> + md->virt_addr = md->phys_addr + virt_offset;
> }
>
> if ((start < m_start && m_start < end) && m_end < end) {
> @@ -351,6 +358,8 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> md->phys_addr = m_start;
> md->num_pages = (m_end - m_start + 1) >>
> EFI_PAGE_SHIFT;
> + if (virt_offset != -1)
> + md->virt_addr = md->phys_addr + virt_offset;
> /* last part */
> new += old_memmap->desc_size;
> memcpy(new, old, old_memmap->desc_size);
> @@ -358,6 +367,8 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> md->phys_addr = m_end + 1;
> md->num_pages = (end - m_end) >>
> EFI_PAGE_SHIFT;
> + if (virt_offset != -1)
> + md->virt_addr = md->phys_addr + virt_offset;
> }
>
> if ((start < m_start && m_start < end) &&
> @@ -373,6 +384,8 @@ void __init efi_memmap_insert(struct efi_memory_map
> *old_memmap, void *buf,
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> md->attribute |= m_attr;
> + if (virt_offset != -1)
> + md->virt_addr = md->phys_addr + virt_offset;
> }
> }
> }
> --
> 2.29.2
>
Re: [PATCH] efi/apple-properties: Handle device properties with software node API
On Thu, 4 Mar 2021 at 10:46, Lukas Wunner wrote: > > On Thu, Mar 04, 2021 at 11:28:37AM +0300, Heikki Krogerus wrote: > > The old device property API is going to be removed. > > Replacing the device_add_properties() call with the software > > node API equivalent, device_create_managed_software_node(). > > > > Signed-off-by: Heikki Krogerus > > Acked-by: Lukas Wunner Queued in efi/next Thanks all.
Re: [RFC PATCH v2 13/13] objtool: arm64: Enable stack validation for arm64
On Wed, 3 Mar 2021 at 18:10, Julien Thierry wrote: > > From: Raphael Gault > > Add build option to run stack validation at compile time. > > When requiring stack validation, jump tables are disabled as it > simplifies objtool analysis (without having to introduce unreliable > artifacs). In local testing, this does not appear to significaly > affect final binary size nor system performance. > > Signed-off-by: Raphael Gault > Signed-off-by: Julien Thierry > --- > arch/arm64/Kconfig | 1 + > arch/arm64/Makefile | 4 > 2 files changed, 5 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1f212b47a48a..928323c03318 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -187,6 +187,7 @@ config ARM64 > select MMU_GATHER_RCU_TABLE_FREE > select HAVE_RSEQ > select HAVE_STACKPROTECTOR > + select HAVE_STACK_VALIDATION > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_KPROBES > select HAVE_KRETPROBES > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 5b84aec31ed3..b819fb2e8eda 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -136,6 +136,10 @@ ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y) >CC_FLAGS_FTRACE := -fpatchable-function-entry=2 > endif > > +ifeq ($(CONFIG_STACK_VALIDATION),y) > +KBUILD_CFLAGS += -fno-jump-tables > +endif > + This is a bit misleading: the Kconfig option in question is selected automatically in all cases, so jump tables are always disabled. However, I think disabling jump tables make sense anyway, at least when building the relocatable kernel for KASLR: we currently don't use -fpic/fpie in that case when building the vmlinux objects (because we don't want/need GOT tables), and so jump tables are emitted using absolute addresses, which induce some space overhead in the image. (24 bytes of RELA data per absolute address) ... unless I am missing something, and jump tables can/will be emitted as relative, even when not compiling in PIC mode? > # Default value > head-y := arch/arm64/kernel/head.o > > -- > 2.25.4 >
Re: [PATCH] KVM: arm64: Disable LTO in hyp
On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
>
> On Fri, 05 Mar 2021 02:38:17 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
> > wrote:
> > >
> > > On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> > > >
> > > > On Thu, 04 Mar 2021 21:25:41 +,
> > > > Sami Tolvanen wrote:
>
> [...]
>
> > > > > I assume hyp_panic() ends up being placed too far from __guest_enter()
> > > > > when the kernel is large enough. Possibly something to do with LLVM
> > > > > always splitting functions into separate sections with LTO. I'm not
> > > > > sure why the linker cannot shuffle things around to make everyone
> > > > > happy in this case, but I confirmed that this patch also fixes the
> > > > > build issue for me:
> > > > >
> > > > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > b/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > index af8e940d0f03..128197b7c794 100644
> > > > > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > @@ -214,7 +214,7 @@ static void __hyp_call_panic(u64 spsr, u64 elr,
> > > > > u64 par)
> > > > > }
> > > > > NOKPROBE_SYMBOL(__hyp_call_panic);
> > > > >
> > > > > -void __noreturn hyp_panic(void)
> > > > > +void __noreturn hyp_panic(void) __section(".text")
> > > > > {
> > > > > u64 spsr = read_sysreg_el2(SYS_SPSR);
> > > > > u64 elr = read_sysreg_el2(SYS_ELR);
> > > > >
> > > >
> > > > We're getting into black-magic territory here. Why wouldn't hyp_panic
> > > > be in the .text section already?
> > >
> > > It's not quite black magic. LLVM essentially flips on
> > > -ffunction-sections with LTO and therefore, hyp_panic() will be in
> > > .text.hyp_panic in vmlinux.o, while __guest_enter() will be in .text.
> > > Everything ends up in .text when we link vmlinux, of course.
> > >
> > > $ readelf --sections vmlinux.o | grep hyp_panic
> > > [3936] .text.hyp_panic PROGBITS 004b56e4
> >
> > Note that disabling LTO here has essentially the same effect as using
> > __section(".text"). It stops the compiler from splitting these
> > functions into .text.* sections and makes it less likely that
> > hyp_panic() ends up too far away from __guest_enter().
> >
> > If neither of these workarounds sound appealing, I suppose we could
> > alternatively change hyp/entry.S to use adr_l for hyp_panic. Thoughts?
>
> That would be an actual fix instead of a workaround, as it would
> remove existing assumptions about the relative locations of the two
> objects. I guess you need to fix both instances with something such
> as:
>
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index b0afad7a99c6..a43e1f7ee354 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -85,8 +85,10 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
>
> // If the hyp context is loaded, go straight to hyp_panic
> get_loaded_vcpu x0, x1
> - cbz x0, hyp_panic
> -
> + cbnzx0, 1f
> + adr_l x0, hyp_panic
> + br x0
> +1:
Agree with replacing the conditional branches that refer to external
symbols: the compiler never emits those, for the reason we are seeing
here, i.e., the range is simply insufficient.
But let's just use 'b hyp_panic' instead, no?
> // The hyp context is saved so make sure it is restored to allow
> // hyp_panic to run at hyp and, subsequently, panic to run in the
> host.
> // This makes use of __guest_exit to avoid duplication but sets the
> @@ -94,7 +96,7 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
> // current state is saved to the guest context but it will only be
> // accurate if the guest had been completely restored.
> adr_this_cpu x0, kvm_hyp_ctxt, x1
> - adr x1, hyp_panic
> + adr_l x1, hyp_panic
> str x1, [x0, #CPU_XREG_OFFSET(30)]
>
> get_vcpu_ptrx1, x0
>
> which is completely untested. I wouldn't be surprised if there were
> more of these somewhere.
>
A quick grep gives me
$ objdump -r vmlinux.o |grep BR19
0005b6e0 R_AARCH64_CONDBR19 hyp_panic
00418e08 R_AARCH64_CONDBR19 __memcpy
00418e14 R_AARCH64_CONDBR19 __memcpy
3818 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3898 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3918 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3998 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3a18 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3a98 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3b18 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3b98 R_AARCH64_CONDBR19 __kvm_nvhe___guest_exit_panic
3c10 R_AARCH64_CONDBR19 __kvm_nvhe___host_exit
3c1c R_AARCH64_CONDBR19 __kvm_nvhe___host_exit
64f0 R_AARCH64_CONDBR19 __kvm_nvhe_hyp_panic
078c
Re: [PATCH] efi/apple-properties: Handle device properties with software node API
(+ Lukas) On Thu, 4 Mar 2021 at 09:28, Heikki Krogerus wrote: > > The old device property API is going to be removed. > Replacing the device_add_properties() call with the software > node API equivalent, device_create_managed_software_node(). > > Signed-off-by: Heikki Krogerus > --- > drivers/firmware/efi/apple-properties.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/apple-properties.c > b/drivers/firmware/efi/apple-properties.c > index e1926483ae2fd..4c3201e290e29 100644 > --- a/drivers/firmware/efi/apple-properties.c > +++ b/drivers/firmware/efi/apple-properties.c > @@ -157,7 +157,7 @@ static int __init unmarshal_devices(struct > properties_header *properties) > if (!entry[0].name) > goto skip_device; > > - ret = device_add_properties(dev, entry); /* makes deep copy */ > + ret = device_create_managed_software_node(dev, entry, NULL); > if (ret) > dev_err(dev, "error %d assigning properties\n", ret); > > -- > 2.30.1 >
Re: [PATCH] drivers: firmware: efi: fix Kconfig dependency on CRYPTO
On Sat, 27 Feb 2021 at 04:29, Julian Braha wrote: > > When EFI_EMBEDDED_FIRMWARE is enabled, and CRYPTO is not enabled, > Kbuild gives the following warning: > > WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256 > Depends on [n]: CRYPTO [=n] > Selected by [y]: > - EFI_EMBEDDED_FIRMWARE [=y] && EFI [=y] > > This is because EFI_EMBEDDED_FIRMWARE selects CRYPTO_LIB_SHA256 > without selecting or depending on CRYPTO, despite CRYPTO_LIB_SHA256 > depending on CRYPTO. > > Signed-off-by: Julian Braha Could you try the below instead? CRYPTO_LIB_SHA256 should not depend on CRYPTO in the first place, we should fix that if we can diff --git a/crypto/Kconfig b/crypto/Kconfig index a367fcfeb5d4..77e6bc6df0ee 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1936,9 +1936,10 @@ config CRYPTO_STATS config CRYPTO_HASH_INFO bool -source "lib/crypto/Kconfig" source "drivers/crypto/Kconfig" source "crypto/asymmetric_keys/Kconfig" source "certs/Kconfig" endif # if CRYPTO + +source "lib/crypto/Kconfig" > --- > drivers/firmware/efi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > index 2c3dac5ecb36..f914da9845ac 100644 > --- a/drivers/firmware/efi/Kconfig > +++ b/drivers/firmware/efi/Kconfig > @@ -248,6 +248,7 @@ endmenu > config EFI_EMBEDDED_FIRMWARE > bool > depends on EFI > + select CRYPTO > select CRYPTO_LIB_SHA256 > > config UEFI_CPER > -- > 2.27.0 >
Re: [PATCH 00/13] x86/crypto/asm: objtool support
On Wed, 24 Feb 2021 at 17:29, Josh Poimboeuf wrote: > > Standardize the crypto asm to make it resemble compiler-generated code, > so that objtool can understand it. > > This magically enables ORC unwinding from crypto code. It also fixes > the last known remaining objtool warnings on vmlinux.o, for LTO and > more. > > Josh Poimboeuf (13): > objtool: Support asm jump tables > x86/crypto/aesni-intel_avx: Remove unused macros > x86/crypto/aesni-intel_avx: Fix register usage comments > x86/crypto/aesni-intel_avx: Standardize stack alignment prologue > x86/crypto/camellia-aesni-avx2: Unconditionally allocate stack buffer > x86/crypto/crc32c-pcl-intel: Standardize jump table > x86/crypto/sha_ni: Standardize stack alignment prologue > x86/crypto/sha1_avx2: Standardize stack alignment prologue > x86/crypto/sha256-avx2: Standardize stack alignment prologue > x86/crypto/sha512-avx: Standardize stack alignment prologue > x86/crypto/sha512-avx2: Standardize stack alignment prologue > x86/crypto/sha512-ssse3: Standardize stack alignment prologue > x86/crypto: Enable objtool in crypto code > I gave this series a spin with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, and all the tests still pass. Tested-by: Ard Biesheuvel Acked-by: Ard Biesheuvel > arch/x86/crypto/Makefile | 2 - > arch/x86/crypto/aesni-intel_avx-x86_64.S | 28 + > arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 5 +-- > arch/x86/crypto/crc32c-pcl-intel-asm_64.S| 7 +--- > arch/x86/crypto/sha1_avx2_x86_64_asm.S | 8 ++-- > arch/x86/crypto/sha1_ni_asm.S| 8 ++-- > arch/x86/crypto/sha256-avx2-asm.S| 13 +++--- > arch/x86/crypto/sha512-avx-asm.S | 41 +-- > arch/x86/crypto/sha512-avx2-asm.S| 42 ++-- > arch/x86/crypto/sha512-ssse3-asm.S | 41 +-- > tools/objtool/check.c| 14 ++- > 11 files changed, 98 insertions(+), 111 deletions(-) > > -- > 2.29.2 >
Re: [PATCH 1/1] efi/efivars: ConInDev, ConOutDev, ConErrDev are volatile
(cc Peter)
On Thu, 18 Feb 2021 at 21:18, Heinrich Schuchardt wrote:
>
> UEFI variables ConInDev, ConOutDev, ConErrDev are volatile variables that
> are set by the firmware on every reset. It does not make sense to set these
> variables via the efivarfs filesystem.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/firmware/efi/vars.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 41c1d00bf933..561e0a01093b 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -180,11 +180,8 @@ static const struct variable_validate
> variable_validate[] = {
> { EFI_GLOBAL_VARIABLE_GUID, "DriverOrder", validate_boot_order },
> { EFI_GLOBAL_VARIABLE_GUID, "Driver*", validate_load_option },
> { EFI_GLOBAL_VARIABLE_GUID, "ConIn", validate_device_path },
> - { EFI_GLOBAL_VARIABLE_GUID, "ConInDev", validate_device_path },
> { EFI_GLOBAL_VARIABLE_GUID, "ConOut", validate_device_path },
> - { EFI_GLOBAL_VARIABLE_GUID, "ConOutDev", validate_device_path },
> { EFI_GLOBAL_VARIABLE_GUID, "ErrOut", validate_device_path },
> - { EFI_GLOBAL_VARIABLE_GUID, "ErrOutDev", validate_device_path },
> { EFI_GLOBAL_VARIABLE_GUID, "Lang", validate_ascii_string },
> { EFI_GLOBAL_VARIABLE_GUID, "OsIndications", NULL },
> { EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
> --
> 2.30.0
>
Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page
On Wed, 17 Feb 2021 at 10:42, Will Deacon wrote: > > [Please include arm64 and kvm folks for threads involving the stage-2 MMU] > > On Tue, Feb 16, 2021 at 03:47:52PM +0530, Preeti Nagar wrote: > > The changes introduce a new security feature, RunTime Integrity Check > > (RTIC), designed to protect Linux Kernel at runtime. The motivation > > behind these changes is: > > 1. The system protection offered by Security Enhancements(SE) for > > Android relies on the assumption of kernel integrity. If the kernel > > itself is compromised (by a perhaps as yet unknown future vulnerability), > > SE for Android security mechanisms could potentially be disabled and > > rendered ineffective. > > 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic > > checks to each stage of the boot-up process, to assert the authenticity > > of all secure software images that the device executes. However, due to > > various vulnerabilities in SW modules, the integrity of the system can be > > compromised at any time after device boot-up, leading to un-authorized > > SW executing. > > > > The feature's idea is to move some sensitive kernel structures to a > > separate page and monitor further any unauthorized changes to these, > > from higher Exception Levels using stage 2 MMU. Moving these to a > > different page will help avoid getting page faults from un-related data. > > The mechanism we have been working on removes the write permissions for > > HLOS in the stage 2 page tables for the regions to be monitored, such > > that any modification attempts to these will lead to faults being > > generated and handled by handlers. If the protected assets are moved to > > a separate page, faults will be generated corresponding to change attempts > > to these assets only. If not moved to a separate page, write attempts to > > un-related data present on the monitored pages will also be generated. > > > > Using this feature, some sensitive variables of the kernel which are > > initialized after init or are updated rarely can also be protected from > > simple overwrites and attacks trying to modify these. > > Although I really like the idea of using stage-2 to protect the kernel, I > think the approach you outline here is deeply flawed. Identifying "sensitive > variables" of the kernel to protect is subjective and doesn't scale. > Furthermore, the triaging of what constitues a valid access is notably > absent from your description and is assumedly implemented in an opaque blob > at EL2. > > I think a better approach would be along the lines of: > > 1. Introduce the protection at stage-1 (like we already have for mapping > e.g. the kernel text R/O) > > 2. Implement the handlers in the kernel, so the heuristics are clear. > > 3. Extend this to involve KVM, so that the host can manage its own > stage-2 to firm-up the stage-1 protections. > Agree here. Making an arbitrary set of data structures r/o behind the OS's back doesn't seem like an easy thing to maintain or reason about, especially if this r/o-ness is only enforced on a tiny subset of devices. If something needs to be writable only at boot, we have __ro_after_init, and having hypervisor assisted enforcement of /that/ might be a worthwhile thing to consider, including perhaps ways to do controlled patching of this region at runtime. > I also think we should avoid tying this to specific data structures. > Rather, we should introduce a mechanism to make arbitrary data read-only. > > I've CC'd Ard and Marc, as I think they've both been thinking about this > sort of thing recently as well. > > Will
Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled
On Tue, 16 Feb 2021 at 11:10, Peter Zijlstra wrote: > > On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using > > SIMD in kernel mode could reduce complexity and improve performance, but > > we > > need to decide whether we can do this, and how much softirq processing > > latency we can tolerate. If we can find a satisfactory solution for this, > > we might do the same for x86 and 32-bit ARM as well. ] > > > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > > expensive? > > Can't we simply save/restore the relevant register set? > > So something like (note amluto was wanting to add a regset argument): > > > kernel_fpu_begin(MMX) > > kernel_fpu_begin(SSE) > kernel_fpu_end(); > > ... > kernel_fpu_end() > > Would have to save the MMX regs on first SIRQ invocation of > kernel_fpu_begin(), and then have softirq context termination > above, restore it. > > I mean, we already do much the same for the first kernel_fpu_begin(), > that has to save the user registers, which will be restore when we go > back to userspace. > > So why not do exactly the same for softirq context? That is what we originally had on arm64, with per-CPU buffers of the appropriate size. This became a bit messy when SVE support was added, because the register file is so large (32 registers of up to 2048 bits each), and since the kernel does not use SVE itself, we want the inner per-CPU buffer to only cover 128 bits per register. This means we cannot allow the region above to interrupt the outer preserve (which is implemented entirely in software), since resuming the outer preserve after a sirq would preserve content that was corrupted by the inner preserve/restore. This could be addressed by disabling interrupts across the outer preserve, but this caused a problem somewhere else (Dave might remember the details better than I do). So we ended up making SIMD in task context mutually exclusive with SIMD in softirq context, also because that is what 32-bit ARM and x86 were already doing as well. But I understand that these concerns may not apply to x86 at all, so perhaps the answer there is indeed to have a alternate buffer. And actually, Andy L. suggested the same when I asked him about it on IRC.
Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check
On Tue, 16 Feb 2021 at 04:12, Anshuman Khandual wrote: > > > > On 2/16/21 1:21 AM, Pavel Tatashin wrote: > > On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel wrote: > >> > >> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin > >> wrote: > >>> > >>>> Can't we simply use signed arithmetic here? This expression works fine > >>>> if the quantities are all interpreted as s64 instead of u64 > >>> > >>> I was thinking about that, but I do not like the idea of using sign > >>> arithmetics for physical addresses. Also, I am worried that someone in > >>> the future will unknowingly change it to unsigns or to phys_addr_t. It > >>> is safer to have start explicitly set to 0 in case of wrap. > >> > >> memstart_addr is already a s64 for this exact reason. > > > > memstart_addr is basically an offset and it must be negative. For > > example, this would not work if it was not signed: > > #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> > > PAGE_SHIFT)) > > > > However, on powerpc it is phys_addr_t type. > > > >> > >> Btw, the KASLR check is incorrect: memstart_addr could also be > >> negative when running the 52-bit VA kernel on hardware that is only > >> 48-bit VA capable. > > > > Good point! > > > > if (IS_ENABLED(CONFIG_ARM64_VA_BITS_52) && (vabits_actual != 52)) > > memstart_addr -= _PAGE_OFFSET(48) - _PAGE_OFFSET(52); > > > > So, I will remove IS_ENABLED(CONFIG_RANDOMIZE_BASE) again. > > > > I am OK to change start_linear_pa, end_linear_pa to signed, but IMO > > what I have now is actually safer to make sure that does not break > > again in the future. > An explicit check for the flip over and providing two different start > addresses points would be required in order to use the new framework. I don't think so. We no longer randomize over the same range, but take the support PA range into account. (97d6786e0669d) This should ensure that __pa(_PAGE_OFFSET(vabits_actual)) never assumes a negative value. And to Pavel's point re 48/52 bit VAs: the fact that vabits_actual appears in this expression means that it already takes this into account, so you are correct that we don't have to care about that here. So even if memstart_addr could be negative, this expression should never produce a negative value. And with the patch above applied, it should never do so when running under KASLR either. So question to Pavel and Tyler: could you please check whether you have that patch, and whether it fixes the issue? It was introduced in v5.11, and hasn't been backported yet (it wasn't marked for -stable)
Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check
On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin wrote: > > > Can't we simply use signed arithmetic here? This expression works fine > > if the quantities are all interpreted as s64 instead of u64 > > I was thinking about that, but I do not like the idea of using sign > arithmetics for physical addresses. Also, I am worried that someone in > the future will unknowingly change it to unsigns or to phys_addr_t. It > is safer to have start explicitly set to 0 in case of wrap. memstart_addr is already a s64 for this exact reason. Btw, the KASLR check is incorrect: memstart_addr could also be negative when running the 52-bit VA kernel on hardware that is only 48-bit VA capable.
Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check
On Mon, 15 Feb 2021 at 20:22, Pavel Tatashin wrote:
>
> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
> linear map range is not checked correctly.
>
> The start physical address that linear map covers can be actually at the
> end of the range because of randomization. Check that and if so reduce it
> to 0.
>
> This can be verified on QEMU with setting kaslr-seed to ~0ul:
>
> memstart_offset_seed = 0x
> START: __pa(_PAGE_OFFSET(vabits_actual)) = 9000c000
> END: __pa(PAGE_END - 1) = 1000bfff
>
> Signed-off-by: Pavel Tatashin
> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear
> mapping")
> Tested-by: Tyler Hicks
> ---
> arch/arm64/mm/mmu.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ae0c3d023824..cc16443ea67f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1444,14 +1444,30 @@ static void __remove_pgd_mapping(pgd_t *pgdir,
> unsigned long start, u64 size)
>
> static bool inside_linear_region(u64 start, u64 size)
> {
> + u64 start_linear_pa = __pa(_PAGE_OFFSET(vabits_actual));
> + u64 end_linear_pa = __pa(PAGE_END - 1);
> +
> + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> + /*
> +* Check for a wrap, it is possible because of randomized
> linear
> +* mapping the start physical address is actually bigger than
> +* the end physical address. In this case set start to zero
> +* because [0, end_linear_pa] range must still be able to
> cover
> +* all addressable physical addresses.
> +*/
> + if (start_linear_pa > end_linear_pa)
> + start_linear_pa = 0;
> + }
> +
> + WARN_ON(start_linear_pa > end_linear_pa);
> +
> /*
> * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
> * accommodating both its ends but excluding PAGE_END. Max physical
> * range which can be mapped inside this linear mapping range, must
> * also be derived from its end points.
> */
> - return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> - (start + size - 1) <= __pa(PAGE_END - 1);
Can't we simply use signed arithmetic here? This expression works fine
if the quantities are all interpreted as s64 instead of u64
> + return start >= start_linear_pa && (start + size - 1) <=
> end_linear_pa;
> }
>
> int arch_add_memory(int nid, u64 start, u64 size,
> --
> 2.25.1
>
Re: [PATCH v7 0/2] ARM: Implement MODULE_PLT support in FTRACE
(+ Linus) On Wed, 3 Feb 2021 at 19:24, Florian Fainelli wrote: > > On 1/27/21 3:09 AM, Alexander A Sverdlin wrote: > > From: Alexander Sverdlin > > > > FTRACE's function tracer currently doesn't always work on ARM with > > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > > code modifier cannot cope with introduced veneers and turns the > > function tracer off globally. > > > > ARM64 already has a solution for the problem, refer to the following > > patches: > > > > arm64: ftrace: emit ftrace-mod.o contents through code > > arm64: module-plts: factor out PLT generation code for ftrace > > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > > arm64: ftrace: fix building without CONFIG_MODULES > > arm64: ftrace: add support for far branches to dynamic ftrace > > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > > > But the presented ARM variant has just a half of the footprint in terms of > > the changed LoCs. It also retains the code validation-before-modification > > instead of switching it off. > > Ard, Russell should this be sent to the patch tracker? Apologies for the delay. Unfortunately, I don't have time to review this. Linus?
Re: [RFC PATCH 4/5] arm64: fpsimd: run kernel mode NEON with softirqs disabled
On Wed, 20 Jan 2021 at 16:44, Dave Martin wrote: > > On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote: > > On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote: > > > > > > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote: > > > > Kernel mode NEON can be used in task or softirq context, but only in > > > > a non-nesting manner, i.e., softirq context is only permitted if the > > > > interrupt was not taken at a point where the kernel was using the NEON > > > > in task context. > > > > > > > > This means all users of kernel mode NEON have to be aware of this > > > > limitation, and either need to provide scalar fallbacks that may be much > > > > slower (up to 20x for AES instructions) and potentially less safe, or > > > > use an asynchronous interface that defers processing to a later time > > > > when the NEON is guaranteed to be available. > > > > > > > > Given that grabbing and releasing the NEON is cheap, we can relax this > > > > restriction, by increasing the granularity of kernel mode NEON code, and > > > > always disabling softirq processing while the NEON is being used in task > > > > context. > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > Sorry for the slow reply on this... it looks reasonable, but I have a > > > few comments below. > > > > > > > No worries - thanks for taking a look. > > > > > > --- > > > > arch/arm64/include/asm/assembler.h | 19 +-- > > > > arch/arm64/kernel/asm-offsets.c| 2 ++ > > > > arch/arm64/kernel/fpsimd.c | 4 ++-- > > > > 3 files changed, 17 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/arch/arm64/include/asm/assembler.h > > > > b/arch/arm64/include/asm/assembler.h > > > > index ddbe6bf00e33..74ce46ed55ac 100644 > > > > --- a/arch/arm64/include/asm/assembler.h > > > > +++ b/arch/arm64/include/asm/assembler.h > > > > @@ -15,6 +15,7 @@ > > > > #include > > > > > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -717,17 +718,23 @@ USER(\label, ic ivau, \tmp2) > > > > // invalidate I line PoU > > > > .endm > > > > > > > > .macro if_will_cond_yield_neon > > > > -#ifdef CONFIG_PREEMPTION > > > > get_current_taskx0 > > > > ldr x0, [x0, #TSK_TI_PREEMPT] > > > > - sub x0, x0, #PREEMPT_DISABLE_OFFSET > > > > - cbz x0, .Lyield_\@ > > > > +#ifdef CONFIG_PREEMPTION > > > > + cmp x0, #PREEMPT_DISABLE_OFFSET > > > > + beq .Lyield_\@ // yield on need_resched in task > > > > context > > > > +#endif > > > > + /* never yield while serving a softirq */ > > > > + tbnzx0, #SOFTIRQ_SHIFT, .Lnoyield_\@ > > > > > > Can you explain the rationale here? > > > > > > Using if_will_cond_yield_neon suggests the algo thinks it may run for > > > too long the stall preemption until completion, but we happily stall > > > preemption _and_ softirqs here. > > > > > > Is it actually a bug to use the NEON conditional yield helpers in > > > softirq context? > > > > > > > No, it is not. But calling kernel_neon_end() from softirq context will > > not cause it to finish any faster, so there is really no point in > > doing so. > > > > > Ideally, if processing in softirq context takes an unreasonable about of > > > time, the work would be handed off to an asynchronous worker, but that > > > does seem to conflict rather with the purpose of this series... > > > > > > > Agreed, but this is not something we can police at this level. If the > > caller does an unreasonable amount of work from a softirq, no amount > > of yielding is going to make a difference. > > Ack, just wanted to make sure I wasn't missing something. > > Anyone writing softirq code can starve preemption, so I agree that we > should trust people to know what they're doing. > > > > > > + > > > > + adr_l x0, irq_stat + IRQ_CPUSTAT_SOFTIRQ_PENDING > > > > + this_cpu_offset x1 > > > > +
Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL
On Fri, 29 Jan 2021 at 00:30, Ard Biesheuvel wrote:
>
> On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote:
> >
> > On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote:
> > > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers
> > > wrote:
> > > > @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
> > > >
> > > > TEST_UNSUPPORTED("strexbr0, r1, [r2]")
> > > > TEST_UNSUPPORTED("strexhr0, r1, [r2]")
> > > > - TEST_UNSUPPORTED("strexdr0, r1, [r2]")
> > > > + TEST_UNSUPPORTED("strexdr0, r1, r2, [r2]")
> > > > TEST_UNSUPPORTED("ldrexbr0, [r1]")
> > > > TEST_UNSUPPORTED("ldrexhr0, [r1]")
> > > > - TEST_UNSUPPORTED("ldrexdr0, [r1]")
> > > > + TEST_UNSUPPORTED("ldrexdr0, r1, [r1]")
> > > >
> > > > TEST_GROUP("Data-processing (shifted register) and (modified
> > > > immediate)")
> > > >
> > > > #define _DATA_PROCESSING32_DNM(op,s,val)
> > > > \
> > > > - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "")
> > > > \
> > > > + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "")
> > > > \
> > >
> > > What is wrong with these .w suffixes? Shouldn't the assembler accept
> > > these even on instructions that only exist in a wide encoding?
> >
> > I don't know if that is a bug in the integrated assembler or
> > intentional behavior, but it may be easier to just change the
> > kernel than the compiler in this case, as it also makes it work
> > for older versions.
> >
> > FWIW, I needed a related change in a couple of other files:
> >
>
> For fully specified test cases, I suppose removing the .w is fine. But
> for the macros below, it really isn't: it depends on the actual
> register assignment whether narrow encodings exist or not, and in that
> case, we definitely want the wide one. The fact that instantiating the
> macro in a different way can only produce wide encodings in the first
> place should really not trigger an error.
>
> Things like this can break the Thumb2 build very subtly, so if the
> integrated assembler is not up to that, we should simply disable it
> for Thumb2 builds.
>
As mentioned in issue #1271, my observation here is not entirely accurate.
In the general case, macros that take register names as inputs can
produce narrow or wide opcodes depending on which exact registers are
being used (narrow opcodes mostly only support registers r0-r7)
However, in this particular case, all the ldr/str instructions are
either the pre-indexed or the post-indexed variants, for which only a
wide encoding exists, and so omitting the .w suffix is safe here.
However, if we apply the change below, can we please document this in
a comment, i.e., that encoding T4 is used for LDR/STR, and so the
result is guaranteed to be wide in spite of the missing suffix?
> > diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S
> > index 6acdfde56849..3ced01d9afe4 100644
> > --- a/arch/arm/lib/copy_from_user.S
> > +++ b/arch/arm/lib/copy_from_user.S
> > @@ -60,7 +60,7 @@
> > #define LDR1W_SHIFT 0
> >
> > .macro ldr1w ptr reg abort
> > - USERL(\abort, W(ldr) \reg, [\ptr], #4)
> > + USERL(\abort, ldr \reg, [\ptr], #4)
> > .endm
> >
> > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
> > @@ -80,7 +80,7 @@
> > #define STR1W_SHIFT 0
> >
> > .macro str1w ptr reg abort
> > - W(str) \reg, [\ptr], #4
> > + str \reg, [\ptr], #4
> > .endm
> >
> > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
> > diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S
> > index 485fa3cffdbe..a6a96f814720 100644
> > --- a/arch/arm/lib/copy_to_user.S
> > +++ b/arch/arm/lib/copy_to_user.S
> > @@ -34,7 +34,7 @@
> > #define LDR1W_SHIFT 0
> >
> > .macro ldr1w ptr reg abort
> > - W(ldr) \reg, [\ptr], #4
> > + ldr \reg, [\ptr], #4
> > .endm
> >
> > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
> > @@ -77,7 +77,7 @@
> > #define STR1W_SHIFT 0
> >
> > .macro str1w ptr reg abort
> > - USERL(\abort, W(str) \reg, [\ptr], #4)
> > + USERL(\abort, str \reg, [\ptr], #4)
> > .endm
> >
> &g
Re: [PATCH] arm64: Fix warning in mte_get_random_tag()
On Thu, 11 Feb 2021 at 13:57, Vincenzo Frascino
wrote:
>
> The simplification of mte_get_random_tag() caused the introduction of the
> warning below:
>
> In file included from arch/arm64/include/asm/kasan.h:9,
> from include/linux/kasan.h:16,
> from mm/kasan/common.c:14:
> mm/kasan/common.c: In function ‘mte_get_random_tag’:
> arch/arm64/include/asm/mte-kasan.h:45:9: warning: ‘addr’ is used
> uninitialized [-Wuninitialized]
>45 | asm(__MTE_PREAMBLE "irg %0, %0"
> |
>
> Fix the warning initializing the address to NULL.
>
> Note: mte_get_random_tag() returns a tag and it never dereferences the
> address,
> hence 'addr' can be safely initialized to NULL.
>
> Fixes: c8f8de4c0887 ("arm64: kasan: simplify and inline MTE functions")
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Andrey Konovalov
> Cc: Andrew Morton
> Signed-off-by: Vincenzo Frascino
> ---
>
> This patch is based on linux-next/akpm
>
> arch/arm64/include/asm/mte-kasan.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/mte-kasan.h
> b/arch/arm64/include/asm/mte-kasan.h
> index 3d58489228c0..b2850b750726 100644
> --- a/arch/arm64/include/asm/mte-kasan.h
> +++ b/arch/arm64/include/asm/mte-kasan.h
> @@ -40,7 +40,12 @@ static inline u8 mte_get_mem_tag(void *addr)
> /* Generate a random tag. */
> static inline u8 mte_get_random_tag(void)
> {
> - void *addr;
> + /*
> +* mte_get_random_tag() returns a tag and it
> +* never dereferences the address, hence addr
> +* can be safely initialized to NULL.
> +*/
> + void *addr = NULL;
>
> asm(__MTE_PREAMBLE "irg %0, %0"
> : "+r" (addr));
> --
> 2.30.0
>
Might it be better to simply change the asm constraint to "=r" ?
Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled
On Tue, 9 Feb 2021 at 09:55, Shaobo Huang wrote:
>
> From: huangshaobo
>
> arm32 uses software to simulate the instruction replaced
> by kprobe. some instructions may be simulated by constructing
> assembly functions. therefore, before executing instruction
> simulation, it is necessary to construct assembly function
> execution environment in C language through binding registers.
> after kasan is enabled, the register binding relationship will
> be destroyed, resulting in instruction simulation errors and
> causing kernel panic.
>
> the kprobe emulate instruction function is distributed in three
> files: actions-common.c actions-arm.c actions-thumb.c, so disable
> KASAN when compiling these files.
>
> for example, use kprobe insert on cap_capable+20 after kasan
> enabled, the cap_capable assembly code is as follows:
> :
> e92d47f0push{r4, r5, r6, r7, r8, r9, sl, lr}
> e1a05000mov r5, r0
> e280006cadd r0, r0, #108; 0x6c
> e1a04001mov r4, r1
> e1a06002mov r6, r2
> e59fa090ldr sl, [pc, #144] ;
> ebfc7bf8bl c03aa4b4 <__asan_load4>
> e595706cldr r7, [r5, #108] ; 0x6c
> e2859014add r9, r5, #20
> ..
> The emulate_ldr assembly code after enabling kasan is as follows:
> c06f1384 :
> e92d47f0push{r4, r5, r6, r7, r8, r9, sl, lr}
> e282803cadd r8, r2, #60 ; 0x3c
> e1a05000mov r5, r0
> e7e37855ubfxr7, r5, #16, #4
> e1a8mov r0, r8
> e1a09001mov r9, r1
> e1a04002mov r4, r2
> ebf35462bl c03c6530 <__asan_load4>
> e357000fcmp r7, #15
> e7e36655ubfxr6, r5, #12, #4
> e205a00fand sl, r5, #15
> 0a01beq c06f13bc
> e0840107add r0, r4, r7, lsl #2
> ebf3545cbl c03c6530 <__asan_load4>
> e084010aadd r0, r4, sl, lsl #2
> ebf3545abl c03c6530 <__asan_load4>
> e2890010add r0, r9, #16
> ebf35458bl c03c6530 <__asan_load4>
> e5990010ldr r0, [r9, #16]
> e12fff30blx r0
> e356000fcm r6, #15
> 1a14bne c06f1430
> e1a06000mov r6, r0
> e2840040add r0, r4, #64 ; 0x40
> ..
> when running in emulate_ldr to simulate the ldr instruction, panic
> occurred, and the log is as follows:
> Unable to handle kernel NULL pointer dereference at virtual address
> 0090
> pgd = ecb46400
> [0090] *pgd=2e0fa003, *pmd=
> Internal error: Oops: 206 [#1] SMP ARM
> PC is at cap_capable+0x14/0xb0
> LR is at emulate_ldr+0x50/0xc0
> psr: 600d0293 sp : ecd63af8 ip : 0004 fp : c0a7c30c
> r10: r9 : c30897f4 r8 : ecd63cd4
> r7 : 000f r6 : 000a r5 : e59fa090 r4 : ecd63c98
> r3 : c06ae294 r2 : r1 : b7611300 r0 : bf4ec008
> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 32c5387d Table: 2d546400 DAC:
> Process bash (pid: 1643, stack limit = 0xecd60190)
> (cap_capable) from (kprobe_handler+0x218/0x340)
> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
> (do_undefinstr) from (__und_svc_finish+0x0/0x30)
> (__und_svc_finish) from (cap_capable+0x18/0xb0)
> (cap_capable) from (cap_vm_enough_memory+0x38/0x48)
> (cap_vm_enough_memory) from
> (security_vm_enough_memory_mm+0x48/0x6c)
> (security_vm_enough_memory_mm) from
> (copy_process.constprop.5+0x16b4/0x25c8)
> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
> (_do_fork) from (SyS_clone+0x1c/0x24)
> (SyS_clone) from (__sys_trace_return+0x0/0x10)
> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)
>
> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support")
> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
> Signed-off-by: huangshaobo
Acked-by: Ard Biesheuvel
> ---
> arch/arm/probes/kprobes/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/probes/kprobes/Makefile
> b/arch/arm/probes/kprobes/Makefile
> index 14db56f49f0a..6159010dac4a 100644
> --- a/arch/arm/probes/kprobes/Makefile
> +++ b/arch/arm/probes/kprobes/Makefile
> @@ -1,4 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> +KASAN_SANITIZE_actions-common.o := n
> +KASAN_SANITIZE_actions-arm.o := n
> +KASAN_SANITIZE_actions-thumb.o := n
> obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o
> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o
> test-kprobes-objs := test-core.o
> --
> 2.12.3
>
Re: [PATCH v2 14/14] x86/fault, x86/efi: Fix and rename efi_recover_from_page_fault()
On Wed, 10 Feb 2021 at 03:34, Andy Lutomirski wrote:
>
> efi_recover_from_page_fault() doesn't recover -- it does a special EFI
> mini-oops. Rename it to make it clear that it crashes.
>
> While renaming it, I noticed a blatant bug: a page fault oops in a
> different thread happening concurrently with an EFI runtime service call
> would be misinterpreted as an EFI page fault. Fix that.
>
> This isn't quite exact. We could do better by using a special CS for
> calls into EFI.
>
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Ard Biesheuvel
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
Acked-by: Ard Biesheuvel
> ---
> arch/x86/include/asm/efi.h | 2 +-
> arch/x86/mm/fault.c| 11 ++-
> arch/x86/platform/efi/quirks.c | 16
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index c98f78330b09..4b7706ddd8b6 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -150,7 +150,7 @@ extern void __init efi_apply_memmap_quirks(void);
> extern int __init efi_reuse_config(u64 tables, int nr_tables);
> extern void efi_delete_dummy_variable(void);
> extern void efi_switch_mm(struct mm_struct *mm);
> -extern void efi_recover_from_page_fault(unsigned long phys_addr);
> +extern void efi_crash_gracefully_on_page_fault(unsigned long phys_addr);
> extern void efi_free_boot_services(void);
>
> /* kexec external ABI */
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index eed217d4a877..dfdd56d9c020 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -16,7 +16,7 @@
> #include /* prefetchw*/
> #include /* exception_enter(), ... */
> #include /* faulthandler_disabled() */
> -#include /* efi_recover_from_page_fault()*/
> +#include /*
> efi_crash_gracefully_on_page_fault()*/
> #include
>
> #include /* boot_cpu_has, ...*/
> @@ -25,7 +25,7 @@
> #include /* emulate_vsyscall */
> #include /* struct vm86 */
> #include/* vma_pkey() */
> -#include/* efi_recover_from_page_fault()*/
> +#include/*
> efi_crash_gracefully_on_page_fault()*/
> #include /* store_idt(), ... */
> #include /* exception stack
> */
> #include /* VMALLOC_START, ... */
> @@ -700,11 +700,12 @@ page_fault_oops(struct pt_regs *regs, unsigned long
> error_code,
> #endif
>
> /*
> -* Buggy firmware could access regions which might page fault, try to
> -* recover from such faults.
> +* Buggy firmware could access regions which might page fault. If
> +* this happens, EFI has a special OOPS path that will try to
> +* avoid hanging the system.
> */
> if (IS_ENABLED(CONFIG_EFI))
> - efi_recover_from_page_fault(address);
> + efi_crash_gracefully_on_page_fault(address);
>
> oops:
> /*
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 5a40fe411ebd..0463ef9cddd6 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -687,15 +687,25 @@ int efi_capsule_setup_info(struct capsule_info
> *cap_info, void *kbuff,
> * @return: Returns, if the page fault is not handled. This function
> * will never return if the page fault is handled successfully.
> */
> -void efi_recover_from_page_fault(unsigned long phys_addr)
> +void efi_crash_gracefully_on_page_fault(unsigned long phys_addr)
> {
> if (!IS_ENABLED(CONFIG_X86_64))
> return;
>
> + /*
> +* If we are in an interrupt nested inside an EFI runtime service,
> +* then this is a regular OOPS, not an EFI failure.
> +*/
> + if (in_interrupt() || in_nmi() || in_softirq())
> + return;
> +
> /*
> * Make sure that an efi runtime service caused the page fault.
> +* READ_ONCE() because we might be OOPSing in a different thread,
> +* and we don't want to trip KTSAN while trying to OOPS.
> */
> - if (efi_rts_work.efi_rts_id == EFI_NONE)
> + if (READ_ONCE(efi_rts_work.efi_rts_id) == EFI_NONE ||
> + current_work() != _rts_work.work)
> return;
>
> /*
> @@ -747,6 +757,4 @@ void efi_recover_from_page_fault(unsigned long phys_addr)
> set_current_state(TASK_IDLE);
> schedule();
> }
> -
> - return;
> }
> --
> 2.29.2
>
Re: [PATCH v5 2/2] ARM: kprobes: rewrite test-arm.c in UAL
On Thu, 11 Feb 2021 at 03:52, Nick Desaulniers wrote:
>
> Clang's integrated assembler only accepts UAL syntax, rewrite the
> instructions that were changed by RVCTv2.1. The document "Assembly
> language changes after RVCTv2.1" was very helpful.
>
> .syntax unified
>
> directive is added, since -masm-syntax-unified is unreliable for older
> but supported versions of GCC. See also:
>
> commit fe09d9c641f2 ("ARM: 8852/1: uaccess: use unified assembler language
> syntax")
>
> Link:
> https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/assembly-language-changes-after-rvctv2-1
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Reported-by: Arnd Bergmann
> Signed-off-by: Nick Desaulniers
Acked-by: Ard Biesheuvel
> ---
> arch/arm/probes/kprobes/test-arm.c | 290 ++--
> arch/arm/probes/kprobes/test-core.h | 1 +
> 2 files changed, 146 insertions(+), 145 deletions(-)
>
> diff --git a/arch/arm/probes/kprobes/test-arm.c
> b/arch/arm/probes/kprobes/test-arm.c
> index 2543106a203e..a0dae35ffacd 100644
> --- a/arch/arm/probes/kprobes/test-arm.c
> +++ b/arch/arm/probes/kprobes/test-arm.c
> @@ -55,25 +55,25 @@ void kprobe_arm_test_cases(void)
> TEST_GROUP("Data-processing (register), (register-shifted register),
> (immediate)")
>
> #define _DATA_PROCESSING_DNM(op,s,val)
> \
> - TEST_RR( op "eq" s " r0, r",1, VAL1,", r",2, val, "")
> \
> - TEST_RR( op "ne" s " r1, r",1, VAL1,", r",2, val, ", lsl #3")
> \
> - TEST_RR( op "cs" s " r2, r",3, VAL1,", r",2, val, ", lsr #4")
> \
> - TEST_RR( op "cc" s " r3, r",3, VAL1,", r",2, val, ", asr #5")
> \
> - TEST_RR( op "mi" s " r4, r",5, VAL1,", r",2, N(val),", asr #6")
> \
> - TEST_RR( op "pl" s " r5, r",5, VAL1,", r",2, val, ", ror #7")
> \
> - TEST_RR( op "vs" s " r6, r",7, VAL1,", r",2, val, ", rrx")
> \
> - TEST_R( op "vc" s " r6, r",7, VAL1,", pc, lsl #3")
> \
> - TEST_R( op "vc" s " r6, r",7, VAL1,", sp, lsr #4")
> \
> - TEST_R( op "vc" s " r6, pc, r",7, VAL1,", asr #5")
> \
> - TEST_R( op "vc" s " r6, sp, r",7, VAL1,", ror #6")
> \
> - TEST_RRR( op "hi" s " r8, r",9, VAL1,", r",14,val, ", lsl r",0,
> 3,"")\
> - TEST_RRR( op "ls" s " r9, r",9, VAL1,", r",14,val, ", lsr r",7,
> 4,"")\
> - TEST_RRR( op "ge" s " r10, r",11,VAL1,", r",14,val, ", asr r",7,
> 5,"")\
> - TEST_RRR( op "lt" s " r11, r",11,VAL1,", r",14,N(val),", asr r",7,
> 6,"")\
> - TEST_RR( op "gt" s " r12, r13" ", r",14,val, ", ror
> r",14,7,"")\
> - TEST_RR( op "le" s " r14, r",0, val, ", r13" ", lsl
> r",14,8,"")\
> - TEST_R( op "eq" s " r0, r",11,VAL1,", #0xf5")
> \
> - TEST_R( op "ne" s " r11, r",0, VAL1,", #0xf500")
> \
> + TEST_RR( op s "eq r0, r",1, VAL1,", r",2, val, "")
> \
> + TEST_RR( op s "ne r1, r",1, VAL1,", r",2, val, ", lsl #3")
> \
> + TEST_RR( op s "cs r2, r",3, VAL1,", r",2, val, ", lsr #4")
> \
> + TEST_RR( op s "cc r3, r",3, VAL1,", r",2, val, ", asr #5")
> \
> + TEST_RR( op s "mi r4, r",5, VAL1,", r",2, N(val),", asr #6")
> \
> + TEST_RR( op s "pl r5, r",5, VAL1,", r",2, val, ", ror #7")
> \
> + TEST_RR( op s "vs r6, r",7, VAL1,", r",2, val, ", rrx")
> \
> + TEST_R( op s "vc r6, r&quo
Re: [PATCH v5 1/2] ARM: kprobes: fix UNPREDICTABLE warnings
On Thu, 11 Feb 2021 at 03:52, Nick Desaulniers wrote:
>
> GNU as warns twice for this file:
> Warning: using r15 results in unpredictable behaviour
>
> via the Arm ARM:
> K1.1.1 Overview of the constraints on Armv7 UNPREDICTABLE behaviors
>
> The term UNPREDICTABLE describes a number of cases where the
> architecture has a feature that software must not use.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Link: https://reviews.llvm.org/D95586
> Reported-by: kernelci.org bot
> Suggested-by: Peter Smith
> Suggested-by: Renato Golin
> Suggested-by: David Spickett
> Signed-off-by: Nick Desaulniers
Acked-by: Ard Biesheuvel
But can we add a bit more context to the commit log, please? It is not
obvious to the casual reader why it is OK to emit UNPREDICTABLE
opcodes, i.e., that these are selftests that aim to ensure that kprobe
never attempts to replace the opcodes in question with a probe, but
that they are not actually executed, or expected to occur in real
code.
> ---
> arch/arm/probes/kprobes/test-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/probes/kprobes/test-arm.c
> b/arch/arm/probes/kprobes/test-arm.c
> index 977369f1aa48..2543106a203e 100644
> --- a/arch/arm/probes/kprobes/test-arm.c
> +++ b/arch/arm/probes/kprobes/test-arm.c
> @@ -166,10 +166,10 @@ void kprobe_arm_test_cases(void)
>
> /* Data-processing with PC as a target and status registers updated */
> TEST_UNSUPPORTED("movs pc, r1")
> - TEST_UNSUPPORTED("movs pc, r1, lsl r2")
> + TEST_UNSUPPORTED(__inst_arm(0xe1b0f211) " @movs pc, r1, lsl
> r2")
> TEST_UNSUPPORTED("movs pc, #0x1")
> TEST_UNSUPPORTED("adds pc, lr, r1")
> - TEST_UNSUPPORTED("adds pc, lr, r1, lsl r2")
> + TEST_UNSUPPORTED(__inst_arm(0xe09ef211) " @adds pc, lr, r1,
> lsl r2")
> TEST_UNSUPPORTED("adds pc, lr, #4")
>
> /* Data-processing with SP as target */
> --
> 2.30.0.478.g8a0d178c01-goog
>
Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
On Mon, 8 Feb 2021 at 20:30, Kaneda, Erik wrote: > > > > > -Original Message----- > > From: Ard Biesheuvel > > Sent: Monday, February 8, 2021 11:14 AM > > To: Kaneda, Erik > > Cc: Rafael J. Wysocki ; Shawn Guo > > ; Linux ARM > ker...@lists.infradead.org>; ACPI Devel Maling List > a...@vger.kernel.org>; Linux Kernel Mailing List > ker...@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE > > (ACPICA) ; Wysocki, Rafael J > > ; Len Brown ; Moore, > > Robert > > Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using > > existing buffer" > > > > On Mon, 8 Feb 2021 at 20:07, Kaneda, Erik wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Rafael J. Wysocki > > > > Sent: Monday, February 8, 2021 5:01 AM > > > > To: Shawn Guo ; Ard Biesheuvel > > > > ; Kaneda, Erik > > > > Cc: Linux ARM ; ACPI Devel Maling > > > > List ; Linux Kernel Mailing List > > > ker...@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE > > > > (ACPICA) ; Wysocki, Rafael J > > > > ; Len Brown ; Moore, > > > > Robert > > > > Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by > > using > > > > existing buffer" > > > > > > > > On Sat, Feb 6, 2021 at 11:49 AM Shawn Guo > > wrote: > > > > > > > > > > On Sat, Feb 06, 2021 at 09:49:37AM +0100, Ard Biesheuvel wrote: > > > > > > This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4. > > > > > > > > > > > > Hi Bob, Ard and Rafael, > > > > > > > > > The 'exisitng buffer' in this case is the firmware provided table, > > > > > > and > > > > > > we should not modify that in place. This fixes a crash on arm64 with > > > > > > initrd table overrides, in which case the DSDT is not mapped with > > > > > > read/write permissions. > > > > > > Since this code runs on basically every _HID and _CID invocation, I would > > have expected this kind of revert to come in for kernels that do not use > > initrd > > override... So it sounds like there is a difference between how pages are > > mapped for initrd table overrides and tables exposed through the XSDT for > > ARM.. I think it would be easier for us to make these fixes in the future > > if we > > could all come to a consensus on whether if we should assume that these > > pages are writable or not. > > > > > > Should we assume that all ACPI tables are non-writable and read only > > regardless of initrd override and architecture? > > > > > > > ACPI tables are measured into the TPM on measured boot systems, and > > checksummed, so I don't think we should ever modify them in place. > > I'm not knowledgeable on TPM but I'm curious - what happens when the TPM > detects that these ACPI tables are modified? > That depends on the policy implemented in user space. The TPM itself does not detect this change, but these ACPI tables will no longer match their SHA hashes in the TPM event log, and this is something we should really avoid. > > > > But if we need code like this, it should be conditional at the very > > least, i.e., it should only rewrite _HIDs and _CIDs if they are > > incorrect to begin with. > > I agree that this would be a more efficient approach > Indeed.
Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
On Mon, 8 Feb 2021 at 20:07, Kaneda, Erik wrote: > > > > > -Original Message- > > From: Rafael J. Wysocki > > Sent: Monday, February 8, 2021 5:01 AM > > To: Shawn Guo ; Ard Biesheuvel > > ; Kaneda, Erik > > Cc: Linux ARM ; ACPI Devel Maling > > List ; Linux Kernel Mailing List > ker...@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE > > (ACPICA) ; Wysocki, Rafael J > > ; Len Brown ; Moore, > > Robert > > Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using > > existing buffer" > > > > On Sat, Feb 6, 2021 at 11:49 AM Shawn Guo wrote: > > > > > > On Sat, Feb 06, 2021 at 09:49:37AM +0100, Ard Biesheuvel wrote: > > > > This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4. > > > > > > Hi Bob, Ard and Rafael, > > > > > The 'exisitng buffer' in this case is the firmware provided table, and > > > > we should not modify that in place. This fixes a crash on arm64 with > > > > initrd table overrides, in which case the DSDT is not mapped with > > > > read/write permissions. > > Since this code runs on basically every _HID and _CID invocation, I would > have expected this kind of revert to come in for kernels that do not use > initrd override... So it sounds like there is a difference between how pages > are mapped for initrd table overrides and tables exposed through the XSDT for > ARM.. I think it would be easier for us to make these fixes in the future if > we could all come to a consensus on whether if we should assume that these > pages are writable or not. > > Should we assume that all ACPI tables are non-writable and read only > regardless of initrd override and architecture? > ACPI tables are measured into the TPM on measured boot systems, and checksummed, so I don't think we should ever modify them in place. But if we need code like this, it should be conditional at the very least, i.e., it should only rewrite _HIDs and _CIDs if they are incorrect to begin with.
Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth
On Mon, 8 Feb 2021 at 15:32, Will Deacon wrote: > > Hi Marc, > > On Mon, Feb 08, 2021 at 09:57:09AM +, Marc Zyngier wrote: > > It recently came to light that there is a need to be able to override > > some CPU features very early on, before the kernel is fully up and > > running. The reasons for this range from specific feature support > > (such as using Protected KVM on VHE HW, which is the main motivation > > for this work) to errata workaround (a feature is broken on a CPU and > > needs to be turned off, or rather not enabled). > > > > This series tries to offer a limited framework for this kind of > > problems, by allowing a set of options to be passed on the > > command-line and altering the feature set that the cpufeature > > subsystem exposes to the rest of the kernel. Note that this doesn't > > change anything for code that directly uses the CPU ID registers. > > I applied this locally, but I'm seeing consistent boot failure under QEMU when > KASAN is enabled. I tried sprinkling some __no_sanitize_address annotations > around (see below) but it didn't help. The culprit appears to be > early_fdt_map(), but looking a bit more closely, I'm really nervous about the > way we call into C functions from __primary_switched. Remember -- this code > runs _twice_ when KASLR is active: before and after the randomization. This > also means that any memory writes the first time around can be lost due to > the D-cache invalidation when (re-)creating the kernel page-tables. > Not just cache invalidation - BSS gets wiped again as well. -- Ard.
Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
On Mon, 8 Feb 2021 at 07:37, Vitaly Chikunov wrote:
>
> Herbert,
>
> On Fri, Jan 29, 2021 at 02:00:04PM +1100, Herbert Xu wrote:
> > On Thu, Jan 28, 2021 at 09:49:41PM -0500, Stefan Berger wrote:
> > >
> > > In my patch series I initially had registered the akciphers under the
> > > names
> > > ecc-nist-p192 and ecc-nist-p256 but now, in V4, joined them together as
> > > 'ecdsa'. This may be too generic for a name. Maybe it should be called
> > > ecsda-nist for the NIST family.
> >
> > What I'm proposing is specifying the curve in the name as well, i.e.,
> > ecdsa-nist-p192 instead of just ecdsa or ecdsa-nist.
> >
> > This simplifies the task of handling hardware that only supports a
> > subset of curves.
>
> So, if some implementation supports multiple curves (like EC-RDSA
> currently supports 5 curves), it should add 5 ecrdsa-{a,b,c,..}
> algorithms with actually the same top level implementation?
> Right?
>
Yes. The only difference will be the init() function, which can be
used to set the TFM properties that define which curve is being used.
The other routines can be generic, and refer to those properties if
the behavior is curve-specific.
>
> > There is a parallel discussion of exactly what curves we should
> > support in the kernel. Personally if there is a user in the kernel
> > for it then I'm happy to see it added. In your specific case, as
> > long as your use of the algorithm in x509 is accepted then I don't
> > have any problems with adding support in the Crypto API.
> >
> > Cheers,
> > --
> > Email: Herbert Xu
> > Home Page: http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3/3] crypto: hisilicon/sec - fixes shash test error
On Sun, 7 Feb 2021 at 03:47, liulongfang wrote: > > On 2021/2/5 19:44, Herbert Xu write: > > On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote: > >> If this configuration item is not turned on, > >> the allocation of crypto_tfm will fail when > >> the shash algorithm calculates the hash > >> through the software. > >> > >> Signed-off-by: Longfang Liu > >> --- > >> arch/arm64/configs/defconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >> index 8383016..7cfc9b6 100644 > >> --- a/arch/arm64/configs/defconfig > >> +++ b/arch/arm64/configs/defconfig > >> @@ -117,7 +117,7 @@ CONFIG_KVM=y > >> CONFIG_ARM64_CRYPTO=y > >> CONFIG_CRYPTO_SHA1_ARM64_CE=y > >> CONFIG_CRYPTO_SHA2_ARM64_CE=y > >> -CONFIG_CRYPTO_SHA512_ARM64_CE=m > >> +CONFIG_CRYPTO_SHA512_ARM64_CE=y > > > > If this is truly needed then it should be enabled through Kconfig. > > > > Cheers, > > > Hi Herbert, > The option select CRYPTO_SHA512 already exists in Kconfig. In that case, how can the shash TFM allocation fail? > Can I change it to this: select CRYPTO_SHA512 || CRYPTO_SHA512_ARM64_CE No, you cannot select expressions like that. Could you please explain the problem you are trying to solve?
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Sat, 6 Feb 2021 at 14:10, Guillaume Tucker wrote: > > On 05/02/2021 12:05, Ard Biesheuvel wrote: > > On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel wrote: > >> > >> On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker > >> wrote: > >>> > >>> On 04/02/2021 18:23, Nick Desaulniers wrote: > >>>> On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor > >>>> wrote: > >>>>> > >>>>> On Thu, Feb 04, 2021 at 10:06:08AM -0800, 'Nick Desaulniers' via Clang > >>>>> Built Linux wrote: > >>>>>> On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel wrote: > >>>>>>> > >>>>>>> On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> On 04/02/2021 15:42, Ard Biesheuvel wrote: > >>>>>>>>> On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Essentially: > >>>>>>>>>> > >>>>>>>>>> make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 > >>>>>>>>>> CC="ccache clang" zImage > >>>>>> > >>>>>> This command should link with BFD (and assemble with GAS; it's only > >>>>>> using clang as the compiler. > >>>>> > >>>>> I think you missed the 'LLVM=1' before CC="ccache clang". That should > >>>>> use all of the LLVM utilities minus the integrated assembler while > >>>>> wrapping clang with ccache. > >>>> > >>>> You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should > >>>> permit fallback to BFD. > >>> > >>> That was close, except we're cross-compiling with GCC for arm. > >>> So I've now built a plain next-20210203 (without Ard's fix) using > >>> this command line: > >>> > >>> make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm > >>> CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage > >>> > >>> I'm using a modified Docker image gtucker/kernelci-build-clang-11 > >>> with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf > >>> packages added to be able to use the GNU linker. BTW I guess we > >>> should enable this kind of hybrid build setup on kernelci.org as > >>> well. > >>> > >>> Full build log + kernel binaries can be found here: > >>> > >>> > >>> https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-41/arm/multi_v7_defconfig/clang-11/ > >>> > >>> And this booted fine, which confirms it's really down to how > >>> ld.lld puts together the kernel image. Does it actually solve > >>> the debate whether this is an issue to fix in the assembly code > >>> or at link time? > >>> > >>> Full test job details for the record: > >>> > >>> https://lava.collabora.co.uk/scheduler/job/3176004 > >>> > >> > >> > >> So the issue appears to be in the way the linker generates the > >> _kernel_bss_size symbol, which obviously has an impact, given that the > >> queued fix takes it into account in the cache_clean operation. > >> > >> On GNU ld, I see > >> > >>479: 00065e14 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size > >> > >> whereas n LLVM ld.lld, I see > >> > >>433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size > >> > >> and adding this value may cause the cache clean to operate on unmapped > >> addresses, or cause the addition to wrap and not perform a cache clean > >> at all. > >> > >> AFAICT, this also breaks the appended DTB case in LLVM, so this needs > >> a separate fix in any case. > > > > I pushed a combined branch of torvalds/master, rmk/fixes (still > > containing my 9052/1 fix) and this patch to my for-kernelci branch > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/ > > > > Guillaume, > > > > It seems there is no Clang-11 coverage there, right? Mind giving this > > branch a spin? If this fixes the regressions, we can get these queued > > up. > > That's right, Clang builds are only enabled on linux-next and > mainline at the moment. We could enable it on any other branch > where it makes sense. How about just the main defconfig for arm, > arm64 and x86_64 on your ardb/for-kernelci branch? > Yes, please. > For now I've run another set of builds with clang-11 and got the > following test results with your branch on staging: > > > https://staging.kernelci.org/test/job/ardb/branch/for-kernelci/kernel/v5.11-rc6-146-g923ca344043a/plan/baseline/ > > which are all passing. > > I'll reply to the thread with your patch to confirm. > Excellent, thanks a lot.
[PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4.
The 'exisitng buffer' in this case is the firmware provided table, and
we should not modify that in place. This fixes a crash on arm64 with
initrd table overrides, in which case the DSDT is not mapped with
read/write permissions.
Cc: Robert Moore
Cc: Erik Kaneda
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Reported-by: Shawn Guo
Signed-off-by: Ard Biesheuvel
---
drivers/acpi/acpica/nsrepair2.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/nsrepair2.c b/drivers/acpi/acpica/nsrepair2.c
index d2c8d8279e7a..24c197d91f29 100644
--- a/drivers/acpi/acpica/nsrepair2.c
+++ b/drivers/acpi/acpica/nsrepair2.c
@@ -495,8 +495,9 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info,
union acpi_operand_object **return_object_ptr)
{
union acpi_operand_object *return_object = *return_object_ptr;
- char *dest;
+ union acpi_operand_object *new_string;
char *source;
+ char *dest;
ACPI_FUNCTION_NAME(ns_repair_HID);
@@ -517,6 +518,13 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info,
return_ACPI_STATUS(AE_OK);
}
+ /* It is simplest to always create a new string object */
+
+ new_string = acpi_ut_create_string_object(return_object->string.length);
+ if (!new_string) {
+ return_ACPI_STATUS(AE_NO_MEMORY);
+ }
+
/*
* Remove a leading asterisk if present. For some unknown reason, there
* are many machines in the field that contains IDs like this.
@@ -526,7 +534,7 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info,
source = return_object->string.pointer;
if (*source == '*') {
source++;
- return_object->string.length--;
+ new_string->string.length--;
ACPI_DEBUG_PRINT((ACPI_DB_REPAIR,
"%s: Removed invalid leading asterisk\n",
@@ -541,11 +549,12 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info,
* "" where N is an uppercase letter or decimal digit, and
* # is a hex digit.
*/
- for (dest = return_object->string.pointer; *source; dest++, source++) {
+ for (dest = new_string->string.pointer; *source; dest++, source++) {
*dest = (char)toupper((int)*source);
}
- return_object->string.pointer[return_object->string.length] = 0;
+ acpi_ut_remove_reference(return_object);
+ *return_object_ptr = new_string;
return_ACPI_STATUS(AE_OK);
}
--
2.30.0
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel wrote: > > On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker > wrote: > > > > On 04/02/2021 18:23, Nick Desaulniers wrote: > > > On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor > > > wrote: > > >> > > >> On Thu, Feb 04, 2021 at 10:06:08AM -0800, 'Nick Desaulniers' via Clang > > >> Built Linux wrote: > > >>> On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel wrote: > > >>>> > > >>>> On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker > > >>>> wrote: > > >>>>> > > >>>>> On 04/02/2021 15:42, Ard Biesheuvel wrote: > > >>>>>> On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker > > >>>>>> wrote: > > >>>>>>> > > >>>>>>> Essentially: > > >>>>>>> > > >>>>>>> make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 > > >>>>>>> CC="ccache clang" zImage > > >>> > > >>> This command should link with BFD (and assemble with GAS; it's only > > >>> using clang as the compiler. > > >> > > >> I think you missed the 'LLVM=1' before CC="ccache clang". That should > > >> use all of the LLVM utilities minus the integrated assembler while > > >> wrapping clang with ccache. > > > > > > You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should > > > permit fallback to BFD. > > > > That was close, except we're cross-compiling with GCC for arm. > > So I've now built a plain next-20210203 (without Ard's fix) using > > this command line: > > > > make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm > > CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage > > > > I'm using a modified Docker image gtucker/kernelci-build-clang-11 > > with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf > > packages added to be able to use the GNU linker. BTW I guess we > > should enable this kind of hybrid build setup on kernelci.org as > > well. > > > > Full build log + kernel binaries can be found here: > > > > > > https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-41/arm/multi_v7_defconfig/clang-11/ > > > > And this booted fine, which confirms it's really down to how > > ld.lld puts together the kernel image. Does it actually solve > > the debate whether this is an issue to fix in the assembly code > > or at link time? > > > > Full test job details for the record: > > > > https://lava.collabora.co.uk/scheduler/job/3176004 > > > > > So the issue appears to be in the way the linker generates the > _kernel_bss_size symbol, which obviously has an impact, given that the > queued fix takes it into account in the cache_clean operation. > > On GNU ld, I see > >479: 00065e14 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size > > whereas n LLVM ld.lld, I see > >433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size > > and adding this value may cause the cache clean to operate on unmapped > addresses, or cause the addition to wrap and not perform a cache clean > at all. > > AFAICT, this also breaks the appended DTB case in LLVM, so this needs > a separate fix in any case. I pushed a combined branch of torvalds/master, rmk/fixes (still containing my 9052/1 fix) and this patch to my for-kernelci branch https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/ Guillaume, It seems there is no Clang-11 coverage there, right? Mind giving this branch a spin? If this fixes the regressions, we can get these queued up. Thanks, Ard.
Re: [PATCH] x86/efi: Remove EFI PGD build time checks
On Fri, 5 Feb 2021 at 12:39, Borislav Petkov wrote: > > From: Borislav Petkov > > With CONFIG_X86_5LEVEL, CONFIG_UBSAN and CONFIG_UBSAN_UNSIGNED_OVERFLOW > enabled, clang fails the build with > > x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function > `efi_sync_low_kernel_mappings': > efi_64.c:(.text+0x22c): undefined reference to `__compiletime_assert_354' > > which happens due to -fsanitize=unsigned-integer-overflow being enabled: > > -fsanitize=unsigned-integer-overflow: Unsigned integer overflow, where > the result of an unsigned integer computation cannot be represented > in its type. Unlike signed integer overflow, this is not undefined > behavior, but it is often unintentional. This sanitizer does not check > for lossy implicit conversions performed before such a computation > (see -fsanitize=implicit-conversion). > > and that fires when the (intentional) EFI_VA_START/END defines overflow > an unsigned long, leading to the assertion expressions not getting > optimized away (on GCC they do)... > > However, those checks are superfluous: the runtime services mapping > code already makes sure the ranges don't overshoot EFI_VA_END as the > EFI mapping range is hardcoded. On each runtime services call, it is > switched to the EFI-specific PGD and even if mappings manage to escape > that last PGD, this won't remain unnoticed for long. > > So rip them out. > > See https://github.com/ClangBuiltLinux/linux/issues/256 for more info. > > Reported-by: Arnd Bergmann > Link: http://lkml.kernel.org/r/20210107223424.4135538-1-a...@kernel.org > Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel > --- > arch/x86/platform/efi/efi_64.c | 19 --- > 1 file changed, 19 deletions(-) > > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c > index e1e8d4e3a213..8efd003540ca 100644 > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -115,31 +115,12 @@ void efi_sync_low_kernel_mappings(void) > pud_t *pud_k, *pud_efi; > pgd_t *efi_pgd = efi_mm.pgd; > > - /* > -* We can share all PGD entries apart from the one entry that > -* covers the EFI runtime mapping space. > -* > -* Make sure the EFI runtime region mappings are guaranteed to > -* only span a single PGD entry and that the entry also maps > -* other important kernel regions. > -*/ > - MAYBE_BUILD_BUG_ON(pgd_index(EFI_VA_END) != pgd_index(MODULES_END)); > - MAYBE_BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) != > - (EFI_VA_END & PGDIR_MASK)); > - > pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET); > pgd_k = pgd_offset_k(PAGE_OFFSET); > > num_entries = pgd_index(EFI_VA_END) - pgd_index(PAGE_OFFSET); > memcpy(pgd_efi, pgd_k, sizeof(pgd_t) * num_entries); > > - /* > -* As with PGDs, we share all P4D entries apart from the one entry > -* that covers the EFI runtime mapping space. > -*/ > - BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END)); > - BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK)); > - > pgd_efi = efi_pgd + pgd_index(EFI_VA_END); > pgd_k = pgd_offset_k(EFI_VA_END); > p4d_efi = p4d_offset(pgd_efi, 0); > -- > 2.29.2 > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker wrote: > > On 04/02/2021 18:23, Nick Desaulniers wrote: > > On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor wrote: > >> > >> On Thu, Feb 04, 2021 at 10:06:08AM -0800, 'Nick Desaulniers' via Clang > >> Built Linux wrote: > >>> On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel wrote: > >>>> > >>>> On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker > >>>> wrote: > >>>>> > >>>>> On 04/02/2021 15:42, Ard Biesheuvel wrote: > >>>>>> On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker > >>>>>> wrote: > >>>>>>> > >>>>>>> Essentially: > >>>>>>> > >>>>>>> make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 > >>>>>>> CC="ccache clang" zImage > >>> > >>> This command should link with BFD (and assemble with GAS; it's only > >>> using clang as the compiler. > >> > >> I think you missed the 'LLVM=1' before CC="ccache clang". That should > >> use all of the LLVM utilities minus the integrated assembler while > >> wrapping clang with ccache. > > > > You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should > > permit fallback to BFD. > > That was close, except we're cross-compiling with GCC for arm. > So I've now built a plain next-20210203 (without Ard's fix) using > this command line: > > make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm > CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage > > I'm using a modified Docker image gtucker/kernelci-build-clang-11 > with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf > packages added to be able to use the GNU linker. BTW I guess we > should enable this kind of hybrid build setup on kernelci.org as > well. > > Full build log + kernel binaries can be found here: > > > https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-41/arm/multi_v7_defconfig/clang-11/ > > And this booted fine, which confirms it's really down to how > ld.lld puts together the kernel image. Does it actually solve > the debate whether this is an issue to fix in the assembly code > or at link time? > > Full test job details for the record: > > https://lava.collabora.co.uk/scheduler/job/3176004 > So the issue appears to be in the way the linker generates the _kernel_bss_size symbol, which obviously has an impact, given that the queued fix takes it into account in the cache_clean operation. On GNU ld, I see 479: 00065e14 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size whereas n LLVM ld.lld, I see 433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size and adding this value may cause the cache clean to operate on unmapped addresses, or cause the addition to wrap and not perform a cache clean at all. AFAICT, this also breaks the appended DTB case in LLVM, so this needs a separate fix in any case.
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker wrote: > > On 04/02/2021 15:42, Ard Biesheuvel wrote: > > On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker > > wrote: > >> > >> On 04/02/2021 10:33, Guillaume Tucker wrote: > >>> On 04/02/2021 10:27, Ard Biesheuvel wrote: > >>>> On Thu, 4 Feb 2021 at 11:06, Russell King - ARM Linux admin > >>>> wrote: > >>>>> > >>>>> On Thu, Feb 04, 2021 at 10:07:58AM +0100, Ard Biesheuvel wrote: > >>>>>> On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Ard, > >>>>>>> > >>>>>>> Please see the bisection report below about a boot failure on > >>>>>>> rk3288 with next-20210203. It was also bisected on > >>>>>>> imx6q-var-dt6customboard with next-20210202. > >>>>>>> > >>>>>>> Reports aren't automatically sent to the public while we're > >>>>>>> trialing new bisection features on kernelci.org but this one > >>>>>>> looks valid. > >>>>>>> > >>>>>>> The kernel is most likely crashing very early on, so there's > >>>>>>> nothing in the logs. Please let us know if you need some help > >>>>>>> with debugging or trying a fix on these platforms. > >>>>>>> > >>>>>> > >>>>>> Thanks for the report. > >>>>> > >>>>> Ard, > >>>>> > >>>>> I want to send my fixes branch today which includes your regression > >>>>> fix that caused this regression. > >>>>> > >>>>> As this is proving difficult to fix, I can only drop your fix from > >>>>> my fixes branch - and given that this seems to be problematical, I'm > >>>>> tempted to revert the original change at this point which should fix > >>>>> both of these regressions - and then we have another go at getting rid > >>>>> of the set/way instructions during the next cycle. > >>>>> > >>>>> Thoughts? > >>>>> > >>>> > >>>> Hi Russell, > >>>> > >>>> If Guillaume is willing to do the experiment, and it fixes the issue, > >>> > >>> Yes, I'm running some tests with that fix now and should have > >>> some results shortly. > >> > >> Yes it does fix the issue: > >> > >> https://lava.collabora.co.uk/scheduler/job/3173819 > >> > >> with Ard's fix applied to this test branch: > >> > >> > >> https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210203-ard-fix/ > >> > >> > >> +clang +Nick > >> > >> It's worth mentioning that the issue only happens with kernels > >> built with Clang. As you can see there are several other arm > >> platforms failing with clang-11 builds but booting fine with > >> gcc-8: > >> > >> > >> https://kernelci.org/test/job/next/branch/master/kernel/next-20210203/plan/baseline/ > >> > >> Here's a sample build log: > >> > >> > >> https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-33/arm/multi_v7_defconfig/clang-11/build.log > >> > >> Essentially: > >> > >> make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache > >> clang" zImage > >> > >> I believe it should be using the GNU assembler as LLVM_IAS=1 is > >> not defined, but there may be something more subtle about it. > >> > > > > > > Do you have a link for a failing zImage built from multi_v7_defconfig? > > Sure, this one was built from a plain next-20210203: > > > http://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-33/arm/multi_v7_defconfig/clang-11/zImage > > You can also find the dtbs, modules and other things in that same > directory. > > For the record, here's the test job that used it: > > https://lava.collabora.co.uk/scheduler/job/3173792 > Thanks. That zImage boots fine locally. Unfortunately, I don't have rk3288 hardware to reproduce. Could you please point me to the list of all the other platforms that failed to boot this image? To be honest, I am slightly annoyed that a change that works fine with GCC but does not work with Clang version 11.1.0-++20210130110826+3a8282376b6c-1~exp1~20210130221445.158 (where exp means experimental, I suppose) is the reason for this discussion, especially because the change is in asm code. Is it possible to build with Clang but use the GNU linker?
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 15:36, Russell King - ARM Linux admin wrote: > > On Thu, Feb 04, 2021 at 03:25:20PM +0100, Ard Biesheuvel wrote: > > Pushing contents of the cache hierarchy to main memory is *not* a > > valid use of set/way ops, and so there is no point in pretending that > > set/way ops will produce the same results as by-VA ops. Only the by-VA > > ops give the architectural guarantees that we rely on for correctness. > > ... yet we /were/ doing that, and it worked fine for 13 years - from > 1st June 2007 until the by-VA merge into mainline on the 3rd April > 2020. > > You may be right that it wasn't the most correct way, but it worked > for those 13 years without issue, and it's only recently that it's > become a problem, and trying to "fix" that introduced a regression, > and fixing that regression has caused another regression... and I > what I'm wondering is how many more regression fixing cycles it's > going to take - how many regression fixes on top of other regression > fixes are we going to end up seeing here. > > The fact is, we never properly understood why your patch caused the > regression I was seeing. If we don't understand it, then we can never > say that we've fixed the problem properly. That is highlighted by the > fact that fixing the regression I was seeing has caused another > regression. > I agree with all these points. But as I pointed out, reverting the original by-VA change, which has been there for almost a year now, has some risks of its own. If we don't understand the details of how this is broken, how can we be sure we don't break something else if we revert it again? So I'm not arguing that reverting the original patch is unreasonable, just that doing so at this point in the cycle is risky, and that it would be better to queue the revert for v5.12, and only backport it after some soak time in -next. And in a sense, reinstating the cache_clean() before cache_off() already amounts to a partial revert of the queued fix.
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker wrote: > > On 04/02/2021 10:33, Guillaume Tucker wrote: > > On 04/02/2021 10:27, Ard Biesheuvel wrote: > >> On Thu, 4 Feb 2021 at 11:06, Russell King - ARM Linux admin > >> wrote: > >>> > >>> On Thu, Feb 04, 2021 at 10:07:58AM +0100, Ard Biesheuvel wrote: > >>>> On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker > >>>> wrote: > >>>>> > >>>>> Hi Ard, > >>>>> > >>>>> Please see the bisection report below about a boot failure on > >>>>> rk3288 with next-20210203. It was also bisected on > >>>>> imx6q-var-dt6customboard with next-20210202. > >>>>> > >>>>> Reports aren't automatically sent to the public while we're > >>>>> trialing new bisection features on kernelci.org but this one > >>>>> looks valid. > >>>>> > >>>>> The kernel is most likely crashing very early on, so there's > >>>>> nothing in the logs. Please let us know if you need some help > >>>>> with debugging or trying a fix on these platforms. > >>>>> > >>>> > >>>> Thanks for the report. > >>> > >>> Ard, > >>> > >>> I want to send my fixes branch today which includes your regression > >>> fix that caused this regression. > >>> > >>> As this is proving difficult to fix, I can only drop your fix from > >>> my fixes branch - and given that this seems to be problematical, I'm > >>> tempted to revert the original change at this point which should fix > >>> both of these regressions - and then we have another go at getting rid > >>> of the set/way instructions during the next cycle. > >>> > >>> Thoughts? > >>> > >> > >> Hi Russell, > >> > >> If Guillaume is willing to do the experiment, and it fixes the issue, > > > > Yes, I'm running some tests with that fix now and should have > > some results shortly. > > Yes it does fix the issue: > > https://lava.collabora.co.uk/scheduler/job/3173819 > > with Ard's fix applied to this test branch: > > https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210203-ard-fix/ > > > +clang +Nick > > It's worth mentioning that the issue only happens with kernels > built with Clang. As you can see there are several other arm > platforms failing with clang-11 builds but booting fine with > gcc-8: > > > https://kernelci.org/test/job/next/branch/master/kernel/next-20210203/plan/baseline/ > > Here's a sample build log: > > > https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-33/arm/multi_v7_defconfig/clang-11/build.log > > Essentially: > > make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache > clang" zImage > > I believe it should be using the GNU assembler as LLVM_IAS=1 is > not defined, but there may be something more subtle about it. > Do you have a link for a failing zImage built from multi_v7_defconfig?
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 15:09, Russell King - ARM Linux admin wrote: > > On Thu, Feb 04, 2021 at 12:26:44PM +, Marc Zyngier wrote: > > I agree. With set/way CMOs, there is no way to reach the PoC if > > it beyond the system cache, leading to an unbootable kernel. > > This is actually pretty well documented in the architecture, > > and it did bite us for the first time on XGene-1, 7 years ago. > > That may be, however we still do set/way maintenance to invalidate > the L1 cache as that is required for ARMv7 to place the cache into > a known state, as stated by the architecture reference manual. > Getting a certain cache at a certain level into a known state is a valid use of set/way ops, and is simply unnecessary when running under virtualization, but doesn't do any harm. Pushing contents of the cache hierarchy to main memory is *not* a valid use of set/way ops, and so there is no point in pretending that set/way ops will produce the same results as by-VA ops. Only the by-VA ops give the architectural guarantees that we rely on for correctness. > Arguably, that should be done by firmware, but when starting > secondary CPUs, there are platforms out there which do not bring > the L1 cache to a defined state. So we are pretty much stuck with > doing set/way operations during CPU initialisation in the main > kernel. > Indeed. And this is unfortunate, but not the end of the world. > If ARMv8 decides that this is not supportable, then that's a matter > for ARMv8 to address without impacting the requirements of ARMv7. > I'm not sure what you mean here. The v7 architecture is crystal clear about the difference between set/way ops (managing a single cache), and by-VA ops (managing the 'cachedness' state of a memory region). The semantics are radically different, regardless of v7 vs v8 or AArch32 vs AArch64.
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 12:45, Russell King - ARM Linux admin wrote: > > On Thu, Feb 04, 2021 at 11:32:05AM +, Guillaume Tucker wrote: > > Yes it does fix the issue: > > > > https://lava.collabora.co.uk/scheduler/job/3173819 > > > > with Ard's fix applied to this test branch: > > > > > > https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210203-ard-fix/ > > > > > > +clang +Nick > > > > It's worth mentioning that the issue only happens with kernels > > built with Clang. As you can see there are several other arm > > platforms failing with clang-11 builds but booting fine with > > gcc-8: > > My gut feeling is that it isn't Clang specific - it's likely down to > the exact code/data placement, how things end up during decompression, > and exactly what state the cache ends up in. > > That certainly was the case with the original regression. > Agreed. So given that my queued fix turns this cache_clean cache_off into this cache_off cache_clean for v7 only, and considering that turning this into cache_clean cache_off cache_clean (as the diff tested by Guillaume does) fixes the reported issue, it seems like the safest option to me at this point. Reverting both patches, one of which has been in mainline since v5.7, seems unwise to me at this point in the cycle.
Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index
On Thu, 4 Feb 2021 at 11:52, Borislav Petkov wrote: > > On Wed, Feb 03, 2021 at 09:29:18PM +0100, Ard Biesheuvel wrote: > > I think we have agreement on the approach but it is unclear who is > > going to write the patch. > > How's that below? > > And frankly, I'd even vote for removing those assertions altogether. If > somehow the EFI pgd lands somewhere else, the kernel will crash'n'burn > spectacularly and quickly so it's not like we won't catch it... > +1 for just removing them > --- > diff --git a/arch/x86/include/asm/pgtable_64_types.h > b/arch/x86/include/asm/pgtable_64_types.h > index 91ac10654570..b6be19c09841 100644 > --- a/arch/x86/include/asm/pgtable_64_types.h > +++ b/arch/x86/include/asm/pgtable_64_types.h > @@ -156,8 +156,8 @@ extern unsigned int ptrs_per_p4d; > #define CPU_ENTRY_AREA_PGD _AC(-4, UL) > #define CPU_ENTRY_AREA_BASE(CPU_ENTRY_AREA_PGD << P4D_SHIFT) > > -#define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) > -#define EFI_VA_END (-68 * (_AC(1, UL) << 30)) > +#define EFI_VA_START ( -4UL * (_AC(1, UL) << 30)) > +#define EFI_VA_END (-68UL * (_AC(1, UL) << 30)) > > #define EARLY_DYNAMIC_PAGE_TABLES 64 > > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c > index e1e8d4e3a213..56fdc0bbb554 100644 > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -123,9 +123,7 @@ void efi_sync_low_kernel_mappings(void) > * only span a single PGD entry and that the entry also maps > * other important kernel regions. > */ > - MAYBE_BUILD_BUG_ON(pgd_index(EFI_VA_END) != pgd_index(MODULES_END)); > - MAYBE_BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) != > - (EFI_VA_END & PGDIR_MASK)); > + MAYBE_BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) != PGDIR_MASK); > > pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET); > pgd_k = pgd_offset_k(PAGE_OFFSET); > @@ -137,8 +135,7 @@ void efi_sync_low_kernel_mappings(void) > * As with PGDs, we share all P4D entries apart from the one entry > * that covers the EFI runtime mapping space. > */ > - BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END)); > - BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK)); > + BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != P4D_MASK); > > pgd_efi = efi_pgd + pgd_index(EFI_VA_END); > pgd_k = pgd_offset_k(EFI_VA_END); > > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
Re: next/master bisection: baseline.login on rk3288-rock2-square
(cc Marc) On Thu, 4 Feb 2021 at 11:48, Russell King - ARM Linux admin wrote: > > On Thu, Feb 04, 2021 at 11:27:16AM +0100, Ard Biesheuvel wrote: > > Hi Russell, > > > > If Guillaume is willing to do the experiment, and it fixes the issue, > > it proves that rk3288 is relying on the flush before the MMU is > > disabled, and so in that case, the fix is trivial, and we can just > > apply it. > > > > If the experiment fails (which would mean rk3288 does not tolerate the > > cache maintenance being performed after cache off), it is going to be > > hairy, and so it will definitely take more time. > > > > So in the latter case (or if Guillaume does not get back to us), I > > think reverting my queued fix is the only sane option. But in that > > case, may I suggest that we queue the revert of the original by-VA > > change for v5.12 so it gets lots of coverage in -next, and allows us > > an opportunity to come up with a proper fix in the same timeframe, and > > backport the revert and the subsequent fix as a pair? Otherwise, we'll > > end up in the situation where v5.10.x until today has by-va, v5.10.x-y > > has set/way, and v5.10y+ has by-va again. (I don't think we care about > > anything before that, given that v5.4 predates any of this) > > I'm suggesting dropping your fix (9052/1) and reverting > "ARM: decompressor: switch to by-VA cache maintenance for v7 cores" > which gets us to a point where _both_ regressions are fixed. > I understand, but we don't know whether doing so might regress other platforms that were added in the mean time. > I'm of the opinion that the by-VA patch was incorrect when it was > merged (it caused a regression), and it's only a performance > improvement. It is a correctness improvement, not a performance improvement. Without that change, the 32-bit ARM kernel cannot boot bare metal on platforms with a system cache such as 8040 or SynQuacer, and can only boot under KVM on such systems because of the special handling of set/way instructions by the host. The performance issue related to set/way ops under KVM was already fixed by describing data and unified caches as 1 set and 1 way when running in 32-bit mode. > Our attempts so far to fix it are just causing other > regressions. So, I think it is reasonable to revert both back to a > known good point which has worked over a decade. If doing so causes > regressions (which I think is unlikely), then that would be unfortunate > but alas is a price that's worth paying to get back to a known good > point - since then we're not stacking regression fixes on top of other > regression fixes. > This is exactly why I am proposing to queue the revert of the original patch for v5.12, and only backport it to v5.10 and v5.11 once we are sure it does not break anything else.
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 11:06, Russell King - ARM Linux admin wrote: > > On Thu, Feb 04, 2021 at 10:07:58AM +0100, Ard Biesheuvel wrote: > > On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker > > wrote: > > > > > > Hi Ard, > > > > > > Please see the bisection report below about a boot failure on > > > rk3288 with next-20210203. It was also bisected on > > > imx6q-var-dt6customboard with next-20210202. > > > > > > Reports aren't automatically sent to the public while we're > > > trialing new bisection features on kernelci.org but this one > > > looks valid. > > > > > > The kernel is most likely crashing very early on, so there's > > > nothing in the logs. Please let us know if you need some help > > > with debugging or trying a fix on these platforms. > > > > > > > Thanks for the report. > > Ard, > > I want to send my fixes branch today which includes your regression > fix that caused this regression. > > As this is proving difficult to fix, I can only drop your fix from > my fixes branch - and given that this seems to be problematical, I'm > tempted to revert the original change at this point which should fix > both of these regressions - and then we have another go at getting rid > of the set/way instructions during the next cycle. > > Thoughts? > Hi Russell, If Guillaume is willing to do the experiment, and it fixes the issue, it proves that rk3288 is relying on the flush before the MMU is disabled, and so in that case, the fix is trivial, and we can just apply it. If the experiment fails (which would mean rk3288 does not tolerate the cache maintenance being performed after cache off), it is going to be hairy, and so it will definitely take more time. So in the latter case (or if Guillaume does not get back to us), I think reverting my queued fix is the only sane option. But in that case, may I suggest that we queue the revert of the original by-VA change for v5.12 so it gets lots of coverage in -next, and allows us an opportunity to come up with a proper fix in the same timeframe, and backport the revert and the subsequent fix as a pair? Otherwise, we'll end up in the situation where v5.10.x until today has by-va, v5.10.x-y has set/way, and v5.10y+ has by-va again. (I don't think we care about anything before that, given that v5.4 predates any of this) But in the end, I'm happy to go along with whatever works best for you.
Re: next/master bisection: baseline.login on rk3288-rock2-square
On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker
wrote:
>
> Hi Ard,
>
> Please see the bisection report below about a boot failure on
> rk3288 with next-20210203. It was also bisected on
> imx6q-var-dt6customboard with next-20210202.
>
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.
>
> The kernel is most likely crashing very early on, so there's
> nothing in the logs. Please let us know if you need some help
> with debugging or trying a fix on these platforms.
>
Thanks for the report.
Mind trying the following fix?
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -617,8 +617,10 @@ not_relocated: mov r0, #0
@ cache_clean_flush() redundant. In other cases, the clean is
@ performed by set/way and R0/R1 are ignored.
@
- mov r0, #0
- mov r1, #0
+ get_inflated_image_size r1, r2, r3
+
+ mov r0, r4 @ start of decompressed kernel
+ add r1, r1, r0 @ end of kernel BSS
bl cache_clean_flush
get_inflated_image_size r1, r2, r3
> On 04/02/2021 04:25, KernelCI bot wrote:
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > * This automated bisection report was sent to you on the basis *
> > * that you may be involved with the breaking commit it has *
> > * found. No manual investigation has been done to verify it, *
> > * and the root cause of the problem may be somewhere else. *
> > * *
> > * If you do send a fix, please include this trailer:*
> > * Reported-by: "kernelci.org bot" *
> > * *
> > * Hope this helps! *
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > next/master bisection: baseline.login on rk3288-rock2-square
> >
> > Summary:
> > Start: 58b6c0e507b7 Add linux-next specific files for 20210203
> > Plain log:
> > https://storage.kernelci.org/next/master/next-20210203/arm/multi_v7_defconfig/clang-11/lab-collabora/baseline-rk3288-rock2-square.txt
> > HTML log:
> > https://storage.kernelci.org/next/master/next-20210203/arm/multi_v7_defconfig/clang-11/lab-collabora/baseline-rk3288-rock2-square.html
> > Result: 5a29552af92d ARM: 9052/1: decompressor: cover BSS in cache
> > clean and reorder with MMU disable on v7
> >
> > Checks:
> > revert: PASS
> > verify: PASS
> >
> > Parameters:
> > Tree: next
> > URL:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > Branch: master
> > Target: rk3288-rock2-square
> > CPU arch: arm
> > Lab:lab-collabora
> > Compiler: clang-11
> > Config: multi_v7_defconfig
> > Test case: baseline.login
> >
> > Breaking commit found:
> >
> > ---
> > commit 5a29552af92dbd62c2b6fd1cddf7dad1ef7555b2
> > Author: Ard Biesheuvel
> > Date: Sun Jan 24 18:03:45 2021 +0100
> >
> > ARM: 9052/1: decompressor: cover BSS in cache clean and reorder with
> > MMU disable on v7
> >
> > Commit 401b368caaec ("ARM: decompressor: switch to by-VA cache
> > maintenance
> > for v7 cores") replaced the by-set/way cache maintenance in the
> > decompressor
> > with by-VA cache maintenance, which is more appropriate for the task at
> > hand, especially under virtualization on hosts with non-architected
> > system
> > caches that are not affected by by-set/way maintenance at all.
> >
> > On such systems, that commit inadvertently removed the cache clean and
> > invalidate of all of the guest's memory that is performed by KVM on
> > behalf
> > of the guest after its MMU is disabled (but only if any by-set/way cache
> > maintenance instructions were issued first). This resulted in various
> > erroneous behaviors observed by Russell, all involving the mini-stack
> > used by the core kernel's v7 boot code, and which resides in BSS. It
> > seems intractable to figure out exactly what goes wrong in each of these
> > cases, but some small experiments did suggest that the lack of a cache
> > clean and invalidate *after*
Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index
On Wed, 3 Feb 2021 at 19:51, Nathan Chancellor wrote:
>
> On Wed, Jan 20, 2021 at 10:33:43AM +0100, Ard Biesheuvel wrote:
> > On Mon, 18 Jan 2021 at 22:42, Arvind Sankar wrote:
> > >
> > > On Mon, Jan 18, 2021 at 09:24:09PM +0100, Borislav Petkov wrote:
> > > > > > > As a matter of fact, it seems like the four assertions could be
> > > > > > > combined
> > > > > > > into:
> > > > > > > BUILD_BUG_ON((EFI_VA_END & P4D_MASK) != (MODULES_END &
> > > > > > > P4D_MASK));
> > > > > > > BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END &
> > > > > > > P4D_MASK));
> > > > > > > instead of separately asserting they're the same PGD entry and
> > > > > > > the same
> > > > > > > P4D entry.
> > > > > > >
> > > > > > > Thanks.
> > > > > >
> > > > > > I actually don't quite get the MODULES_END check -- Ard, do you know
> > > > > > what that's for?
> > > > > >
> > > > >
> > > > > Maybe Boris remembers? He wrote the original code for the 'new' EFI
> > > > > page table layout.
> > > >
> > > > That was added by Kirill for 5-level pgtables:
> > > >
> > > > e981316f5604 ("x86/efi: Add 5-level paging support")
> > >
> > > That just duplicates the existing pgd_index() check for the p4d_index()
> > > as well. It looks like the original commit adding
> > > efi_sync_low_kernel_mappings() used to copy upto the PGD entry including
> > > MODULES_END:
> > > d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping")
> > > and then Matt changed that when creating efi_mm:
> > > 67a9108ed4313 ("x86/efi: Build our own page table structures")
> > > to use EFI_VA_END instead but have a check that EFI_VA_END is in the
> > > same entry as MODULES_END.
> > >
> > > AFAICT, MODULES_END is only relevant as being something that happens to
> > > be in the top 512GiB, and -1ul would be clearer.
> > >
> > > >
> > > > Documentation/x86/x86_64/mm.rst should explain the pagetable layout:
> > > >
> > > >ff80 | -512GB | ffee | 444 GB | ...
> > > > unused hole
> > > >ffef | -68GB | fffe | 64 GB | EFI
> > > > region mapping space
> > > > | -4GB | 7fff |2 GB | ...
> > > > unused hole
> > > >8000 | -2GB | 9fff | 512 MB | kernel
> > > > text mapping, mapped to physical address 0
> > > >8000 |-2048MB | | |
> > > >a000 |-1536MB | feff | 1520 MB | module
> > > > mapping space
> > > >ff00 | -16MB | | |
> > > > FIXADDR_START | ~-11MB | ff5f | ~0.5 MB |
> > > > kernel-internal fixmap range, variable size and offset
> > > >
> > > > That thing which starts at -512 GB above is the last PGD on the
> > > > pagetable. In it, between -4G and -68G there are 64G which are the EFI
> > > > region mapping space for runtime services.
> > > >
> > > > Frankly I'm not sure what this thing is testing because the EFI VA range
> > > > is hardcoded and I can't imagine it being somewhere else *except* in the
> > > > last PGD.
> > >
> > > It's just so that someone doesn't just change the #define's for
> > > EFI_VA_END/START and think that it will work, I guess.
> > >
> > > Another reasonable option, for example, would be to reserve an entire
> > > PGD entry, allowing everything but the PGD level to be shared, and
> > > adding the EFI PGD to the pgd_list and getting rid of
> > > efi_sync_low_kernel_mappings() altogether. There aren't that many PGD
> > > entries still unused though, so this is probably not worth it.
> > >
> >
> > The churn doesn't seem to be worth it, tbh.
> >
> > So could we get rid of the complexity here, and only build_bug() on
> > the start address of the EFI region being outside the topmost p4d?
> > That should make the PGD test redundant as well.
>
> Was there ever a resolution to this conversation or a patch sent? I am
> still seeing the build failure that Arnd initially sent the patch for.
> x86_64 all{mod,yes}config with clang are going to ship broken in 5.11.
>
I think we have agreement on the approach but it is unclear who is
going to write the patch.
Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote:
>
> Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Like how the MODULES_VADDR does now, just not to early populate
> the VMALLOC_START between VMALLOC_END.
> similarly, the kernel code mapping is now in the VMALLOC area and
> should keep these area populated.
>
> Signed-off-by: Lecopzer Chen
This commit log text is a bit hard to follow. You are saying that the
vmalloc region is *not* backed with zero shadow or any default mapping
at all, right, and everything gets allocated on demand, just like is
the case for modules?
> ---
> arch/arm64/mm/kasan_init.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index d8e66c78440e..39b218a64279 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
> {
> u64 kimg_shadow_start, kimg_shadow_end;
> u64 mod_shadow_start, mod_shadow_end;
> + u64 vmalloc_shadow_start, vmalloc_shadow_end;
> phys_addr_t pa_start, pa_end;
> u64 i;
>
> @@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
> mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
> mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
>
> + vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void
> *)VMALLOC_START);
> + vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
> +
This and the below seems overly complicated, given that VMALLOC_START
== MODULES_END. Can we simplify this?
> /*
> * We are going to perform proper setup of shadow memory.
> * At first we should unmap early shadow (clear_pgds() call below).
> @@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
>
> kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
>(void *)mod_shadow_start);
> - kasan_populate_early_shadow((void *)kimg_shadow_end,
> - (void *)KASAN_SHADOW_END);
> + if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
> + kasan_populate_early_shadow((void *)vmalloc_shadow_end,
> + (void *)KASAN_SHADOW_END);
> + if (vmalloc_shadow_start > mod_shadow_end)
> + kasan_populate_early_shadow((void *)mod_shadow_end,
> + (void
> *)vmalloc_shadow_start);
> +
> + } else {
> + kasan_populate_early_shadow((void *)kimg_shadow_end,
> + (void *)KASAN_SHADOW_END);
> + if (kimg_shadow_start > mod_shadow_end)
> + kasan_populate_early_shadow((void *)mod_shadow_end,
> + (void
> *)kimg_shadow_start);
> + }
>
> - if (kimg_shadow_start > mod_shadow_end)
> - kasan_populate_early_shadow((void *)mod_shadow_end,
> - (void *)kimg_shadow_start);
>
> for_each_mem_range(i, _start, _end) {
> void *start = (void *)__phys_to_virt(pa_start);
> --
> 2.25.1
>
Re: [PATCH v2 0/4] arm64: kasan: support CONFIG_KASAN_VMALLOC
On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote:
>
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64
> by not to populate the vmalloc area except for kimg address.
>
> Test environment:
> 4G and 8G Qemu virt,
> 39-bit VA + 4k PAGE_SIZE with 3-level page table,
> test by lib/test_kasan.ko and lib/test_kasan_module.ko
>
> It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL
> and randomize module region inside vmalloc area.
>
>
> [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")
>
> Signed-off-by: Lecopzer Chen
> Acked-by: Andrey Konovalov
> Tested-by: Andrey Konovalov
>
>
> v2 -> v1
> 1. kasan_init.c tweak indent
> 2. change Kconfig depends only on HAVE_ARCH_KASAN
> 3. support randomized module region.
>
> v1:
> https://lore.kernel.org/lkml/20210103171137.153834-1-lecop...@gmail.com/
>
> Lecopzer Chen (4):
> arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
> arm64: kasan: abstract _text and _end to KERNEL_START/END
> arm64: Kconfig: support CONFIG_KASAN_VMALLOC
> arm64: kaslr: support randomized module area with KASAN_VMALLOC
>
I failed to realize that VMAP_STACK and KASAN are currently mutually
exclusive on arm64, and that this series actually fixes that, which is
a big improvement, so it would make sense to call that out.
This builds and runs fine for me on a VM running under KVM.
Tested-by: Ard Biesheuvel
Re: [GIT PULL] arm64 fixes for 5.11-rc6
On Sun, 31 Jan 2021 at 19:55, Catalin Marinas wrote: > > On Fri, Jan 29, 2021 at 02:09:05PM -0800, Linus Torvalds wrote: > > On Fri, Jan 29, 2021 at 11:03 AM Catalin Marinas > > wrote: > > > > > > arm64 fixes: > > > > > > - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses. > > > > That's a really odd fix. > > > > It went from an incorrect bitwise operation (masking) to an _odd_ > > bitwise operation (xor). > > > > Yes, PAGE_OFFSET has the bit pattern of all upper bits set, so "(addr > > ^ PAGE_OFFSET)" by definition reverses the upper bits - and for a > > valid case turns them to zero. > > > > But isn't the *logical* thing to do to use a subtract instead? For the > > valid cases, the two do the same thing (clear the upper bits), but > > just conceptually, isn't the operation that you actually want to do > > "(addr - PAGE_OFFSET)"? > > > > IOW, why is it using that odd xor pattern that doesn't make much > > sense? I believe it _works_, but it looks very strange to me. > > This macro used to test a single bit and it evolved into a bitmask. So, > yes, basically what we need is: > > #define __is_lm_address(addr) ((u64)(addr) >= PAGE_OFFSET && \ > (u64)(addr) < PAGE_END) > > I wasn't sure whether the code generation with two comparisons is > similar to the xor variant but the compiler should probably be smart > enough to use CMP and CCMP. In the grand scheme, it probably doesn't > even matter. > > Unless I miss something, I don't see any overflow issues even if we do > (((u64)addr - PAGE_OFFSET) < (PAGE_END - PAGE_OFFSET)). > > We can backport the fix already upstream and clean-up the code in > mainline going forward (after some sanity check on the code generation). > It would be easier to parse in the future. > > > Also, shouldn't _lm_to_phys() do the same? It does that "mask upper > > bits" too that was problematic in __is_lm_address(). Again, shouldn't > > that logically be a subtract op? > > Yes, that's similar and a subtract should do. > The original bit test was written like that because it removes the need to reason about a potential tag in the upper bits. I tried to preserve that behavior when removing the guaranteed 1:1 split between the vmalloc and linear regions, by masking with PAGE_OFFSET and comparing with PAGE_END - PAGE_OFFSET, but unfortunately, both approaches suffer from the issue fixed by this patch, i.e., that virt_addr_valid(0x0) erroneously returns true. I think both proposed fixes are appropriate, but they both reintroduce the need to consider the tag. I don't know whether or where this could pose a problem, but it needs to be taken into account.
Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL
On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote:
>
> On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote:
> > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers
> > wrote:
> > > @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
> > >
> > > TEST_UNSUPPORTED("strexbr0, r1, [r2]")
> > > TEST_UNSUPPORTED("strexhr0, r1, [r2]")
> > > - TEST_UNSUPPORTED("strexdr0, r1, [r2]")
> > > + TEST_UNSUPPORTED("strexdr0, r1, r2, [r2]")
> > > TEST_UNSUPPORTED("ldrexbr0, [r1]")
> > > TEST_UNSUPPORTED("ldrexhr0, [r1]")
> > > - TEST_UNSUPPORTED("ldrexdr0, [r1]")
> > > + TEST_UNSUPPORTED("ldrexdr0, r1, [r1]")
> > >
> > > TEST_GROUP("Data-processing (shifted register) and (modified
> > > immediate)")
> > >
> > > #define _DATA_PROCESSING32_DNM(op,s,val)
> > > \
> > > - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "")
> > > \
> > > + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "")
> > > \
> >
> > What is wrong with these .w suffixes? Shouldn't the assembler accept
> > these even on instructions that only exist in a wide encoding?
>
> I don't know if that is a bug in the integrated assembler or
> intentional behavior, but it may be easier to just change the
> kernel than the compiler in this case, as it also makes it work
> for older versions.
>
> FWIW, I needed a related change in a couple of other files:
>
For fully specified test cases, I suppose removing the .w is fine. But
for the macros below, it really isn't: it depends on the actual
register assignment whether narrow encodings exist or not, and in that
case, we definitely want the wide one. The fact that instantiating the
macro in a different way can only produce wide encodings in the first
place should really not trigger an error.
Things like this can break the Thumb2 build very subtly, so if the
integrated assembler is not up to that, we should simply disable it
for Thumb2 builds.
> diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S
> index 6acdfde56849..3ced01d9afe4 100644
> --- a/arch/arm/lib/copy_from_user.S
> +++ b/arch/arm/lib/copy_from_user.S
> @@ -60,7 +60,7 @@
> #define LDR1W_SHIFT 0
>
> .macro ldr1w ptr reg abort
> - USERL(\abort, W(ldr) \reg, [\ptr], #4)
> + USERL(\abort, ldr \reg, [\ptr], #4)
> .endm
>
> .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
> @@ -80,7 +80,7 @@
> #define STR1W_SHIFT 0
>
> .macro str1w ptr reg abort
> - W(str) \reg, [\ptr], #4
> + str \reg, [\ptr], #4
> .endm
>
> .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
> diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S
> index 485fa3cffdbe..a6a96f814720 100644
> --- a/arch/arm/lib/copy_to_user.S
> +++ b/arch/arm/lib/copy_to_user.S
> @@ -34,7 +34,7 @@
> #define LDR1W_SHIFT 0
>
> .macro ldr1w ptr reg abort
> - W(ldr) \reg, [\ptr], #4
> + ldr \reg, [\ptr], #4
> .endm
>
> .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
> @@ -77,7 +77,7 @@
> #define STR1W_SHIFT 0
>
> .macro str1w ptr reg abort
> - USERL(\abort, W(str) \reg, [\ptr], #4)
> + USERL(\abort, str \reg, [\ptr], #4)
> .endm
>
> .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
> index e4caf48c089f..7b980a1a4227 100644
> --- a/arch/arm/lib/memcpy.S
> +++ b/arch/arm/lib/memcpy.S
> @@ -15,7 +15,7 @@
> #define STR1W_SHIFT 0
>
> .macro ldr1w ptr reg abort
> - W(ldr) \reg, [\ptr], #4
> + ldr \reg, [\ptr], #4
> .endm
>
> .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
> @@ -31,7 +31,7 @@
> .endm
>
> .macro str1w ptr reg abort
> - W(str) \reg, [\ptr], #4
> + str \reg, [\ptr], #4
> .endm
>
> .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
> diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S
> index 6fecc12a1f51..35c5c06b7588 100644
> --- a/arch/arm/lib/memmove.S
> +++ b/arch/arm/lib/memmove.S
> @@ -84,24 +84,24 @@ WEAK(memmove)
> addne pc, pc, ip @ C is always clear here
> b 7f
> 6: W(nop)
> - W(ldr) r3, [r1, #-4]!
> - W(ldr) r4, [r1, #-4]!
> - W(ldr) r5, [r1, #-4]!
> - W(ldr) r6, [r1, #-4]!
> - W(ldr) r7, [r1, #-4]!
> - W(ldr) r8, [r1, #-4]!
> - W(ldr) lr, [r1, #-4]!
> + ldr r3, [r1, #-4]!
> + ldr r4, [r1, #-4]!
> + ldr r5, [r1, #-4]!
> + ldr r6, [r1, #-4]!
> + ldr r7, [r1, #-4]!
> + ldr r8, [r1, #-4]!
> + ldr lr, [r1, #-4]!
>
> add pc, pc, ip
> nop
> W(nop)
> - W(str) r3, [r0, #-4]!
> - W(str) r4, [r0, #-4]!
> - W(str) r5, [r0, #-4]!
> - W(str) r6, [r0, #-4]!
> - W(str) r7, [r0, #-4]!
> - W(str) r8, [r0, #-4]!
> - W(str) lr, [r0, #-4]!
> + str r3, [r0, #-4]!
> + str r4, [r0, #-4]!
> + str r5, [r0, #-4]!
> + str r6, [r0, #-4]!
> + str r7, [r0, #-4]!
> + str r8, [r0, #-4]!
> + str lr, [r0, #-4]!
>
> CALGN( bcs 2b )
Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL
On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers wrote:
>
> Clang's integrated assembler only accepts UAL syntax, rewrite the
> instructions that were changed by RVCTv2.1.
>
> The document "Assembly language changes after RVCTv2.1" was very
> helpful.
>
> This exposed a bug in Clang's integrated assembler, which hopefully will
> land in clang-12, but is required to test this patch with LLVM_IAS=1.
>
> Link:
> https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/assembly-language-changes-after-rvctv2-1
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Link: https://reviews.llvm.org/D95586
> Reported-by: Arnd Bergmann
> Signed-off-by: Nick Desaulniers
> ---
> * Fix additonal swpvsb case in test-arm.c when __LINUX_ARM_ARCH__ < 6,
> reported by Arnd.
> * Fix arch/arm/probes/kprobes/test-thumb.c, reported by Arnd.
> * Modify the oneline to note I'm modifying test-*.c.
>
> arch/arm/probes/kprobes/test-arm.c | 290 +--
> arch/arm/probes/kprobes/test-thumb.c | 20 +-
> 2 files changed, 155 insertions(+), 155 deletions(-)
>
...
> diff --git a/arch/arm/probes/kprobes/test-thumb.c
> b/arch/arm/probes/kprobes/test-thumb.c
> index 456c181a7bfe..63277c1006b9 100644
> --- a/arch/arm/probes/kprobes/test-thumb.c
> +++ b/arch/arm/probes/kprobes/test-thumb.c
> @@ -441,21 +441,21 @@ void kprobe_thumb32_test_cases(void)
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RX("tbh[pc, r",7, (9f-(1f+4))>>1,"]",
> + TEST_RX("tbh[pc, r",7, (9f-(1f+4))>>1,", lsl #1]",
Why is this change needed? Are the resulting opcodes equivalent? Does
GAS infer the lsl #1 but Clang doesn't?
> "9: \n\t"
> ".short (2f-1b-4)>>1\n\t"
> ".short (3f-1b-4)>>1\n\t"
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RX("tbh[pc, r",12, ((9f-(1f+4))>>1)+1,"]",
> + TEST_RX("tbh[pc, r",12, ((9f-(1f+4))>>1)+1,", lsl #1]",
> "9: \n\t"
> ".short (2f-1b-4)>>1\n\t"
> ".short (3f-1b-4)>>1\n\t"
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RRX("tbh [r",1,9f, ", r",14,1,"]",
> + TEST_RRX("tbh [r",1,9f, ", r",14,1,", lsl #1]",
> "9: \n\t"
> ".short (2f-1b-4)>>1\n\t"
> ".short (3f-1b-4)>>1\n\t"
> @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
>
> TEST_UNSUPPORTED("strexbr0, r1, [r2]")
> TEST_UNSUPPORTED("strexhr0, r1, [r2]")
> - TEST_UNSUPPORTED("strexdr0, r1, [r2]")
> + TEST_UNSUPPORTED("strexdr0, r1, r2, [r2]")
> TEST_UNSUPPORTED("ldrexbr0, [r1]")
> TEST_UNSUPPORTED("ldrexhr0, [r1]")
> - TEST_UNSUPPORTED("ldrexdr0, [r1]")
> + TEST_UNSUPPORTED("ldrexdr0, r1, [r1]")
>
> TEST_GROUP("Data-processing (shifted register) and (modified
> immediate)")
>
> #define _DATA_PROCESSING32_DNM(op,s,val)
> \
> - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "")
> \
> + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "")
> \
What is wrong with these .w suffixes? Shouldn't the assembler accept
these even on instructions that only exist in a wide encoding?
> TEST_RR(op s" r1, r",1, VAL1,", r",2, val, ", lsl #3")
> \
> TEST_RR(op s" r2, r",3, VAL1,", r",2, val, ", lsr #4")
> \
> TEST_RR(op s" r3, r",3, VAL1,", r",2, val, ", asr #5")
> \
> @@ -764,7 +764,7 @@ CONDITION_INSTRUCTIONS(22,
> TEST("nop.w")
> TEST("wfi.w")
> TEST_SUPPORTED("wfe.w")
> - TEST_UNSUPPORTED("dbg.w #0")
> + TEST_UNSUPPORTED("dbg #0")
>
> TEST_UNSUPPORTED("clrex")
> TEST_UNSUPPORTED("dsb")
> @@ -790,9 +790,9 @@ CONDITION_INSTRUCTIONS(22,
> TEST_BB( "b.w 2b")
> TEST_BF_X("b.w 2f", SPACE_0x1000)
>
> - TEST_BF( "bl.w 2f")
> - TEST_BB( "bl.w 2b")
> - TEST_BB_X("bl.w 2b", SPACE_0x1000)
> + TEST_BF( "bl 2f")
> + TEST_BB( "bl 2b")
> + TEST_BB_X("bl 2b", SPACE_0x1000)
>
> TEST_X( "blx__dummy_arm_subroutine",
> ".arm \n\t"
> --
> 2.30.0.365.g02bc693789-goog
>
Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
On Thu, 28 Jan 2021 at 06:04, Herbert Xu wrote: > > On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote: > > 1. Add ecc curves(P224, P384, P521) for ECDH; > > OK I think this is getting unwieldy. > > In light of the fact that we already have hardware that supports > a specific subset of curves, I think perhaps it would be better > to move the curve ID from the key into the algorithm name instead. > > IOW, instead of allocating ecdh, you would allocate ecdh-nist-pXXX. > > Any comments? > Agreed. Bluetooth appears to be the only in-kernel user at the moment, and it is hard coded to use p256, so it can be easily updated. But this also begs the question which ecdh-nist-pXXX implementations we actually need? Why are we exposing these curves in the first place?
[tip: efi/core] efi: x86: move mixed mode stack PA variable out of 'efi_scratch'
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Gitweb:
https://git.kernel.org/tip/3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:16:27 +01:00
Committer: Ard Biesheuvel
CommitterDate: Tue, 19 Jan 2021 17:57:16 +01:00
efi: x86: move mixed mode stack PA variable out of 'efi_scratch'
As a first step to removing the awkward 'struct efi_scratch' definition
that conveniently combines the storage of the mixed mode stack pointer
with the MM pointer variable that records the task's MM pointer while it
is being replaced with the EFI MM one, move the mixed mode stack pointer
into a separate variable.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/efi.h | 3 +--
arch/x86/platform/efi/efi_64.c | 2 +-
arch/x86/platform/efi/efi_thunk_64.S | 6 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index c98f783..5e37e6d 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -12,6 +12,7 @@
#include
extern unsigned long efi_fw_vendor, efi_config_table;
+extern unsigned long efi_mixed_mode_stack_pa;
/*
* We map the EFI regions needed for runtime services non-contiguously,
@@ -96,11 +97,9 @@ extern asmlinkage u64 __efi_call(void *fp, ...);
/*
* struct efi_scratch - Scratch space used while switching to/from efi_mm
- * @phys_stack: stack used during EFI Mixed Mode
* @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
*/
struct efi_scratch {
- u64 phys_stack;
struct mm_struct*prev_mm;
} __packed;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index e1e8d4e..1d90418 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -256,7 +256,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap,
unsigned num_pages)
return 1;
}
- efi_scratch.phys_stack = page_to_phys(page + 1); /* stack grows down */
+ efi_mixed_mode_stack_pa = page_to_phys(page + 1); /* stack grows down */
npages = (_etext - _text) >> PAGE_SHIFT;
text = __pa(_text);
diff --git a/arch/x86/platform/efi/efi_thunk_64.S
b/arch/x86/platform/efi/efi_thunk_64.S
index 26f0da2..fd3dd17 100644
--- a/arch/x86/platform/efi/efi_thunk_64.S
+++ b/arch/x86/platform/efi/efi_thunk_64.S
@@ -33,7 +33,7 @@ SYM_CODE_START(__efi64_thunk)
* Switch to 1:1 mapped 32-bit stack pointer.
*/
movq%rsp, %rax
- movqefi_scratch(%rip), %rsp
+ movqefi_mixed_mode_stack_pa(%rip), %rsp
push%rax
/*
@@ -70,3 +70,7 @@ SYM_CODE_START(__efi64_thunk)
pushl %ebp
lret
SYM_CODE_END(__efi64_thunk)
+
+ .bss
+ .balign 8
+SYM_DATA(efi_mixed_mode_stack_pa, .quad 0)
[tip: efi/core] efi/libstub: fix prototype of efi_tcg2_protocol::get_event_log()
The following commit has been merged into the efi/core branch of tip:
Commit-ID: cdec91c034a2c99331b62a5f417bf7527fa6d490
Gitweb:
https://git.kernel.org/tip/cdec91c034a2c99331b62a5f417bf7527fa6d490
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 10:04:39 +01:00
Committer: Ard Biesheuvel
CommitterDate: Tue, 19 Jan 2021 17:57:15 +01:00
efi/libstub: fix prototype of efi_tcg2_protocol::get_event_log()
efi_tcg2_protocol::get_event_log() takes a protocol pointer as the
first argument, not a EFI handle.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/efistub.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/efistub.h
b/drivers/firmware/efi/libstub/efistub.h
index b50a6c6..2b7438b 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -672,7 +672,7 @@ typedef union efi_tcg2_protocol efi_tcg2_protocol_t;
union efi_tcg2_protocol {
struct {
void *get_capability;
- efi_status_t (__efiapi *get_event_log)(efi_handle_t,
+ efi_status_t (__efiapi *get_event_log)(efi_tcg2_protocol_t *,
efi_tcg2_event_log_format,
efi_physical_addr_t *,
efi_physical_addr_t *,
[tip: efi/core] efi/libstub: move TPM related prototypes into efistub.h
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3820749ddcee694abfd5ae6cabc18aaab11eab34
Gitweb:
https://git.kernel.org/tip/3820749ddcee694abfd5ae6cabc18aaab11eab34
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 11:51:10 +01:00
Committer: Ard Biesheuvel
CommitterDate: Tue, 19 Jan 2021 17:57:15 +01:00
efi/libstub: move TPM related prototypes into efistub.h
Move TPM related definitions that are only used in the EFI stub into
efistub.h, which is a local header.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/efistub.h | 9 +
include/linux/efi.h| 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efistub.h
b/drivers/firmware/efi/libstub/efistub.h
index 2b7438b..cde0a2e 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -849,4 +849,13 @@ void efi_handle_post_ebs_state(void);
enum efi_secureboot_mode efi_get_secureboot(void);
+#ifdef CONFIG_RESET_ATTACK_MITIGATION
+void efi_enable_reset_attack_mitigation(void);
+#else
+static inline void
+efi_enable_reset_attack_mitigation(void) { }
+#endif
+
+void efi_retrieve_tpm2_eventlog(void);
+
#endif
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 2537a24..8710f57 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1104,13 +1104,6 @@ enum efi_secureboot_mode
efi_get_secureboot_mode(efi_get_variable_t *get_var)
return efi_secureboot_mode_enabled;
}
-#ifdef CONFIG_RESET_ATTACK_MITIGATION
-void efi_enable_reset_attack_mitigation(void);
-#else
-static inline void
-efi_enable_reset_attack_mitigation(void) { }
-#endif
-
#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE
void efi_check_for_embedded_firmwares(void);
#else
@@ -1119,8 +1112,6 @@ static inline void efi_check_for_embedded_firmwares(void)
{ }
efi_status_t efi_random_get_seed(void);
-void efi_retrieve_tpm2_eventlog(void);
-
/*
* Arch code can implement the following three template macros, avoiding
* reptition for the void/non-void return cases of {__,}efi_call_virt():
[tip: efi/core] efi: ia64: move IA64-only declarations to new asm/efi.h header
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 8ff059b8531f3b98e14f0461859fc7cdd95823e4
Gitweb:
https://git.kernel.org/tip/8ff059b8531f3b98e14f0461859fc7cdd95823e4
Author:Ard Biesheuvel
AuthorDate:Mon, 18 Jan 2021 13:38:42 +01:00
Committer: Ard Biesheuvel
CommitterDate: Mon, 18 Jan 2021 13:50:37 +01:00
efi: ia64: move IA64-only declarations to new asm/efi.h header
Move some EFI related declarations that are only referenced on IA64 to
a new asm/efi.h arch header.
Cc: Tony Luck
Cc: Fenghua Yu
Signed-off-by: Ard Biesheuvel
---
arch/ia64/include/asm/efi.h | 13 +
arch/ia64/kernel/efi.c | 1 +
arch/ia64/kernel/machine_kexec.c | 1 +
arch/ia64/kernel/mca.c | 1 +
arch/ia64/kernel/smpboot.c | 1 +
arch/ia64/kernel/time.c | 1 +
arch/ia64/kernel/uncached.c | 4 +---
arch/ia64/mm/contig.c| 1 +
arch/ia64/mm/discontig.c | 1 +
arch/ia64/mm/init.c | 1 +
include/linux/efi.h | 6 --
11 files changed, 22 insertions(+), 9 deletions(-)
create mode 100644 arch/ia64/include/asm/efi.h
diff --git a/arch/ia64/include/asm/efi.h b/arch/ia64/include/asm/efi.h
new file mode 100644
index 000..6a4a50d
--- /dev/null
+++ b/arch/ia64/include/asm/efi.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_EFI_H
+#define _ASM_EFI_H
+
+typedef int (*efi_freemem_callback_t) (u64 start, u64 end, void *arg);
+
+void *efi_get_pal_addr(void);
+void efi_map_pal_code(void);
+void efi_memmap_walk(efi_freemem_callback_t, void *);
+void efi_memmap_walk_uc(efi_freemem_callback_t, void *);
+void efi_gettimeofday(struct timespec64 *ts);
+
+#endif
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index f932b25..dd7fd75 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index efc9b56..af310dc 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 2703f77..0fea266 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -91,6 +91,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index 093040f..49b4885 100644
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index ed9fc3d..a37f161 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/kernel/uncached.c b/arch/ia64/kernel/uncached.c
index 0750f36..51883a6 100644
--- a/arch/ia64/kernel/uncached.c
+++ b/arch/ia64/kernel/uncached.c
@@ -20,14 +20,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-
-extern void __init efi_memmap_walk_uc(efi_freemem_callback_t, void *);
-
struct uncached_pool {
struct gen_pool *pool;
struct mutex add_chunk_mutex; /* serialize adding a converted chunk */
diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index bfc4ecd..62fe80a 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index c731113..03b3a02 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 9b5acf8..24583a3 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 763b816..0c31af3 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -167,8 +167,6 @@ struct capsule_info {
int __efi_capsule_setup_info(struct capsule_info *cap_info);
-typedef int (*efi_freemem_callback_t) (u64 start, u64 end, void *arg);
-
/*
* Types and defines for Time Services
*/
@@ -605,10 +603,6 @@ efi_guid_to_str(efi_guid_t *guid, char *out)
}
extern void efi_init (void);
-extern void *efi_get_pal_addr (void);
-extern void efi_map_pal_code (void);
-extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
-extern void efi_gettimeofday (struct timespec64 *ts);
#ifdef CONFIG_EFI
extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode,
if possible */
#else
[tip: efi/core] efi/libstub: whitespace cleanup
The following commit has been merged into the efi/core branch of tip: Commit-ID: 2f196059864fb0fe8f60c14a2cb214055b283e08 Gitweb: https://git.kernel.org/tip/2f196059864fb0fe8f60c14a2cb214055b283e08 Author:Ard Biesheuvel AuthorDate:Mon, 02 Nov 2020 17:11:49 +01:00 Committer: Ard Biesheuvel CommitterDate: Tue, 19 Jan 2021 17:57:15 +01:00 efi/libstub: whitespace cleanup Trivial whitespace cleanup. Signed-off-by: Ard Biesheuvel --- include/linux/efi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/efi.h b/include/linux/efi.h index 0c31af3..2537a24 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -29,10 +29,10 @@ #include #define EFI_SUCCESS0 -#define EFI_LOAD_ERROR ( 1 | (1UL << (BITS_PER_LONG-1))) +#define EFI_LOAD_ERROR ( 1 | (1UL << (BITS_PER_LONG-1))) #define EFI_INVALID_PARAMETER ( 2 | (1UL << (BITS_PER_LONG-1))) #define EFI_UNSUPPORTED( 3 | (1UL << (BITS_PER_LONG-1))) -#define EFI_BAD_BUFFER_SIZE ( 4 | (1UL << (BITS_PER_LONG-1))) +#define EFI_BAD_BUFFER_SIZE( 4 | (1UL << (BITS_PER_LONG-1))) #define EFI_BUFFER_TOO_SMALL ( 5 | (1UL << (BITS_PER_LONG-1))) #define EFI_NOT_READY ( 6 | (1UL << (BITS_PER_LONG-1))) #define EFI_DEVICE_ERROR ( 7 | (1UL << (BITS_PER_LONG-1)))
[tip: efi/core] efi: x86: clean up previous struct mm switching
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Gitweb:
https://git.kernel.org/tip/514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:05:40 +01:00
Committer: Ard Biesheuvel
CommitterDate: Tue, 19 Jan 2021 17:57:15 +01:00
efi: x86: clean up previous struct mm switching
EFI on x86_64 keeps track of the process's MM pointer by storing it
in a global struct called 'efi_scratch', which also used to contain
the mixed mode stack pointer. Let's clean this up a little bit, by
getting rid of the struct, and pushing the mm handling into the
callees entirely.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/efi.h | 17 +
arch/x86/platform/efi/efi_64.c | 27 +++
2 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 5e37e6d..1328b79 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -95,20 +95,12 @@ extern asmlinkage u64 __efi_call(void *fp, ...);
__efi_call(__VA_ARGS__);\
})
-/*
- * struct efi_scratch - Scratch space used while switching to/from efi_mm
- * @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
- */
-struct efi_scratch {
- struct mm_struct*prev_mm;
-} __packed;
-
#define arch_efi_call_virt_setup() \
({ \
efi_sync_low_kernel_mappings(); \
kernel_fpu_begin(); \
firmware_restrict_branch_speculation_start(); \
- efi_switch_mm(_mm); \
+ efi_enter_mm(); \
})
#define arch_efi_call_virt(p, f, args...) \
@@ -116,7 +108,7 @@ struct efi_scratch {
#define arch_efi_call_virt_teardown() \
({ \
- efi_switch_mm(efi_scratch.prev_mm); \
+ efi_leave_mm(); \
firmware_restrict_branch_speculation_end(); \
kernel_fpu_end(); \
})
@@ -135,7 +127,6 @@ struct efi_scratch {
#endif /* CONFIG_X86_32 */
-extern struct efi_scratch efi_scratch;
extern int __init efi_memblock_x86_reserve_range(void);
extern void __init efi_print_memmap(void);
extern void __init efi_map_region(efi_memory_desc_t *md);
@@ -148,10 +139,12 @@ extern void __init efi_dump_pagetable(void);
extern void __init efi_apply_memmap_quirks(void);
extern int __init efi_reuse_config(u64 tables, int nr_tables);
extern void efi_delete_dummy_variable(void);
-extern void efi_switch_mm(struct mm_struct *mm);
extern void efi_recover_from_page_fault(unsigned long phys_addr);
extern void efi_free_boot_services(void);
+void efi_enter_mm(void);
+void efi_leave_mm(void);
+
/* kexec external ABI */
struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 1d90418..62a6c86 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -54,10 +54,7 @@
* 0x___ and limit EFI VA mapping space to 64G.
*/
static u64 efi_va = EFI_VA_START;
-
-struct efi_scratch efi_scratch;
-
-EXPORT_SYMBOL_GPL(efi_mm);
+static struct mm_struct *efi_prev_mm;
/*
* We need our own copy of the higher levels of the page tables
@@ -481,11 +478,17 @@ void __init efi_dump_pagetable(void)
* can not change under us.
* It should be ensured that there are no concurent calls to this function.
*/
-void efi_switch_mm(struct mm_struct *mm)
+void efi_enter_mm(void)
+{
+ efi_prev_mm = current->active_mm;
+ current->active_mm = _mm;
+ switch_mm(efi_prev_mm, _mm, NULL);
+}
+
+void efi_leave_mm(void)
{
- efi_scratch.prev_mm = current->active_mm;
- current->active_mm = mm;
- switch_mm(efi_scratch.prev_mm, mm, NULL);
+ current->active_mm = efi_prev_mm;
+ switch_mm(_mm, efi_prev_mm, NULL);
}
static DEFINE_SPINLOCK(efi_runtime_lock);
@@ -549,12 +552,12 @@ efi_thunk_set_virtual_address_map(unsigned long
memory_map_size,
efi_sync_low_kernel_mappings();
local_irq_save(flags);
- efi_switch_mm(_mm);
+ efi_enter_mm();
status = __efi_thunk(set_virtual_address_map, memory_map_size,
descriptor_size, descriptor_version, virtual_map);
- efi_switch_mm(efi_scratch.prev_mm);
+ efi_leave_mm();
local_irq_restore(flags);
return status;
@
Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the kaslr implementation, let's reimplement
> >> the matching of the "nokaslr" option with it.
> >>
> >> Signed-off-by: Marc Zyngier
> >> Acked-by: Catalin Marinas
> >> Acked-by: David Brazdil
> >> ---
> >> arch/arm64/kernel/idreg-override.c | 15 +
> >> arch/arm64/kernel/kaslr.c | 36
> >> ++
> >> 2 files changed, 17 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/idreg-override.c
> >> b/arch/arm64/kernel/idreg-override.c
> >> index cbb8eaa48742..3ccf51b84ba4 100644
> >> --- a/arch/arm64/kernel/idreg-override.c
> >> +++ b/arch/arm64/kernel/idreg-override.c
> >> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
> >> {
> >> },
> >> };
> >>
> >> +extern struct arm64_ftr_override kaslr_feature_override;
> >> +
> >> +static const struct ftr_set_desc kaslr __initdata = {
> >
> > This should be __initconst not __initdata (below too)
> >
> >> + .name = "kaslr",
> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> + .override = _feature_override,
> >> +#endif
> >> + .fields = {
> >> + { "disabled", 0 },
> >> + {}
> >> + },
> >> +};
> >> +
> >> static const struct ftr_set_desc * const regs[] __initdata = {
> >> ,
> >> + ,
> >> };
> >>
> >> static const struct {
> >> @@ -41,6 +55,7 @@ static const struct {
> >> } aliases[] __initdata = {
> >> { "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
> >> { "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
> >> + { "nokaslr","kaslr.disabled=1" },
> >> };
> >>
> >
> > This struct now takes up
> > - ~100 bytes for the characters themselves (which btw are not emitted
> > into __initdata or __initconst)
> > - 6x8 bytes for the char pointers
> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> > quantities that need to be relocated at boot (on a kernel built with
> > KASLR)
> >
> > I know it's only a drop in the ocean, but in this case, where the
> > struct is statically declared and defined only once, and in the same
> > place, we could easily turn this into
> >
> > static const struct {
> >char alias[24];
> >char param[20];
> > };
> >
> > and get rid of all the overhead. The only slightly annoying thing is
> > that the array sizes need to be kept in sync with the largest instance
> > appearing in the array, but this is easy when the struct type is
> > declared in the same place where its only instance is defined.
>
> Fair enough. I personally find the result butt-ugly, but I agree
> that it certainly saves some memory. Does the following work for
> you? I can even give symbolic names to the various constants (how
> generous of me! ;-).
>
To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'charfeature[80];' really need 80 bytes
though?
> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index d1310438d95c..9e7043bdc808 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -14,15 +14,15 @@
> #include
>
> struct ftr_set_desc {
> - const char *name;
> + charname[20];
> struct arm64_ftr_override *override;
> struct {
> - const char *name;
> + charname[20];
> u8 shift;
> } fields[];
> };
>
> -static const struct ftr_set_desc mmfr1 __initdata = {
> +static const struct ftr_set_desc mmfr1 __initconst = {
> .name = "id_aa64mmfr1",
> .override = _aa64mmfr1_override,
> .fields = {
> @@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
> },
> };
>
&g
Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
>
> Given that the early cpufeature infrastructure has borrowed quite
> a lot of code from the kaslr implementation, let's reimplement
> the matching of the "nokaslr" option with it.
>
> Signed-off-by: Marc Zyngier
> Acked-by: Catalin Marinas
> Acked-by: David Brazdil
> ---
> arch/arm64/kernel/idreg-override.c | 15 +
> arch/arm64/kernel/kaslr.c | 36 ++
> 2 files changed, 17 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index cbb8eaa48742..3ccf51b84ba4 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata = {
> },
> };
>
> +extern struct arm64_ftr_override kaslr_feature_override;
> +
> +static const struct ftr_set_desc kaslr __initdata = {
This should be __initconst not __initdata (below too)
> + .name = "kaslr",
> +#ifdef CONFIG_RANDOMIZE_BASE
> + .override = _feature_override,
> +#endif
> + .fields = {
> + { "disabled", 0 },
> + {}
> + },
> +};
> +
> static const struct ftr_set_desc * const regs[] __initdata = {
> ,
> + ,
> };
>
> static const struct {
> @@ -41,6 +55,7 @@ static const struct {
> } aliases[] __initdata = {
> { "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
> { "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
> + { "nokaslr","kaslr.disabled=1" },
> };
>
This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted
into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as
quantities that need to be relocated at boot (on a kernel built with
KASLR)
I know it's only a drop in the ocean, but in this case, where the
struct is statically declared and defined only once, and in the same
place, we could easily turn this into
static const struct {
char alias[24];
char param[20];
};
and get rid of all the overhead. The only slightly annoying thing is
that the array sizes need to be kept in sync with the largest instance
appearing in the array, but this is easy when the struct type is
declared in the same place where its only instance is defined.
> static char *cmdline_contains_option(const char *cmdline, const char *option)
> diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
> index 5fc86e7d01a1..27f8939deb1b 100644
> --- a/arch/arm64/kernel/kaslr.c
> +++ b/arch/arm64/kernel/kaslr.c
> @@ -51,39 +51,7 @@ static __init u64 get_kaslr_seed(void *fdt)
> return ret;
> }
>
> -static __init bool cmdline_contains_nokaslr(const u8 *cmdline)
> -{
> - const u8 *str;
> -
> - str = strstr(cmdline, "nokaslr");
> - return str == cmdline || (str > cmdline && *(str - 1) == ' ');
> -}
> -
> -static __init bool is_kaslr_disabled_cmdline(void *fdt)
> -{
> - if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> - int node;
> - const u8 *prop;
> -
> - node = fdt_path_offset(fdt, "/chosen");
> - if (node < 0)
> - goto out;
> -
> - prop = fdt_getprop(fdt, node, "bootargs", NULL);
> - if (!prop)
> - goto out;
> -
> - if (cmdline_contains_nokaslr(prop))
> - return true;
> -
> - if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> - goto out;
> -
> - return false;
> - }
> -out:
> - return cmdline_contains_nokaslr(CONFIG_CMDLINE);
> -}
> +struct arm64_ftr_override kaslr_feature_override __initdata;
>
> /*
> * This routine will be executed with the kernel mapped at its default
> virtual
> @@ -126,7 +94,7 @@ u64 __init kaslr_early_init(void)
> * Check if 'nokaslr' appears on the command line, and
> * return 0 if that is the case.
> */
> - if (is_kaslr_disabled_cmdline(fdt)) {
> + if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
> kaslr_status = KASLR_DISABLED_CMDLINE;
> return 0;
> }
> --
> 2.29.2
>
Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
On Mon, 25 Jan 2021 at 15:28, Marc Zyngier wrote:
>
> On 2021-01-25 14:19, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
> >>
> >> On 2021-01-25 12:54, Ard Biesheuvel wrote:
>
> [...]
>
> >> > This struct now takes up
> >> > - ~100 bytes for the characters themselves (which btw are not emitted
> >> > into __initdata or __initconst)
> >> > - 6x8 bytes for the char pointers
> >> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> >> > quantities that need to be relocated at boot (on a kernel built with
> >> > KASLR)
> >> >
> >> > I know it's only a drop in the ocean, but in this case, where the
> >> > struct is statically declared and defined only once, and in the same
> >> > place, we could easily turn this into
> >> >
> >> > static const struct {
> >> >char alias[24];
> >> >char param[20];
> >> > };
> >> >
> >> > and get rid of all the overhead. The only slightly annoying thing is
> >> > that the array sizes need to be kept in sync with the largest instance
> >> > appearing in the array, but this is easy when the struct type is
> >> > declared in the same place where its only instance is defined.
> >>
> >> Fair enough. I personally find the result butt-ugly, but I agree
> >> that it certainly saves some memory. Does the following work for
> >> you? I can even give symbolic names to the various constants (how
> >> generous of me! ;-).
> >>
> >
> > To be honest, I was anticipating more of a discussion, but this looks
> > reasonable to me.
>
> It looked like a reasonable ask: all the strings are completely useless
> once the kernel has booted, and I'm the first to moan that I can't boot
> an arm64 kernel with less than 60MB of RAM (OK, it's a pretty bloated
> kernel...).
>
> > Does 'charfeature[80];' really need 80 bytes though?
>
> It really needs 75 bytes, because of this:
>
> { "arm64.nopauth",
> "id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
> "id_aa64isar1.api=0 id_aa64isar1.apa=0" },
>
> 80 is a round enough number.
>
Fair enough. This will inflate the struct substantially, but at least
it's all __initconst data now, and it's all NUL bytes so it compresses
much better than the pointers and RELA entries.
