From patchwork Wed Jan 30 16:32:00 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jann Horn X-Patchwork-Id: 10788963 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 30B2A13BF for ; Wed, 30 Jan 2019 16:32:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1AB472FF6F for ; Wed, 30 Jan 2019 16:32:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 181962FF9A; Wed, 30 Jan 2019 16:32:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 902822FF6F for ; Wed, 30 Jan 2019 16:32:41 +0000 (UTC) Received: (qmail 30700 invoked by uid 550); 30 Jan 2019 16:32:39 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 30667 invoked from network); 30 Jan 2019 16:32:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=P3LJhH6cgW4upA2EWRXXc/wXQNtn/k7S03s//A6su1g=; b=kpw2ZIFeUCBxsDcxNjhh3Hy585LqG168l0ocOK2C3yTm+7PjfjeB2Q9f8RSc2L3iLV 6I+wP22GZsEtZQ7fFBgZfot3EC5ReLs8CDvET93xlb5LMd2dc+pa5PJVr0XcnEzpYvjB DBsWam1wJ5r0GHiXNttNVDJaablE5HVhUuXKQn0zso8RoQtQyqhXRSobk6gkoytWgRT2 SeUEnTahHzJjfyV3t+Mqp8DRTIFJXt8ViDm1+g/7fkTgvxK7TFeXNHgWiMXv0YDhBChC sqx2pq0xKl4GMeJWMiRtAw+jwf/snlqQnOlrP3wVCq4bdTSeX+dfwUNrht7x2xAyPa1q Og8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=P3LJhH6cgW4upA2EWRXXc/wXQNtn/k7S03s//A6su1g=; b=KcARBF4xqKdruzvKJx668WKmoqV8JqYX8yyusZRMbt9GiwMV1EqFwufLUBW4xCupL2 BjhD+lPax9EV9T6e/+fHIe5zjrBmW4mRtH7mbHolNmm20cUfgsi9do2Ui9NihhVHormh StGybVG1Ad7mLszx/uPVRsLSua1+nB1GtClVjfmLW9J7v0VAgFKgwaz/OUOmCPuthTSC /ZtpoWCFz0bVUa7tGmc0q0wqgVnuS/4eSGXfu97UmsKAhAuxgfzIPlwbOBeRnP3Q2BUD 0YeaTwiZMZlNo5HCW2UPx0Bw33tLo6xivouE6TmQc9fcAriTkG4M5L1c0zlXRZrz/gMc EnUg== X-Gm-Message-State: AJcUukceSn84WLb4Zvla/Bfe/nTEBgYt+8QVbRRxAf6Df1ermk8HmLWW etKujhpRba0hL5U9377tcmLKYsAJ4BG0oIdNB2wfXQ== X-Google-Smtp-Source: ALg8bN45MHCQnyC0t7Ivu27C/GsFmiyhloUnQg4Wml8VU64GpqLrhQuMqastC/b7fXBQGxkJXTqTmdlwEcVj9i9lhCs= X-Received: by 2002:a9d:4c01:: with SMTP id l1mr23359047otf.242.1548865946597; Wed, 30 Jan 2019 08:32:26 -0800 (PST) MIME-Version: 1.0 From: Jann Horn Date: Wed, 30 Jan 2019 17:32:00 +0100 Message-ID: Subject: ARM64 suggestion: reduce the compat address limit (currently 0x100000000)? To: Catalin Marinas , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Kernel Hardening , kernel list X-Virus-Scanned: ClamAV using ClamSMTP Hi! At the moment, compat tasks running on ARM64 can allocate memory up to 0x100000000 (TASK_SIZE_32). Testing on an Android device (with an admittedly somewhat old kernel): ============== =========== $ cat mmap_filler.c #include #include #include #include #include int main(void) { unsigned long size = 1UL<<31; while (size >= 0x1000UL) { void *res = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0); if (res == MAP_FAILED) size >>= 1; } int fd = open("/proc/self/maps", O_RDONLY); if (fd == -1) err(1, "open"); while (1) { char buf[0x1000]; ssize_t res = read(fd, buf, sizeof(buf)); if (res == -1) err(1, "read"); if (res == 0) _exit(0); ssize_t wres = write(1, buf, res); if (wres != res) errx(1, "write failed"); } } $ arm-linux-gnueabi-gcc -static -o mmap_filler mmap_filler.c && adb push mmap_filler /data/local/tmp/ && adb shell /data/local/tmp/mmap_filler mmap_filler: 1 file pushed. 16.3 MB/s (587008 bytes in 0.034s) 00008000-00010000 rw-p 00000000 00:00 0 00010000-00089000 r-xp 00000000 103:1d 2080772 /data/local/tmp/mmap_filler 00089000-00098000 rw-p 00000000 00:00 0 00098000-0009a000 rw-p 00078000 103:1d 2080772 /data/local/tmp/mmap_filler 0009a000-0009b000 rw-p 00000000 00:00 0 0009b000-00752000 rw-p 00000000 00:00 0 [heap] 00752000-00774000 rw-p 00000000 00:00 0 [heap] 00774000-f081b000 rw-p 00000000 00:00 0 [heap] f081b000-f081c000 r--p 00000000 00:00 0 [vvar] f081c000-f081e000 r-xp 00000000 00:00 0 [vdso] f081e000-ff710000 rw-p 00000000 00:00 0 ff810000-ff831000 rw-p 00000000 00:00 0 [stack] ff831000-ffff0000 rw-p 00000000 00:00 0 ffff0000-ffff1000 r-xp 00000000 00:00 0 [kuserhelpers] ffff1000-100000000 rw-p 00000000 00:00 0 =========== This means that mmap() allocations do not adhere to section 6.5.8 of C99 ("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.") if you treat mmap() allocations as returning an array. In practice, I've also seen code that does things like computing a pointer that is out of bounds by a few bytes and then comparing it against the end of the array; while this is UB according to C99, it probably makes sense to try to avoid breaking such code. X86-64's compat code uses the limit 0xFFFFe000 (IA32_PAGE_OFFSET), which I think makes more sense. Would it make sense to do something like the following (untested)? ============== diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h index f1a7ab18faf3..a0c7eb1358dd 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(0xFFFFe000) #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) ? \