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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 C58E4C43381 for ; Mon, 1 Apr 2019 09:13:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 7EA4F213A2 for ; Mon, 1 Apr 2019 09:13:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="co9h/k8S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EA4F213A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DtBSa5J0v1yqB4RQG/CIKetgOs7sifwosQVa0LVJfsA=; b=co9h/k8SQt5NrD 8hEmsVwlU7CEsxZuIKoG44rUMuxcOz6O4dOWEOXZ23alH5/Zvw2H0RNIGZ2FCBYxlx+sxeGEqf/bo Xrw9KPyPrh7GuEc/je39MD+3bvjWfahOe+iXrURKC63D/8T+Otrshn/sg6ctdOreiY3cEd3+MzBlc MkETw/4NVC1EbF1GjFV5/Bmzu5Sc8KkjFgodtXoJlegviK015Qvie97YFYI0kw0tqB/Rw2yukhgz3 vBKH5aTtcax0/JpDi7+S1hvOdWKApM+dFpRu6BCQAckzZcDOefm7zpuPHZzBUWmgfoKhg/ekE1IIN fqvJCOMDfZ7PYsUIgJHA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hAt0s-0007KC-My; Mon, 01 Apr 2019 09:13:54 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hAt0p-0007Ji-H3 for linux-arm-kernel@lists.infradead.org; Mon, 01 Apr 2019 09:13:52 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DF22F374; Mon, 1 Apr 2019 02:13:50 -0700 (PDT) Received: from [10.1.196.72] (e119884-lin.cambridge.arm.com [10.1.196.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD8A23F690; Mon, 1 Apr 2019 02:13:49 -0700 (PDT) Subject: Re: [PATCH 5/5] arm64: compat: Reduce address limit To: Catalin Marinas References: <20190319151542.19557-1-vincenzo.frascino@arm.com> <20190319151542.19557-6-vincenzo.frascino@arm.com> <20190329155937.GA48010@arrakis.emea.arm.com> From: Vincenzo Frascino Message-ID: <682cdfd5-200c-4e1e-2863-605e44f3e5e8@arm.com> Date: Mon, 1 Apr 2019 10:13:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190329155937.GA48010@arrakis.emea.arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190401_021351_571243_BB018336 X-CRM114-Status: GOOD ( 26.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Mark Rutland , Will Deacon , linux-arm-kernel@lists.infradead.org, Jann Horn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 29/03/2019 15:59, Catalin Marinas wrote: > On Tue, Mar 19, 2019 at 03:15:42PM +0000, Vincenzo Frascino wrote: >> Currently, compat tasks running on arm64 can allocate memory up to >> TASK_SIZE_32 (UL(0x100000000)). >> >> This means that mmap() allocations, if we treat them as returning an >> array, are not compliant with the sections 6.5.8 of the C standard >> (C99) which states that: "If the expression P points to an element of >> an array object and the expression Q points to the last element of the >> same array object, the pointer expression Q+1 compares greater than P". >> >> Redefine TASK_SIZE_32 to address the issue. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Jann Horn >> Reported-by: Jann Horn >> Signed-off-by: Vincenzo Frascino >> --- >> arch/arm64/include/asm/processor.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h >> index 07c873fce961..4c689740940d 100644 >> --- a/arch/arm64/include/asm/processor.h >> +++ b/arch/arm64/include/asm/processor.h >> @@ -57,7 +57,7 @@ >> #define TASK_SIZE_64 (UL(1) << vabits_user) >> >> #ifdef CONFIG_COMPAT >> -#define TASK_SIZE_32 UL(0x100000000) >> +#define TASK_SIZE_32 (UL(0x100000000) - PAGE_SIZE) >> #define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ >> TASK_SIZE_32 : TASK_SIZE_64) >> #define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \ > > So what I meant with the previous comment, can we have this: > > #ifndef CONFIG_ARM64_64K_PAGES > #define TASK_SIZE_32 (UK(0x100000000) - PAGE_SIZE) > #endif > > and still have a vectors page with 64K configuration? Assuming that it > is not unmapped, an mmap() wouldn't return the 0xffff0000 page to break > the C99 requirements. There is the case of user unmapping the vectors > page (which seems to be allowed based on my reading of the code) and > then getting an mmap() at the end for the 32-bit address range but I > really don't think we should cover for this case. > The current set is designed to cover all the cases, but I am fine either way. > Another option which I think would cover the unmap case as well in all > configurations is to handle the limit in arch_get_mmap_end(). We already > define this to handle mmap limitation on 52-bit user VA but you can make > it handle compat tasks (and probably turn it into a static inline > function). > I like this approach more than what I proposed in the current series, but I think this is not easily back-portable to stable. > The other patches for splitting the vectors page in two are still valid > (to be on par with arm32) but they would not be required for this fix. > Ok, to summarize, this is what I am going to do next: - Send a patch that includes your comments about CONFIG_ARM64_64K_PAGES. - Send a separate series for kuser helpers leaving them enabled by default in all the cases. - Create a new series based on arch_get_mmap_end(). -- Regards, Vincenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel