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=-8.5 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,USER_AGENT_MUTT 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 3C418C43381 for ; Fri, 29 Mar 2019 15:59:57 +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 0B8B42070B for ; Fri, 29 Mar 2019 15:59:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pb8G9l6T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B8B42070B 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:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gV/PcICpB5j9FGMcg0viWIDoZ+Dobozk8uqodlYSTYU=; b=pb8G9l6TpsJeC3 8CWLmasG0O5UQVrYowoc8fgp8PqqoM5rlf2/5WQ/xtkxZcXpo5wxv2r7Aqr+Y0RL4EqnG6IeZk3v3 f7E6/l1HLvPti4qBJ/2p4MORAKDiU1yHN9i4mC1kUeZXM26AbO4+Arw3t6BNsjxkOb8MRw9yRrnKq 7JWH3xh4PUXo6Akny+n92h30rVPKqnLyDKYAh2sS751daELixl9ZrfrGHRySZNPVgch+H5Ogtt015 QzIgWIjrYahzu/dU//Dni4BtjYbyCLYNGEDdIAWFcz2/jwztFwfZugipedeo2glnTZfxSyDp4m+0R 5KXOJ6IYC20r0MczbVtg==; 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 1h9tv3-0000uk-Cg; Fri, 29 Mar 2019 15:59:49 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9tuw-0000uK-P1 for linux-arm-kernel@lists.infradead.org; Fri, 29 Mar 2019 15:59:44 +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 AF90280D; Fri, 29 Mar 2019 08:59:41 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C0043F614; Fri, 29 Mar 2019 08:59:40 -0700 (PDT) Date: Fri, 29 Mar 2019 15:59:37 +0000 From: Catalin Marinas To: Vincenzo Frascino Subject: Re: [PATCH 5/5] arm64: compat: Reduce address limit Message-ID: <20190329155937.GA48010@arrakis.emea.arm.com> References: <20190319151542.19557-1-vincenzo.frascino@arm.com> <20190319151542.19557-6-vincenzo.frascino@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190319151542.19557-6-vincenzo.frascino@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190329_085942_816022_98E8FAEF X-CRM114-Status: GOOD ( 20.43 ) 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 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. 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). 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. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel