Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp14090686ybl; Mon, 30 Dec 2019 03:59:10 -0800 (PST) X-Google-Smtp-Source: APXvYqwNuOPVpvatZhEBvfKqFfx0jHP3PB11PBJGYbbx7s4BGJtjBaeMcjiv+R9S4+IuEjAqi8Ar X-Received: by 2002:a9d:7ac9:: with SMTP id m9mr70809415otn.80.1577707150449; Mon, 30 Dec 2019 03:59:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577707150; cv=none; d=google.com; s=arc-20160816; b=OsUe4PFrj2YcXLXRCV+cxGjXRqIgKABjjpS+k6wNsZ8HbdhGOkfQKsgdbTLFVVLzR+ NzS1rV8dBffyPJxfLcMzlwz65pkThC91pQIC57jKrjh7s/AEiMGlfsqD5C/g0zINX6v4 w8eCYV6pWIKvIcwNzNpRl2GwtIV0xEQSeeLS0Z4hHBCtD0NJnj/SIM3XWxQDeNlHwtVc iHzHAq443TFAaDc0Nq1nkNZtkUTflw7D84fvD1L6RzMBVrCZc11StzaEjxENmoIbxHf4 3vYcOH7KwRdwOQRg2s81JY+TLCfTG714GsmS4JBFAk4fl/7aauz/hi72547kt4jbl+lg kQ6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=w8lXNd1r8MJMenIuy0jo5kU2uQVuVsLapsUT9MkbqDM=; b=NFrnxVP4nxLpIgffL919r92/p9RNMnFUBe/62F4OsypWCr11xH8AGVsEaY1t5mqP+e A/SSG0eRp9TWSbh+oL6uJyyvNW6LsKio710GvAONeHZZnq5NTKx6B2L65wn9OQJbgUU4 TnYxM99AzOA8Ixi6AiffyFBXG0B4cvVGgYz0vfLNAyyX8yMntO22OsiVzAyFSugQwLGJ Axk9pueRN6gYsXwnw3EXxuFy22qdLvQYMHPOjkMTjcLqI9EENKc3eZj0DExg3FUlddCj ERbu6cuSwsTkMZU3fnwz76oHnTSOZyaxE9GwedM8BDEPxZAf8xu1Fuyhq4nqvSzcwuus pu0A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h64si14711453oif.215.2019.12.30.03.58.57; Mon, 30 Dec 2019 03:59:10 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727406AbfL3L6T (ORCPT + 99 others); Mon, 30 Dec 2019 06:58:19 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:46813 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbfL3L6S (ORCPT ); Mon, 30 Dec 2019 06:58:18 -0500 Received: from mail-qk1-f172.google.com ([209.85.222.172]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MLAAs-1j3yVH10x0-00IAEi; Mon, 30 Dec 2019 12:58:17 +0100 Received: by mail-qk1-f172.google.com with SMTP id t129so26064714qke.10; Mon, 30 Dec 2019 03:58:16 -0800 (PST) X-Gm-Message-State: APjAAAVMiyVtXV/+kbCMWFGoHfQnRzBjT9l92VEp+9YnGivmbWc1HQH5 teSn2LW2cHeUgkdSy+Xlw91eLAadFyXfFzKjc/U= X-Received: by 2002:a05:620a:a5b:: with SMTP id j27mr54486692qka.286.1577707096044; Mon, 30 Dec 2019 03:58:16 -0800 (PST) MIME-Version: 1.0 References: <20191223130834.GA102399@zx2c4.com> <20191224135404.389039-1-Jason@zx2c4.com> In-Reply-To: <20191224135404.389039-1-Jason@zx2c4.com> From: Arnd Bergmann Date: Mon, 30 Dec 2019 12:57:59 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mips: vdso: conditionalize 32-bit time functions on COMPAT_32BIT_TIME To: "Jason A. Donenfeld" Cc: "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Paul Burton , Vincenzo Frascino , Christian Brauner Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:9VNsB/0hV+uE9zUbhnqLZ6nurlkV2+Py0P0PFGmNrhG80WpHmRM X77X2nwlZHYi/To/p16EOLRgfwnnqAnGvcMG/VZEHeXKRArVYQbC1hhx3cd2nvbeq6KOpQd u73ajuKjYbjn2ONuh+c0xo49lcdBaFuws7Lp7hgZfpx5Mj0f4VYKeFeHsQO3lrsV23Mf523 RKuU1siU/zZrRLLKCB5Zw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Kso8zCSd2bA=:jMb7H0gBZZ4sMXVuHy6w9T Lr6JTxyoKWk0SgMA2EJScqQoiA2ZFX8e4JY5BYQ5Po6b6w7AJTj48dZoVZRo1v5Bpl5rNKPoQ AmzCEGoH7LcpphD6i1u9+Fn3l2xl0DHlhmo6MJIbyIa1OmubDodffmSmCslji+AdMx/fIJx37 gYj57dSYaGatpCulyfNvJVrf9BqjXfeEKZQhRdhsEU9P5eXIfIBaG6zAhyT+uPTbt4g7WfpE9 LXZ6qJIInFy6bPvMjkXyolibuCND42XmXRvsm1RyBPyo5t71KlrSWch2dTpMRwx5HlzcDkxfe 7Qxx2b3iWm0iYhGXAeS7KryFPup3svVRxq9uReEBfFnyE54iSvTJPHJk4gPF26KGZUC8P7QRG 8LtZCHia9xQHnvZi9YSjZfbp1qBen7EcRoKtLHgAe1zeh+PFuqk7NmuqjRa+n2vaApIaTY2Gw JSQxibZ6fZjppy+SkEgtgUbvjNRne3oUogcATAGMo4E40VGV+wnXCu4n+sV6K/Xo3KhKYA6QD yTOlDwOYpOUTQRyj058qETqz5WTSmCc9wzv+7U8IpvSd/JCJ2Rxdoknn+vQ8LPrbrmdFZyFQt fth8nAg7OmKhVCpcLUaMl8EcDbh6xrFetTOS0iW0oDvfueMSvDSokrUxD5Ncs/kRyFhb5eGKe k4QvZuxIxVLEsRkK1F5wP00fTjND2G9k5vaW2CZrKJitsf7JznJZRi2deMrMf84A893S0LipT rDpEmEW4OgzHWsWLmwS8JwyhgHdOhw6lkf56NxRFnM9c+cHGcb02SNubkZs+NpUc+Nx2H3iDI bvW/YdUxvsbgRMqb8RIZGG9m0jaing4rbcQTp5j5fZmMmoByWZNkPLjaSWODrHO8kMMJB9JDV R3JehtGBI1ymV1mYOMMw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 24, 2019 at 2:54 PM Jason A. Donenfeld wrote: > > When the VDSO falls back to 32-bit time functions on kernels with > COMPAT_32BIT_TIME=n, userspace becomes corrupted and appears to crash > shortly after, with something like: > > [ 0.359617] do_page_fault(): sending SIGSEGV to init for invalid read access from 000000007ff790d0 > [ 0.359843] epc = 0000000077e45df4 in libc.so[77da6000+de000] > [ 0.360319] ra = 0000000010000c50 in init[10000000+2000] > [ 0.364456] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > > This can be reproduced with simply calling `clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts)`, > since `CLOCK_PROCESS_CPUTIME_ID` is not exported to the VDSO, invoking > the syscall callback branch. This crash was observed with musl 1.20's > clock_gettime implementation: Thanks for the bug report! I'm not completely sure why this fails in this particular way though. I assume you are using musl-1.1.20, not a musl-1.2.0 snapshot (the version 1.20 you list does not exist), so the combination you are testing is supposed to just return -ENOSYS here to match the behavior of hte system call. > --- a/arch/mips/include/asm/vdso/gettimeofday.h > +++ b/arch/mips/include/asm/vdso/gettimeofday.h > @@ -107,7 +107,7 @@ static __always_inline int clock_getres_fallback( > return error ? -ret : ret; > } > > -#if _MIPS_SIM != _MIPS_SIM_ABI64 > +#if _MIPS_SIM != _MIPS_SIM_ABI64 && defined(CONFIG_COMPAT_32BIT_TIME) > > #define VDSO_HAS_32BIT_FALLBACK 1 > I don't think this is the correct fix, it may actually make it worse by changing the vdso implementation for clock_gettime32() to fall back to clock_gettime64(), which would appear to work correctly before y2038 but fail afterwards. How about this one: diff --git a/arch/mips/vdso/vdso.lds.S b/arch/mips/vdso/vdso.lds.S index da4627430aba..0bdc6a026be8 100644 --- a/arch/mips/vdso/vdso.lds.S +++ b/arch/mips/vdso/vdso.lds.S @@ -93,9 +93,11 @@ VERSION LINUX_2.6 { #ifndef DISABLE_MIPS_VDSO global: +#if (_MIPS_SIM == _MIPS_SIM_ABI64) || defined(CONFIG_COMPAT_32BIT_TIME) __vdso_clock_gettime; __vdso_gettimeofday; __vdso_clock_getres; +#endif #if _MIPS_SIM != _MIPS_SIM_ABI64 __vdso_clock_gettime64; #endif That should ensure that no user space can call the old vdso functions on a kernel that intentionally breaks the actual syscalls. Arnd