linux-kernel - Re: 答复: [PATCH] arm64/ptrace: add PTRACE_SYSEMU and PTRACE_SYSEMU

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]

Date:   Tue, 04 Sep 2018 21:45:06 +0200
From:   Richard Weinberger <richard@....at>
To:     "Haibo Xu (Arm Technology China)" <Haibo.Xu@....com>
Cc:     Will Deacon <Will.Deacon@....com>,
        Catalin Marinas <Catalin.Marinas@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        nd <nd@....com>, "jdike@...toit.com" <jdike@...toit.com>
Subject: Re: 答复: [PATCH] arm64/ptrace: add PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support

Am Dienstag, 4. September 2018, 04:11:07 CEST schrieb Haibo Xu (Arm Technology China):
> Hi Richard,
> 
> What do you mean by done it in the core? moving macro definition to include/uapi/linux/ptrace.h?
> The patch is strictly follow x86's sematic on PTRACE_SYSEMU/SINGLESTEP support.

Well, the feature itself is not really architecture specific.
Just because x86 does it in arch/x86, it does not mean that this is the best way.
I guess this is also what Will tried to say.
If we can, we should implement PTRACE_SYSEMU in the core ptrace code and not
per architecture.

> > > I wonder what Haibo Xu want to do with PTRACE_SYSEMU on arm64.
> > > Are you porting UML or gvisor to arm64?
> >
> > That's a good question. Haibo?
> 
> The story is we are working on a container runtime(Google Gvisor) support on ARM64 platform,
> and the Gvisor depend on Linux kernel PTRACE_SYSEMU/SINGLESTEP support.

Gvisor also supports a kvm backend which should be *much* faster than PTRACE_SYSEMU.
Otherwise gvisor suffers from the same performance drawbacks as UML does.
Pagefaults via SIGSEGV/mmap, syscall gate via ptrace().

Did you check, is PTRACE_SYSEMU really the way to go for gvisor?
Last time I checked the KVM backend looked promising but still WIP, though.

I also wonder whether PTRACE_SYSEMU is really the only missing bit to support
gvisor on arm64. Did you check how to work around VIPT/VIVT caching issues?
UML (and gvisor in this context) have lots of implicit x86 dependencies.

Thanks,
//richard