lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAT5gyn0C9EJhh1EeFT7gF0rOudWcdqAVN=+C4jR42W90w@mail.gmail.com>
Date: Sat, 23 Dec 2023 13:10:18 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Helge Deller <deller@....de>
Cc: deller@...nel.org, linux-kernel@...r.kernel.org, 
	Arnd Bergmann <arnd@...db.de>, linux-modules@...r.kernel.org, linux-arch@...r.kernel.org, 
	Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*,
 __kcrctab_* and .pci_fixup sections

On Fri, Dec 22, 2023 at 6:02 PM Helge Deller <deller@....de> wrote:
>
> On 12/21/23 14:07, Masahiro Yamada wrote:
> > On Thu, Nov 23, 2023 at 7:18 AM <deller@...nel.org> wrote:
> >>
> >> From: Helge Deller <deller@....de>
> >>
> >> On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> >> (e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores
> >> 64-bit pointers into the __ksymtab* sections.
> >> Make sure that the start of those sections is 64-bit aligned in the vmlinux
> >> executable, otherwise unaligned memory accesses may happen at runtime.
> >
> >
> > Are you solving a real problem?
>
> Not any longer.
> I faced a problem on parisc when neither #1 and #3 were applied
> because of a buggy unalignment exception handler. But this is
> not something which I would count a "real generic problem".
>
> > 1/4 already ensures the proper alignment of __ksymtab*, doesn't it?
>
> Yes, it does.
>
> >...
> > So, my understanding is this patch is unneeded.
>
> Yes, it's not required and I'm fine if we drop it.
>
> But regarding __kcrctab:
>
> >> @@ -498,6 +501,7 @@
> >>          }                                                               \
> >>                                                                          \
> >>          /* Kernel symbol table: Normal symbols */                       \
> >> +       . = ALIGN(4);                                                   \
> >>          __kcrctab         : AT(ADDR(__kcrctab) - LOAD_OFFSET) {         \
> >>                  __start___kcrctab = .;                                  \
> >>                  KEEP(*(SORT(___kcrctab+*)))                             \
>
> I think this patch would be beneficial to get proper alignment:
>
> diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> index cd253eb51d6c..d445705ac13c 100644
> --- a/include/linux/export-internal.h
> +++ b/include/linux/export-internal.h
> @@ -64,6 +64,7 @@
>
>   #define SYMBOL_CRC(sym, crc, sec)   \
>          asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> +           ".balign 4"                                         "\n" \
>              "__crc_" #sym ":"                                   "\n" \
>              ".long " #crc                                       "\n" \
>              ".previous"                                         "\n")


Yes!


Please send a patch with this:


Fixes: f3304ecd7f06 ("linux/export: use inline assembler to populate
symbol CRCs")



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ