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

On Thu, Jun 11, 2020 at 09:53:52PM +0200, Mikhail Morfikov wrote:
> On 11/06/2020 20:16, Adam Zabrocki wrote:
> > I meant "your compiler". You must have enabled optimization flag during 
> > compilation (-02? -03?). However, as I mentioned you can manually replace the 
> > name of lookup_fast to lookup_fast.constprop.0 and it will work fine. This 
> > function is ISRA safe and should CONSTPROP safe as well.
> > 
> Hmm, that's weird because I haven't changed anything in the kernel build 
> process, except moving from gcc9 to gcc10. 

Sure, however, from the logs below it looks like you've compiled Linux kernel 
using -O2 flag.

> Here's the log when the kernel is built with the gcc9:
> kernel: p_lkrg: loading out-of-tree module taints kernel.
> kernel: [p_lkrg] Loading LKRG...
> kernel: [p_lkrg] System does NOT support SMAP. LKRG can't enforce SMAP validation :(
> kernel: Freezing user space processes ... (elapsed 0.154 seconds) done.
> kernel: OOM killer disabled.
> kernel: [p_lkrg] 8/23 UMH paths were whitelisted...
> kernel: [p_lkrg] LKRG initialized successfully!
> kernel: OOM killer enabled.
> kernel: Restarting tasks ... done.
> As you can see, there's no problem because:
> # cat /proc/kallsyms|grep lookup_fast
> ffffffff864ee250 t lookup_fast
> ffffffff86fcbbc0 t nft_hash_lookup_fast
> ffffffffc04d53ee t p_pcfi_lookup_fast_entry.cold        [p_lkrg]
> ffffffffc04ed520 d p_pcfi_lookup_fast_kretprobe [p_lkrg]
> ffffffffc04cd130 t p_pcfi_lookup_fast_ret       [p_lkrg]
> ffffffffc04cd320 t p_install_pcfi_lookup_fast_hook      [p_lkrg]
> ffffffffc04cd140 t p_pcfi_lookup_fast_entry     [p_lkrg]
> ffffffffc04cd350 t p_uninstall_pcfi_lookup_fast_hook    [p_lkrg]
> ffffffffc04f4d74 b p_pcfi_lookup_fast_kretprobe_state   [p_lkrg]
> So it looks good.
> I checked what flags are used when building the kernel via 
> "make ARCH="x86_64" -j3 bindeb-pkg" , and I got:
> $ make ARCH="x86_64" -j3 bindeb-pkg
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/confdata.o
>   HOSTCC  scripts/kconfig/expr.o
>   HOSTCC  scripts/kconfig/lexer.lex.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf  --syncconfig Kconfig
> 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-7
> 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 [vendor]: -g -O2 -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 [vendor]: -g -O2 -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: FCFLAGS [vendor]: -g -O2 -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: FFLAGS [vendor]: -g -O2 -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong
> dpkg-buildflags: status: GCJFLAGS [vendor]: -g -O2 -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 [vendor]: -g -O2 -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> dpkg-buildflags: status: OBJCXXFLAGS [vendor]: -g -O2 -fdebug-prefix-map=/media/debian_sources/git-kernel/linux-5.7=. -fstack-protector-strong -Wformat -Werror=format-security
> ...
> The same sets of flags is used when I switch to gcc10, and yet in the case of 
> gcc10 LKRG has problem with lookup_fast function.

LKRG itself doesn't change how the kernel symbols are build.

> So I assume that when the gcc10 will be default in Debian, LKRG will have this 
> issue I experience now.

It will be depended on the kernel config. Debian package kernels won't have 
that issue. If you manually compile your kernel from the sources using -O2 
optimization and your configuration allows for such optimization then yes.

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.