linux-kernel - Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support

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: <877fcn46pn.fsf@linaro.org>
Date:	Fri, 15 Jul 2016 09:59:48 +0100
From:	Alex Bennée <alex.bennee@...aro.org>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	William Cohen <wcohen@...hat.com>,
	David Long <dave.long@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Petr Mladek <pmladek@...e.com>,
	Zi Shen Lim <zlim.lnx@...il.com>,
	Will Deacon <will.deacon@....com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	yalin wang <yalin.wang2010@...il.com>,
	Li Bin <huawei.libin@...wei.com>,
	John Blackwood <john.blackwood@...r.com>,
	Pratyush Anand <panand@...hat.com>,
	Daniel Thompson <daniel.thompson@...aro.org>,
	Huang Shijie <shijie.huang@....com>,
	Dave P Martin <Dave.Martin@....com>,
	Jisheng Zhang <jszhang@...vell.com>,
	Vladimir Murzin <Vladimir.Murzin@....com>,
	Steve Capper <steve.capper@...aro.org>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Yang Shi <yang.shi@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
	Adam Buchbinder <adam.buchbinder@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	linux-kernel@...r.kernel.org, James Morse <james.morse@....com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robin Murphy <robin.murphy@....com>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support


Marc Zyngier <marc.zyngier@....com> writes:

> On 15/07/16 08:50, Catalin Marinas wrote:
>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>> David A. Long (3):
>>>>>   arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>>   arm64: Add more test functions to insn.c
>>>>>   arm64: add conditional instruction simulation support
>>>>>
>>>>> Pratyush Anand (2):
>>>>>   arm64: Blacklist non-kprobe-able symbol
>>>>>   arm64: Treat all entry code as non-kprobe-able
>>>>>
>>>>> Sandeepa Prabhu (4):
>>>>>   arm64: Kprobes with single stepping support
>>>>>   arm64: kprobes instruction simulation support
>>>>>   arm64: Add kernel return probes support (kretprobes)
>>>>>   kprobes: Add arm64 case in kprobe example module
>>>>>
>>>>> William Cohen (1):
>>>>>   arm64: Add trampoline code for kretprobes
>>>>
>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>> exception at EL1".
>>>>
>>>> Did you manage to run Kprobes in a guest before?
>>>
>>> I ran the systemtap testsuite several times on a physical machine
>>> running a kernel with the kprobe v15 patches without problem.
>>> Shouldn't the guest machine behave in the same manner as a host
>>> machine for single stepping and exception handling?  If the guest
>>> machine is failing, wouldn't that suggest there is a problem with the
>>> KVM handling of single stepping for guests?
>>
>> It didn't fail for me on the host either. What's strange is that on some
>> occasions even the guest managed to get to a prompt. I'll do more tests
>> today on different CPU configurations, just to rule out potential
>> hardware issues. If not hardware related, it's possible that the
>> interaction with KVM doesn't work as expected, maybe the
>> saving/restoring of the guest debug state loses information.
>
> Could well be the latter. I'll try to have a look, but Alex Bennée (on
> cc) is our man when it comes to the KVM debug infrastructure.
>
> Alex, any chance you could try this and shed some light on it?

Sure I'll have a look. There are problems with running gdb inside a
guest while trying to debug from outside associated with single-stepping
but none of this should get in the way if your not debugging the guest.

Let me get my system spun up and see if I can reproduce.

Shall I just apply this series on top of the current master?

--
Alex Bennée