Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1363139imu; Wed, 16 Jan 2019 18:11:03 -0800 (PST) X-Google-Smtp-Source: ALg8bN5v/Z6zKKKo1bfyA3ij1S4Pf5Ksi3VjbaASpLK41Jt8aM+ZATMjmRps/yUEuIMCdqQS691w X-Received: by 2002:a63:200e:: with SMTP id g14mr11750260pgg.235.1547691063428; Wed, 16 Jan 2019 18:11:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547691063; cv=none; d=google.com; s=arc-20160816; b=G79d9DGncmQMeo2rHaA5L0BmoKzWgGq7h1UcVjUzBEDUiq2uWaMDCQNX7pOO6fCJ31 WdZelClT0j2IhI52aJiNUkNKNc3rOyxBvFbGlDBSsgjVjQQmxynk+27cVPc5Oer5qiJi kZWSSNApbLWOaUnfhD7c4pqakOlmZXwQqyvvnR9hz9xzT+PbxKOGFTgmCrPRg5OpmDNE ueefyu4w2BO8bDSWqi/+E5rjVCIb9eevJ0PRy0W31jbxG96ygfKzDJe14uMPKguLmAK/ 87U5R2lGJ4d1ECIx1rvnMsMc2HtRf5wbKAhme1HYAx3xp/Yq4xu0IF+ozDYuSyU4vn4S 515Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=EXIW7bVzHWS1DHDPDbxMnongYlAY8CFRBhpc/tSDLb4=; b=tIe9AVd+aFte4J8NxD4p1gddxW9Qhk6ckFJiN70Eam235k5UlwD8Hp7cgIS4AHbwwC jdEpyzhLF3eB1jiwlDp4KEg7DiNFj7y+JdGiEoPqst5hY7NoS1ihjydCFTDykZUOeC3a rQCJLfU0IdXni7ZzEV+4GShNixnR3lUfZOqWWWr7jrKcr3lZ5lSKkaNSP+AY/+Bi/wT5 2YaN/u//DNxo4Ck8SYt9tSFxyrPenOt5Krpuh0TslUYb4QZU3AuWewGraii/GzYs11Bf 7t7zHs3YEZKY0mL2Gtsog0ZFbdDfpATjn3nkX6UlXgRDuGkaAbi+oiVEoyifJwJvXIAp B4+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tytqg4+v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 187si178967pfv.238.2019.01.16.18.10.47; Wed, 16 Jan 2019 18:11:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tytqg4+v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727012AbfAQB53 (ORCPT + 99 others); Wed, 16 Jan 2019 20:57:29 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:38114 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbfAQB53 (ORCPT ); Wed, 16 Jan 2019 20:57:29 -0500 Received: by mail-ot1-f66.google.com with SMTP id e12so9724758otl.5 for ; Wed, 16 Jan 2019 17:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EXIW7bVzHWS1DHDPDbxMnongYlAY8CFRBhpc/tSDLb4=; b=tytqg4+veE2PMT5iR8Y5szfVVaeuogXMa+zTTIZ1ZQX7ZJ1ViMPbDfv0JuYClrVGfC apu0vIZgdyUNztXMZOc5bPi+bgkHbUhUV5JZWsu2wUBbBWlPfY1/AHUACsSN0/QRtonF 4Y5tylh2zP4PWsn6dEdJ/xLE7YZDzW3SAJ3FIQUMsPU9PraGJXhWZFP0wL537ZONjEk3 wFP28/4apl3ucv5BLKTeu9QQaAOnjNeosypY4Y/w6nJPGdJzQeUIlEvRiviVYFXUUKz8 Tc5pkGAN2eo6/jgS9yRwWTDBWfXaIJJvIpBRWYUBiTg9VhdBn5FhOg9ln/IxJ1MEbVI5 6MRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EXIW7bVzHWS1DHDPDbxMnongYlAY8CFRBhpc/tSDLb4=; b=GFeGE8JHKYdPYJNgAWbmicJkDt2fIxDp7x8SpzjPMS4rw1ofivY/EehTuOuB7ZRCKk EWdz3EqaMXXMZkURaV9pqnCsDPRf7U3kt93ynR6REcpJn63elNibncc/iGkkEY28GyPH QxY1vmgkUghqGiGmUp8E+Yfba5tsXUNso47fhwCb19bduQHvcg2fY8zESdGmAp5l3MiD gYrNAW17Gc2kaRC+ZbXaOP/1wZsJJX22TQe5488dfEIZUM+udlRTeeVZfWRAoNIR0hoj ZUq01drKhu3jiQqR7tSLbsJ84tNIW6+IDhsVRGhO1xml6B1vx0fGC6DX67ks6dx2eWa7 +AKA== X-Gm-Message-State: AJcUukfDfT8gfef54N4PwvV3gQnEMTY5s5jorsBWJ8B1sjIZAqL7LoPg ZJ8OWRfuAwLHmSWB1TXytiy/BX1ce13HsmlM2g8= X-Received: by 2002:a05:6830:1584:: with SMTP id i4mr7042971otr.116.1547690248430; Wed, 16 Jan 2019 17:57:28 -0800 (PST) MIME-Version: 1.0 References: <20190116164817.GG1910@brain-police> In-Reply-To: <20190116164817.GG1910@brain-police> From: Kassey Date: Thu, 17 Jan 2019 09:57:17 +0800 Message-ID: Subject: Re: arm64: copy_from_user access the last page of ddr has problem on 4.14 kernel To: Will Deacon Cc: linux-kernel@vger.kernel.org, willy@infradead.org, kassey@126.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, mark.rutland@arm.com, robin.murphy@arm.com, ard.biesheuvel@linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org hi, Will it is hard to try on v5.0-rc2 kernel, since there is much port job to be done. dst kernel buffer is looks overwriten by some same(fix) patter start with "mmap" (0x6d6d7061) see below code (data from vmalloc), and file is mmaped (include the last phy page of ddr.) see below pattern and pieces of code. not sure if there is boundary issue for copy_from_user, please help to suggest if you got some idea from the pattern, thanks. 0079c00 6d6d 7061 0000 0000 0848 fd8f 0001 0000 0079c10 0048 fd8f 0001 0000 0001 0000 0003 0000 0079c20 2000 fd83 0001 0000 1fff fd86 0001 0000 0079c30 0000 0000 0000 0000 700f 0000 0000 0000 0079c40 6d6d 7061 0000 0000 f448 ffff 0001 0000 0079c50 f748 ffff 0001 0000 0001 0000 0004 0000 0079c60 3000 fd8c 0001 0000 2fff fd8e 0001 0000 0079c70 0000 0000 0000 0000 700f 0000 0000 0000 0079c80 c103 0606 0100 be00 1009 3b00 3b07 0607 0079c90 0100 5700 1006 e800 8c03 3103 0100 0a00 0079ca0 0000 cf00 bf08 0a00 0100 5700 1006 3700 0079cb0 3906 0606 0100 1600 0004 4700 9902 0207 0079cc0 6d6d 7061 0000 0000 f808 ffff 0001 0000 0079cd0 f1c8 ffff 0001 0000 0001 0000 0005 0000 0079ce0 d000 fff8 0001 0000 efff fffa 0001 0000 0079cf0 0000 0000 0000 0000 700f 0000 0000 0000 0079d00 6d6d 7061 0000 0000 f1c8 ffff 0001 0000 0079d10 f388 ffff 0001 0000 0001 0000 0003 0000 0079d20 c000 ffdf 0001 0000 6fff fff8 0001 0000 0079d30 0000 0000 0000 0000 700f 0000 0000 0000 0079d40 9407 0901 0100 5300 0204 b400 d503 0a04 0079d50 0100 0000 0001 0200 7309 0202 0100 0200 0079d60 5000 0200 7309 0202 0400 ff00 f7ff 94ff 0079d70 b400 0208 0100 dc00 0000 b400 5803 0607 0079d80 6d6d 7061 0000 0000 f7c8 ffff 0001 0000 static ssize_t sel_write_load(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { ssize_t length; void *data =3D NULL; mutex_lock(&sel_mutex); length =3D avc_has_perm(current_sid(), SECINITSID_SECURITY, SECCLASS_SECURITY, SECURITY__LOAD_POLICY, NULL); if (length) goto out; /* No partial writes. */ length =3D -EINVAL; if (*ppos !=3D 0) goto out; length =3D -EFBIG; if (count > 64 * 1024 * 1024) goto out; length =3D -ENOMEM; data =3D vmalloc(count); // dst buffer in kernel if (!data) goto out; length =3D -EFAULT; if (copy_from_user(data, buf, count) !=3D 0) goto out; BR Kassey Will Deacon =E4=BA=8E2019=E5=B9=B41=E6=9C=8817=E6=97= =A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=8812:48=E5=86=99=E9=81=93=EF=BC=9A > > [I'm due to get on a long flight shortly, so I've added LAKML and a few > others to CC] > > On Wed, Jan 16, 2019 at 11:25:15AM +0800, Kassey wrote: > > Hi, Will and team: > > > > we met a issue when copy_from_user to access the last page of DDR > > on 4.14 kenrel, below is the detail steps, > > can you help to suggest if there is know fix or debug something ? > > > > 1. we mmap ( in userspace) a region of phy address that is not > > continous but include the last page of ddr > > > > for example our ddr end is 0x200000000 > > the last page is fall in below addr: > > 0x1fffff000 to 0x200000000 > > > > 2. we using copy_from_user to copy these mmap address to kernel buffer > > > > 3. and we find everytime when trying to copy_from_user the last page > > in phy of ddr, > > the dst kernel buffer is looks overwrite by some same patten start > > with "mmap" in this last page ,but the src in the last page of ddr is > > still correct. > > > > is there any know issue for copy_from_user to accces the last page of > > phy ddr mmaped by userspace ? > > Not that I'm aware of. Are you using defconfig and can you reproduce the > problem with mainline (e.g. v5.0-rc2)? What exactly do you mean by: > > "the fst kernel buffer is looks overwrite by some same patten start wit= h > "mmap""? > > Does the copy_from_user fail (what does it return?) or does it succeed bu= t > the data copied appears to be junk? Is it deterministic? Could you share = an > example of what the corrupted data looks like, please? > > Cheers, > > Will --=20 Best regards Kassey