[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200611203413.GA30060@pi3.com.pl>
Date: Thu, 11 Jun 2020 22:34:13 +0200
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
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 <mmorfikov@...il.com>
> 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
http://pi3.com.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.
