linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] ARM: change link order of $(mmy-y) to avoid veneers
Date: Tue, 20 Jun 2023 15:13:06 -0400	[thread overview]
Message-ID: <CAKwvOdkX993kCaGVj5jd9-xeUwU5w9XmP4gUoSjOndfG-DhWHg@mail.gmail.com> (raw)
In-Reply-To: <20230619143725.57967-1-masahiroy@kernel.org>

On Mon, Jun 19, 2023 at 10:37 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> The kernel compiled with multi_v7_defconfig + CONFIG_KASAN=y +
> CONFIG_KASAN_INLINE=y does not boot.
>
> I do not think KASAN is the direct reason of the boot failure.
> CONFIG_KASAN_INLINE is just one example configuration that grows the
> image size significantly and makes a big distance between function
> callers and callees.
>
> I see some veneers for __get_user_* in the bad kernel image. I am
> not perfectly clear, but __get_user_* may not work with veneers for
> some reasons.

I'm kind of curious to know more about this.  Has there been other
instances in the ARCH=arm port where "there must not be a veneer from
X to Y for reason Z?"

I thought the linker inserted veneers were meant to be transparent
here.  If you disassemble ____get_user_1_veneer, do they themselves
branch to different symbols, or the same symbol? (Perhaps they
trampoline to each other then the final one is the "call" to the
original symbol).  But perhaps the symbol at the end of the chain
gives us more clues. I'd bet it's the KASAN callback, though does
KASAN_INLINE inline those?  Perhaps the veneer is corrupting a
register?  Maybe inline asm in the caller is missing a clobber for
that register...

>
> If I move the link order of arch/arm/lib/getuser.S, the veneers are
> gone, and the kernel gets working again.
>
> I do not see a good reason that $(mmu-y) must be added to lib-y because
> all the code in $(mmu-y) is mandatory. Add it to obj-y to move the code
> to lower address.
>
> [1] multi_v7_defconfig (works)
>
>  $ arm-linux-gnueabihf-nm vmlinux | grep __get_user_1
>  c072a450 T __get_user_1
>  c17ea033 r __kstrtab___get_user_1
>  c18119fe r __kstrtabns___get_user_1
>  c17c4878 r __ksymtab___get_user_1
>
> [2] multi_v7_defconfig + CONFIG_KASAN_INLINE (does not work)
>
>  $ arm-linux-gnueabihf-nm vmlinux | grep __get_user_1
>  c341ec2c T __get_user_1
>  c06e3580 t ____get_user_1_veneer
>  c0adc6c0 t ____get_user_1_veneer
>  c12cf054 t ____get_user_1_veneer
>  c43f42cc r __kstrtab___get_user_1
>  c441c128 r __kstrtabns___get_user_1
>  c43cead8 r __ksymtab___get_user_1
>
> [3] multi_v7_defconfig + CONFIG_KASAN_INLINE + this patch (works)
>
>  $ arm-linux-gnueabihf-nm vmlinux | grep __get_user_1
>  c10975b0 T __get_user_1
>  c43f42cc r __kstrtab___get_user_1
>  c441c128 r __kstrtabns___get_user_1
>  c43cead8 r __ksymtab___get_user_1
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
>  arch/arm/lib/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 650404be6768..4d092ef87a1d 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -28,7 +28,7 @@ endif
>  # using lib_ here won't override already available weak symbols
>  obj-$(CONFIG_UACCESS_WITH_MEMCPY) += uaccess_with_memcpy.o
>
> -lib-$(CONFIG_MMU) += $(mmu-y)
> +obj-$(CONFIG_MMU) += $(mmu-y)
>
>  ifeq ($(CONFIG_CPU_32v3),y)
>    lib-y        += io-readsw-armv3.o io-writesw-armv3.o
> --
> 2.39.2
>


-- 
Thanks,
~Nick Desaulniers

      parent reply	other threads:[~2023-06-20 19:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 14:37 [PATCH] ARM: change link order of $(mmy-y) to avoid veneers Masahiro Yamada
2023-06-20  2:55 ` Masahiro Yamada
2023-06-20  4:14 ` Nicolas Schier
2023-06-20 19:13 ` Nick Desaulniers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKwvOdkX993kCaGVj5jd9-xeUwU5w9XmP4gUoSjOndfG-DhWHg@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=ardb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=masahiroy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).