Received: by 10.192.165.148 with SMTP id m20csp3213198imm; Mon, 23 Apr 2018 02:37:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/4lmgmZYI/vd0UWctS44bIh6ltXhz7UChAsWL1dEET5OViJEcZ+DXViwos9+Ah1RrNAN9T X-Received: by 2002:a17:902:aa90:: with SMTP id d16-v6mr20123510plr.189.1524476262073; Mon, 23 Apr 2018 02:37:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524476262; cv=none; d=google.com; s=arc-20160816; b=ldj29BAbjc/BrrBZ2cLpOQBveQKHCQqfbJgRrXc9HtXtaaQ5e27hNioSPa1L/F6Ncu w7nMZ5D6CUo8w6SiEgCtVOsSO5wbod8D491Rx5HJ7UjzO8eF//Y3LyWUlIXzAu/wkjca FNzK3Y/IadUov+gpld9V4mDCIHwR4ufq0ZZT6zTCndzRpHlxDy7tph49xptnAGJhjJv0 KYHxjEW2VWcuyVvM4VJgBBm+37/m8aMd8mr+gsUk4y930qioSuoLllL7E/sV7uoh1eOv ibdEfZHzqNugMHhh2+dN5mXbsvVsTX3s+YRb4e9k5TAVIFjQJKfecdlwDpxefuKH78LT dgGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=6PCM6M3egyyahRuWHo4KUvQAiFWK6lsPWMRkAYZk5+c=; b=o9DsDKidZ/YvsKND6Hed7Vf5iM2LIajcsoboPORHYKCvCRxdFvy5Vu147VpoFa7Z4E Ooz9O7zDKi9kR36eqWf9kzYDw0E83yIG89WpLrVciLeTkyY+Qnwcj+et+qCpj6wM7OoV 1mWHKJZfk6JhYnRFlgLk7vVSsvNH6nsCTe/erlp86rhT+JqSIaER6wGWRJdeGe8Vv8ou YKabCMII0pKlSZDnyUn9qidN7LwOqo8sGWB+LqMXukGN4fZJFdsO784FrWnOxM07DOBq /pCVRoVCq4grJGaasYnsT8wYoTOgWSdkcz0mQwvU/QR5ksOBZ4Nz8O6WUuGV01Q0hPX8 KsZg== 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 b61-v6si11404588plc.500.2018.04.23.02.37.28; Mon, 23 Apr 2018 02:37:42 -0700 (PDT) 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 S1754382AbeDWJgZ (ORCPT + 99 others); Mon, 23 Apr 2018 05:36:25 -0400 Received: from 9pmail.ess.barracuda.com ([64.235.154.210]:60521 "EHLO 9pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754235AbeDWJgX (ORCPT ); Mon, 23 Apr 2018 05:36:23 -0400 Received: from mipsdag02.mipstec.com (mail2.mips.com [12.201.5.32]) by mx1404.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NO); Mon, 23 Apr 2018 09:36:08 +0000 Received: from [192.168.155.41] (192.168.155.41) by mipsdag02.mipstec.com (10.20.40.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Mon, 23 Apr 2018 02:36:27 -0700 Subject: Re: [PATCH 3.18 45/52] MIPS: memset.S: Fix clobber of v1 in last_fixup To: Heiher , Greg Kroah-Hartman CC: , , James Hogan , Ralf Baechle , References: <20180422135315.254787616@linuxfoundation.org> <20180422135317.436671003@linuxfoundation.org> From: Matt Redfearn Message-ID: <8293aba6-81fa-6552-529e-030cc41c705f@mips.com> Date: Mon, 23 Apr 2018 10:36:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.155.41] X-ClientProxiedBy: mipsdag02.mipstec.com (10.20.40.47) To mipsdag02.mipstec.com (10.20.40.47) X-BESS-ID: 1524476168-382908-3433-257490-1 X-BESS-VER: 2018.5-r1804181636 X-BESS-Apparent-Source-IP: 12.201.5.32 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.192283 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/04/18 08:16, Heiher wrote: > Hi, > > IIRC, The v1 is a temporary register, value is not preserved across > function calls. v1 is conventionally used for a function return value and as such can be changed by called functions. However, bzero is called from inline assembly and v1 is not in the clobbers list https://elixir.bootlin.com/linux/v4.17-rc1/source/arch/mips/include/asm/uaccess.h#L652 So the calling function does not expect that register to have been used and can legitimately expect its value to remain after the function call, which without this patch, it does not - as demonstrated by the test code. Thanks, Matt > > I don't see any functions that generated by compiler to restore values > of v1 after clobbered it. > > On Sun, Apr 22, 2018 at 9:54 PM, Greg Kroah-Hartman > wrote: >> 3.18-stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Matt Redfearn >> >> commit c96eebf07692e53bf4dd5987510d8b550e793598 upstream. >> >> The label .Llast_fixup\@ is jumped to on page fault within the final >> byte set loop of memset (on < MIPSR6 architectures). For some reason, in >> this fault handler, the v1 register is randomly set to a2 & STORMASK. >> This clobbers v1 for the calling function. This can be observed with the >> following test code: >> >> static int __init __attribute__((optimize("O0"))) test_clear_user(void) >> { >> register int t asm("v1"); >> char *test; >> int j, k; >> >> pr_info("\n\n\nTesting clear_user\n"); >> test = vmalloc(PAGE_SIZE); >> >> for (j = 256; j < 512; j++) { >> t = 0xa5a5a5a5; >> if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) { >> pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, j, k); >> } >> if (t != 0xa5a5a5a5) { >> pr_err("v1 was clobbered to 0x%x!\n", t); >> } >> } >> >> return 0; >> } >> late_initcall(test_clear_user); >> >> Which demonstrates that v1 is indeed clobbered (MIPS64): >> >> Testing clear_user >> v1 was clobbered to 0x1! >> v1 was clobbered to 0x2! >> v1 was clobbered to 0x3! >> v1 was clobbered to 0x4! >> v1 was clobbered to 0x5! >> v1 was clobbered to 0x6! >> v1 was clobbered to 0x7! >> >> Since the number of bytes that could not be set is already contained in >> a2, the andi placing a value in v1 is not necessary and actively >> harmful in clobbering v1. >> >> Reported-by: James Hogan >> Signed-off-by: Matt Redfearn >> Cc: Ralf Baechle >> Cc: linux-mips@linux-mips.org >> Cc: stable@vger.kernel.org >> Patchwork: https://patchwork.linux-mips.org/patch/19109/ >> Signed-off-by: James Hogan >> Signed-off-by: Greg Kroah-Hartman >> >> --- >> arch/mips/lib/memset.S | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> --- a/arch/mips/lib/memset.S >> +++ b/arch/mips/lib/memset.S >> @@ -210,7 +210,7 @@ >> >> .Llast_fixup\@: >> jr ra >> - andi v1, a2, STORMASK >> + nop >> >> .Lsmall_fixup\@: >> PTR_SUBU a2, t1, a0 >> >> >> > > >