[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191226164503.GA29258@pi3.com.pl>
Date: Thu, 26 Dec 2019 17:45:03 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: LIST HASH IS DIFFERENT - nf_nat / nf_conntrack
Linux version 5.3.0-0
Hi,
I've set-up a template-VM with a debian buster using the following kernel:
Linux debian-10 5.3.0-0.bpo.2-amd64 #1 SMP Debian 5.3.9-2~bpo10+1 (2019-11-13)
x86_64 GNU/Linux
(same as yours). However, I don't see any problems there using LKRG from the
bitbucket repo:
[Thu Dec 26 10:53:36 2019] [p_lkrg] Loading LKRG...
[Thu Dec 26 10:53:36 2019] Freezing user space processes ... (elapsed 0.001
seconds) done.
[Thu Dec 26 10:53:36 2019] OOM killer disabled.
[Thu Dec 26 10:53:36 2019] [p_lkrg] LKRG initialized successfully!
[Thu Dec 26 10:53:36 2019] OOM killer enabled.
[Thu Dec 26 10:53:36 2019] Restarting tasks ... done.
[Thu Dec 26 10:53:46 2019] [p_lkrg] Enabling "clean" message.
[Thu Dec 26 10:53:51 2019] [p_lkrg] System is clean!
[Thu Dec 26 10:54:04 2019] [p_lkrg] Disabling "clean" message.
...
[Thu Dec 26 11:09:51 2019] [p_lkrg] New log level => 3 (WARN)
[Thu Dec 26 11:31:51 2019] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel
core .text section hash!
[Thu Dec 26 11:31:51 2019] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel
core .text section hash!
[Thu Dec 26 11:31:51 2019] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel
core .text section hash!
[Thu Dec 26 11:31:51 2019] [p_lkrg] [JUMP_LABEL <batch mode>] Updating module's
core .text section hash!
[Thu Dec 26 11:31:51 2019] [p_lkrg] [JUMP_LABEL <batch mode>] Updating module's
core .text section hash!
...
[Thu Dec 26 11:42:06 2019] [p_lkrg] System is clean!
user@...ian-10:~$ cat /proc/kallsyms |grep p_arch_jump
0000000000000000 t p_arch_jump_label_transform_entry.cold.3 [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_ret.cold.4 [p_lkrg]
0000000000000000 d p_arch_jump_label_transform_kretprobe [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_apply_entry.cold.3 [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_apply_ret.cold.4 [p_lkrg]
0000000000000000 d p_arch_jump_label_transform_apply_kretprobe [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_ret [p_lkrg]
0000000000000000 b p_arch_jump_label_transform_kretprobe_state [p_lkrg]
0000000000000000 b p_arch_jump_label_transform_apply_kretprobe_state
[p_lkrg]
0000000000000000 t p_arch_jump_label_transform_apply_ret [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_entry [p_lkrg]
0000000000000000 t p_arch_jump_label_transform_apply_entry [p_lkrg]
user@...ian-10:~$
Can you confirm that you are using LKRG from the bitbucket repo?
The easiest way to be able to test JUMP_LABEL is to enable / disable global
kernel tracing, e.g.:
# echo 1 > /sys/kernel/debug/tracing/events/enable
# echo 0 > /sys/kernel/debug/tracing/events/enable
Thanks,
Adam
On Thu, Dec 26, 2019 at 07:28:15AM +0000, Patrick Schleizer wrote:
> Adam Zabrocki:
> > Can you share with me a VM with that specific kernel which I can use for local
> > repro?
>
>
> You mean to share a binary VM build? That is an interesting idea.
>
> If it was a VirtualBox VM, I could export the VM and upload it
> elsewhere. Then you could easily download it and re-import to reproduce
> (hopefully [1]) the very same issue. Usually I don't offer that because
> I thought most would refuse it (download size, time, security) but
> sometimes that could be a good way to debug things.
>
> For Qubes I don't know from the top of my head how to export/share a VM
> and then how someone else could re-import that. Might be possible but
> someone might have to research and document that. Even if I managed to
> share the template image, we might not be using the same dom0 VM
> settings (but these could be easy enough to reproduce manually).
> Therefore instead I try to produce better instructions for reproduction
> of this issue.
>
> > I'm going to have limited access to the internet until 14th of Jan ;/
>
>
> No worries. Keep your time.
>
> > However, I've sucrificed one physical machine to install qubeos but it has
> > fedora not debian in dom0.
>
> Correcting in my original report.
>
> "Qubes, Debian buster"
>
> There's no Qubes with Debian in dom0 yet. If there was or if I
> accomplished that, that would be big news and I should explicit explain
> that. More specifically:
>
> "Qubes, in a Debian buster (debian-10) based TemplateVM"
>
> To reproduce, first, you'd need to re-configure the VM to use VM kernel
> rather than Qubes dom0 kernel as per these instructions (which were
> recently simplified by me):
>
> https://www.qubes-os.org/doc/managing-vm-kernel/#installing-kernel-in-debian-vm
>
> in summary:
>
> in TemplateVM:
> sudo mkdir -p /boot/grub
>
> in TemplateVM:
> sudo apt install --no-install-recommends linux-image-amd64
> linux-headers-amd64 grub2-common qubes-kernel-vm-support initramfs-tools
> busybox
>
> in TemplateVM:
> sudo update-grub
>
> > The Kernel setting of the Virtualization mode setting:
>
> > If Virtualization is set to PVH -> Kernel -> choose pvgrub2-pvh -> OK
>
>
> (These instructions are even compatible with minimal Debian template. [2])
>
>
> Then you'd need to add
>
> deb tor+https://deb.debian.org/debian buster-backports main
>
> to sources.list ( /etc/apt/sources.list / /etc/apt/sources.list.d )
>
> And install the newer kernel from backports.
>
> sudo apt update
>
> sudo apt-get -t buster-backports install linux-image-amd64
> linux-headers-amd64
>
>
> > Can you check the output of the following command?
> >
> > # cat /proc/kallsyms |grep p_arch_jump_label_transform
>
>
> No output. But small chance this will help:
>
> sudo cat /proc/kallsyms | grep p_arch
> ffffffffa6fe9e60 T swsusp_arch_resume
> ffffffffa6feb000 T swsusp_arch_suspend
> ffffffffa7e84b6a T setup_arch
> ffffffffa7fc4370 t __setup_arch_parse_efi_cmdline
>
> > Additionally, do you see the same problem just on QubeOS or normal debian
> > installation faces the same issue?
>
>
> Qubes (usual fedora dom0) with Debian TemplateVM: described above.
>
> (Non-Qubes, plain) Debian: not yet tested. I'll report once tested.
>
> Kind regards,
> Patrick
>
> [1] Might not reproduce due to different host system configuration, host
> system CPU and whatnot.
> [2] https://github.com/QubesOS/qubes-doc/pull/905
--
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.
