From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8507C31E51 for ; Tue, 18 Jun 2019 12:20:00 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6D8AA20665 for ; Tue, 18 Jun 2019 12:20:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XJqwkGGn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D8AA20665 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45SnG46q2RzDqcR for ; Tue, 18 Jun 2019 22:19:56 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::d41; helo=mail-io1-xd41.google.com; envelope-from=radu.rendec@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XJqwkGGn"; dkim-atps=neutral Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45SnB82FszzDqbs for ; Tue, 18 Jun 2019 22:16:31 +1000 (AEST) Received: by mail-io1-xd41.google.com with SMTP id s7so29121562iob.11 for ; Tue, 18 Jun 2019 05:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=VD5To6MnDfxC+IblUyr9QHqMXNKUG2Rn2i056Yk7q5s=; b=XJqwkGGnuh98wPP8O575KoOR08AD4YwDJfdgVkf5GQHAn42596DeD8l6JkgarBWXlf quPjO7rMH1TvR8RIybHhggvHPUWefEsvQVGGK2AIGbN7rrQWUEeC3eFhXr+t2vnD6Eao efxtkSBUphv7Hfcfky8x3A4WepJcST6qM4obvsd2RDn2QTZ4efRUsHL+zw1FeMWZzchz SWIOeWALK8viMOs/Fjs2cx+BmTJNMDpO68+x44XJ6oDeiP5alZr0opFOmWzWyh02hJYI QDOCCjg++9kcRXmt89Z5axe5+184XCuHbYA6T9++hoTP5Ts5H6hQamLF3KQbW5WVzsPb smRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=VD5To6MnDfxC+IblUyr9QHqMXNKUG2Rn2i056Yk7q5s=; b=azJR5xbGNwktYohppRur7xoIB/jVSAR/87zOU6aEjPdsFU0aYA7ESr8iE0iQ7BMVbt Hh7G83kn4rHxSmNfnEMcDdrRB0SVbubw78JS8v0+Cvwy5Vo3wx8s6pywVpBnwekijjIE ZsxE5fjbMtj1QmpKOxgJpeNvJ0CYaJ7909muGR+AzwuOfpHPeYm4kQFt6DPpLfp9nwH3 eTwJ0ErbHqOh31kQtcnrgc2qO44683Clfkqmcck9VJFDz1CWVam8fICbXZ98c7zNCN4v TCMo+blidtHpMowxkzZyC+IvrqfQkG1zTG2gpFmtI+J9pdk8ZH7BwWSnUs9fSpx715Cj jr9g== X-Gm-Message-State: APjAAAXSltWPUW4No+gV0BPX5k3WzcIowvFlVgHNwaRk7nyTyOU1aNBu P4JbJI+rDve7WT9pNdRTs10= X-Google-Smtp-Source: APXvYqx1QEId0NwxhHn8WNdY9TZNvtBLJd9m8kwLhJTBJro5Nz64ZXjl7D6Buin0rKikrcDmuGWptA== X-Received: by 2002:a5e:c70c:: with SMTP id f12mr5081684iop.293.1560860188081; Tue, 18 Jun 2019 05:16:28 -0700 (PDT) Received: from bat.mindbit.ro (CPE00fc8d79db03-CM00fc8d79db00.cpe.net.fido.ca. [72.140.67.131]) by smtp.gmail.com with ESMTPSA id o7sm12990844ioo.81.2019.06.18.05.16.27 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 18 Jun 2019 05:16:27 -0700 (PDT) Message-ID: Subject: Re: [PATCH 0/1] PPC32: fix ptrace() access to FPU registers From: Radu Rendec To: Daniel Axtens , linuxppc-dev@lists.ozlabs.org Date: Tue, 18 Jun 2019 08:16:25 -0400 In-Reply-To: <87muif2y4l.fsf@dja-thinkpad.axtens.net> References: <20190610232758.19010-1-radu.rendec@gmail.com> <87r27t2el0.fsf@dja-thinkpad.axtens.net> <5fcdb5767b7cf4c7d5b7496c0032021e43115d39.camel@gmail.com> <87muif2y4l.fsf@dja-thinkpad.axtens.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Mackerras , Oleg Nesterov Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, 2019-06-18 at 16:42 +1000, Daniel Axtens wrote: > Radu Rendec < > radu.rendec@gmail.com > > writes: > > > On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote: > > > Radu Rendec < > > > radu.rendec@gmail.com > > > > > > > writes: > > > > Hi Everyone, > > > > > > > > I'm following up on the ptrace() problem that I reported a few days ago. > > > > I believe my version of the code handles all cases correctly. While the > > > > problem essentially boils down to dividing the fpidx by 2 on PPC32, it > > > > becomes tricky when the same code must work correctly on both PPC32 and > > > > PPC64. > > > > > > > > One other thing that I believe was handled incorrectly in the previous > > > > version is the unused half of fpscr on PPC32. Note that while PT_FPSCR > > > > is defined as (PT_FPR0 + 2*32 + 1), making only the upper half visible, > > > > PT_FPR0 + 2*32 still corresponds to a possible address that userspace > > > > can pass. In that case, comparing fpidx to (PT_FPSCR - PT_FPR0) would > > > > cause an invalid access to the FPU registers array. > > > > > > > > I tested the patch on 4.9.179, but that part of the code is identical in > > > > recent kernels so it should work just the same. > > > > > > > > I wrote a simple test program than can be used to quickly test (on an > > > > x86_64 host) that all cases are handled correctly for both PPC32/PPC64. > > > > The code is included below. > > > > > > > > I also tested with gdbserver (test patch included below) and verified > > > > that it generates two ptrace() calls for each FPU register, with > > > > addresses between 0xc0 and 0x1bc. > > > > > > Thanks for looking in to this. I can confirm your issue. What I'm > > > currently wondering is: what is the behaviour with a 32-bit userspace on > > > a 64-bit kernel? Should they also be going down the 32-bit path as far > > > as calculating offsets goes? > > > > Thanks for reviewing this. I haven't thought about the 32-bit userspace > > on a 64-bit kernel, that is a very good question. Userspace passes a > > pointer, so in theory it could go down either path as long as the > > pointer points to the right data type. > > > > I will go back to the gdb source code and try to figure out if that case > > is handled in a special way. If not, it's probably safe to assume that a > > 32-bit userspace should always go down the 32-bit path regardless of the > > kernel bitness (in which case I think I have to change my patch). > > It doesn't seem to reproduce on a 64-bit kernel with 32-bit > userspace. Couldn't tell you why - if you can figure it out from the gdb > source code I'd love to know! I have, however, tried it - and all the fp > registers look correct and KASAN doesn't pick up any memory corruption. I looked at the gdb source code and all it seems to care about is the architecture it was compiled for. In other words, 32-bit gdb always assumes 32-bit register layout, regardless of whether it's running on a 32-bit or 64-bit kernel. So it's no surprise that the problem didn't reproduce and KASAN didn't pick up anything in your experiment. Since the kernel is 64-bit, it divides addresses by 8, so all indexes are within bounds. The part that I don't get is how the FP registers looked correct. Since you already have a working setup, it would be nice if you could add a printk to arch_ptrace() to print the address and confirm what I believe happens (by reading the gdb source code). So for 32-bit gdb on 64-bit kernel, I think gdb will generate 48 x 4- byte aligned addresses for the CPU registers, then 32 x 2 x 4-byte aligned addresses for the FPU registers. The indexes will not overflow, but access to all registers (CPU and FPU) will be broken because: * The kernel always divides by 8. The CPU register address range that gdb generates will be half of what the kernel expects and "odd" (i.e. non 8-byte aligned) addresses will fail with EIO because the kernel code checks that the last 3 bits are all zero. * The FPU register indexes will be off by 24. For example, when gdb thinks it asks for FPR0, it calculates the address as 4 x 48, but the kernel divides by 8, so it will get index 24, which it thinks is a CPU register. When it stops on a breakpoint, gdb seems to read all registers (both CPU and FPU) in ascending index order. So if you print the address in the kernel it's actually very easy to verify my theory. I expect addresses from 0 to 48 x 4 in increments of 4 (for the CPU registers), then addresses from 48 x 4 to 48 x 4 + 32 x 2 x 4 in increments of 4 (for the FPU registers). Best regards, Radu