Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Jun 2020 00:19:25 +0200
From: Adam Zabrocki <>
Subject: Re: RE: ISRA optimized functions


On Thu, Jun 11, 2020 at 11:33:45PM +0200, Mikhail Morfikov wrote:
> On 11/06/2020 23:14, Mikhail Morfikov wrote:
> > On 11/06/2020 22:34, Adam Zabrocki wrote:
> >>
> >> Sure, however, from the logs below it looks like you've compiled Linux kernel 
> >> using -O2 flag.
> >>
> > 
> > Yes, but in both cases this flag was used, and in the case of gcc9 it looks like 
> > it doesn't matter (because LKRG works well), and in the case of gcc10 it does 
> > (since it has the problem with the function). So the question here is why? All I 
> > did was using update-alternatives to configure the gcc/g++/cpp links, and nothing 
> > else have changed in my system. So why does it work with the kernel built with 
> > gcc9 and it doesn't work with kernel built with gcc10?
> > 

This is question for GCC developers not for LKRG.

> I just checked, and the flags aren't used in the kernel build process:
> $ make ARCH="x86_64" -j3 bindeb-pkg
> sh ./scripts/package/mkdebian
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch)  -b -nc -uc
> dpkg-buildpackage: info: source package linux-5.7.2-amd64
> dpkg-buildpackage: info: source version 5.7.2-amd64-8
> dpkg-buildpackage: info: source distribution sid
> dpkg-buildpackage: info: source changed by Mikhail Morfikov <>
> dpkg-buildpackage: info: host architecture amd64
>  dpkg-source --before-build .
>  debian/rules build
> dpkg-buildflags --status
> dpkg-buildflags: status: environment variable DEB_BUILD_OPTIONS=parallel=4
> dpkg-buildflags: status: environment variable DEB_HOST_ARCH=amd64
> dpkg-buildflags: status: vendor is Debian
> dpkg-buildflags: status: future features: lfs=no
> dpkg-buildflags: status: hardening features: bindnow=no format=yes fortify=yes pie=yes relro=yes stackprotector=yes stackprotectorstrong=yes
> dpkg-buildflags: status: qa features: bug=no canary=no
> dpkg-buildflags: status: reproducible features: fixdebugpath=yes fixfilepath=no timeless=yes
> dpkg-buildflags: status: sanitize features: address=no leak=no thread=no undefined=no
> dpkg-buildflags: status: CFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: CPPFLAGS [vendor]: -Wdate-time -D_FORTIFY_SOURCE=2
> dpkg-buildflags: status: CXXFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: FCFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: FFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: GCJFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: LDFLAGS [vendor]: -Wl,-z,relro
> dpkg-buildflags: status: OBJCFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: OBJCXXFLAGS [user]: -g -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> make KERNELRELEASE=5.7.2-amd64 ARCH=x86_64      KBUILD_BUILD_VERSION=8 -f ./Makefile
>   DESCEND  objtool
>   CALL    scripts/atomic/
>   CALL    scripts/
>   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
>   CC      init/version.o
>   AR      init/built-in.a
>   GEN     .version
>   CHK     include/generated/compile.h
>   LD      vmlinux.o
>   MODPOST vmlinux.o
>   MODINFO modules.builtin.modinfo
>   GEN     modules.builtin
>   LD      .tmp_vmlinux.kallsyms1
>   KSYM    .tmp_vmlinux.kallsyms1.o
>   LD      .tmp_vmlinux.kallsyms2
>   KSYM    .tmp_vmlinux.kallsyms2.o
>   LD      vmlinux
>   SORTTAB vmlinux
>   MODPOST 0 modules
>   CC      arch/x86/boot/version.o
>   VOFFSET arch/x86/boot/compressed/../voffset.h
>   OBJCOPY arch/x86/boot/compressed/vmlinux.bin
>   RELOCS  arch/x86/boot/compressed/vmlinux.relocs
>   CC      arch/x86/boot/compressed/kaslr.o
>   XZKERN  arch/x86/boot/compressed/vmlinux.bin.xz
>   CC      arch/x86/boot/compressed/misc.o
>   MKPIGGY arch/x86/boot/compressed/piggy.S
>   AS      arch/x86/boot/compressed/piggy.o
>   LD      arch/x86/boot/compressed/vmlinux
>   ZOFFSET arch/x86/boot/zoffset.h
>   OBJCOPY arch/x86/boot/vmlinux.bin
>   AS      arch/x86/boot/header.o
>   LD      arch/x86/boot/setup.elf
>   OBJCOPY arch/x86/boot/setup.bin
>   BUILD   arch/x86/boot/bzImage
> Setup is 14396 bytes (padded to 14848 bytes).
> System is 10336 kB
> CRC 514b895b
> Kernel: arch/x86/boot/bzImage is ready  (#9)
>  fakeroot -u debian/rules binary
> make KERNELRELEASE=5.7.2-amd64 ARCH=x86_64      KBUILD_BUILD_VERSION=8 -f ./Makefile intdeb-pkg
> sh ./scripts/package/builddeb
>   DEPMOD  5.7.2-amd64
> dpkg-deb: building package 'linux-headers-5.7.2-amd64' in '../linux-headers-5.7.2-amd64_5.7.2-amd64-8_amd64.deb'.
>   INSTALL debian/linux-libc-dev/usr/include
> dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.7.2-amd64-8_amd64.deb'.
> dpkg-deb: building package 'linux-image-5.7.2-amd64' in '../linux-image-5.7.2-amd64_5.7.2-amd64-8_amd64.deb'.
>  dpkg-genbuildinfo --build=binary
>  dpkg-genchanges --build=binary >../linux-5.7.2-amd64_5.7.2-amd64-8_amd64.changes
> dpkg-genchanges: info: binary-only upload (no source code included)
>  dpkg-source --after-build .
> dpkg-buildpackage: info: binary-only upload (no source included)
> Here I stripped the -02 (via ~/.config/dpkg/buildflags.conf) and as you can see 
> the kernel wasn't recompiled, so the flags weren't taken into consideration, 
> and probably it uses the default set of flags which all debian systems use. So 
> still what could be wrong with the gcc10 compared to gcc9?

I would need to do manual investigation how your build process looks and works. 
However, I don't think it makes any sense.

You can read more about CONSTPROP here:

And people are having issues with that:

It is normal that such optimizations are applied, e.g.:

$ uname -r
$ cat /proc/kallsyms |grep constprop|wc -l

$ uname -r
$ cat /proc/kallsyms |grep constprop|wc -l

However, which function would be affected by such optimization purely 
depends on the kernel configuration.

I need to discuss and research more in details if adding such non-standard 
kernel configuration / compilation support makes sense from LKRG perspective.

Nevertheless, current LKRG is going to work fine in your system with all 


pi3 (pi3ki31ny) - pi3 (at) itsec pl

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.