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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 916A7C4332D for ; Thu, 19 Mar 2020 15:50:05 +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 6269020724 for ; Thu, 19 Mar 2020 15:50:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AECWqYFN"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="WZUFhydF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6269020724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bX4PAwhvyzB+19pwIUGAVq70HpNAitPws5fLLSsCOKY=; b=AECWqYFNzmYxTU SrgvJWW5l5rG9XhdtsfcWEovpIiOZ26lFhuGAHSb2K35dlXa0hQ8KddM/AmDMZX0rqkpu0JgxnSLv //RTtccr9pIb1tO7+f6cZA/Q89PrJMfGBXWhL+zDfn7W/JzeVhSpEOR7hTVa1P+eHUZBZ6aQEsXmU IEf5/LPw7x+CfE03aLqmdIHpFVxK/2HXHiIFs2UYLuRekl8nbxTtUi/0KOHrzV4ss2UTWeT6ztu+o oaKeuq4907cPP6S/dz9W7+G8MnnB46PQKrhpG8Q2+5+QpwImReCz6HiFTxifErVDteQJsBRhHsutc 0iuqIbNEasaiGP2F+8BA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jExQo-0006JK-5C; Thu, 19 Mar 2020 15:50:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jExQk-0006IU-MR for linux-arm-kernel@lists.infradead.org; Thu, 19 Mar 2020 15:49:59 +0000 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF8E121973 for ; Thu, 19 Mar 2020 15:49:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584632998; bh=Rkh1vXkhW9rmZk8EPxDBYiPb1mQUKR3iI0zKH1Fg7V0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WZUFhydFW+Cby4n4jF5wJlr3MQjDUpTFw2i9V1LHv+NPUTRvg4c5vXR+39NvQ36hV LV2qdarSCIR9wOQ6JSNEy9hrK7Cx7AstvxQJmgf67dj2IdXfO9Yyr1uyLhJbSZ+zZD pTmckZRZnqhY2vCuCiqv/Zba/M1uKnMFKJ5yAAq8= Received: by mail-wr1-f52.google.com with SMTP id h4so3699706wru.2 for ; Thu, 19 Mar 2020 08:49:57 -0700 (PDT) X-Gm-Message-State: ANhLgQ11PNpdaT5w1icwHYd/+sI7gQLrDehvhfn+0udXeWtgkIPZ5vbk 9o0L7wwuFgDtspxunTYDSeRgEK/VYIMnTDt/K8iqew== X-Google-Smtp-Source: ADFU+vsxkngrkFV8I9T5oK6bcpr4TwgtNHg0eR2cNw6mloMNXkw0k55Rziijc9a+w3nNSCb9M7gTmTIBkLDmnkww4I4= X-Received: by 2002:adf:9dc6:: with SMTP id q6mr4999539wre.70.1584632996131; Thu, 19 Mar 2020 08:49:56 -0700 (PDT) MIME-Version: 1.0 References: <20200317122220.30393-1-vincenzo.frascino@arm.com> <20200317122220.30393-19-vincenzo.frascino@arm.com> <20200317143834.GC632169@arrakis.emea.arm.com> In-Reply-To: <20200317143834.GC632169@arrakis.emea.arm.com> From: Andy Lutomirski Date: Thu, 19 Mar 2020 08:49:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 18/26] arm64: vdso32: Replace TASK_SIZE_32 check in vgettimeofday To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200319_084958_774284_D9D1D0BA X-CRM114-Status: GOOD ( 17.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Dmitry Safonov <0x7f454c46@gmail.com>, "open list:MIPS" , Vincenzo Frascino , Will Deacon , linux-arch , Marc Zyngier , X86 ML , Russell King , clang-built-linux , Ingo Molnar , Kees Cook , Arnd Bergmann , Will Deacon , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Peter Collingbourne , linux-arm-kernel , Andrei Vagin , Stephen Boyd , Nick Desaulniers , LKML , Mark Salyzyn , Paul Burton 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 17, 2020 at 7:38 AM Catalin Marinas wrote: > > On Tue, Mar 17, 2020 at 12:22:12PM +0000, Vincenzo Frascino wrote: > > diff --git a/arch/arm64/kernel/vdso32/vgettimeofday.c b/arch/arm64/kernel/vdso32/vgettimeofday.c > > index 54fc1c2ce93f..91138077b073 100644 > > --- a/arch/arm64/kernel/vdso32/vgettimeofday.c > > +++ b/arch/arm64/kernel/vdso32/vgettimeofday.c > > @@ -8,11 +8,14 @@ > > #include > > #include > > > > +#define VALID_CLOCK_ID(x) \ > > + ((x >= 0) && (x < VDSO_BASES)) > > + > > int __vdso_clock_gettime(clockid_t clock, > > struct old_timespec32 *ts) > > { > > /* The checks below are required for ABI consistency with arm */ > > - if ((u32)ts >= TASK_SIZE_32) > > + if ((u32)ts > UINTPTR_MAX - sizeof(*ts) + 1) > > return -EFAULT; > > > > return __cvdso_clock_gettime32(clock, ts); > > I probably miss something but I can't find the TASK_SIZE check in the > arch/arm/vdso/vgettimeofday.c code. Is this done elsewhere? > Can you not just remove the TASK_SIZE_32 check entirely? If you pass a garbage address to the vDSO, you are quite likely to get SIGSEGV. Why does this particular type of error need special handling? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel