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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 4C90EC6778A for ; Tue, 3 Jul 2018 08:30:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 44D9424658 for ; Tue, 3 Jul 2018 08:30:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44D9424658 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=de.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754659AbeGCIaL (ORCPT ); Tue, 3 Jul 2018 04:30:11 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56022 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753788AbeGCIaH (ORCPT ); Tue, 3 Jul 2018 04:30:07 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w638SijL141638 for ; Tue, 3 Jul 2018 04:30:07 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0b-001b2d01.pphosted.com with ESMTP id 2k01sbrwc9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 03 Jul 2018 04:30:07 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Jul 2018 09:30:05 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 3 Jul 2018 09:29:58 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w638TvVi38338772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 3 Jul 2018 08:29:57 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4BC9611C04C; Tue, 3 Jul 2018 11:30:23 +0100 (BST) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9773711C052; Tue, 3 Jul 2018 11:30:22 +0100 (BST) Received: from osiris (unknown [9.152.212.90]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 3 Jul 2018 11:30:22 +0100 (BST) Date: Tue, 3 Jul 2018 10:29:55 +0200 From: Heiko Carstens To: Peter Zijlstra Cc: Mathieu Desnoyers , Linus Torvalds , Andy Lutomirski , Thomas Gleixner , linux-kernel , linux-api , "Paul E. McKenney" , Boqun Feng , Dave Watson , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes , michal.simek@xilinx.com, Martin Schwidefsky , Vasily Gorbik Subject: Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs References: <20180702223143.4663-1-mathieu.desnoyers@efficios.com> <825871008.10839.1530573419561.JavaMail.zimbra@efficios.com> <1959930320.10843.1530573742647.JavaMail.zimbra@efficios.com> <8B2E4CEB-3080-4602-8B62-774E400892EB@amacapital.net> <459661281.10865.1530580742205.JavaMail.zimbra@efficios.com> <858886246.10882.1530583291379.JavaMail.zimbra@efficios.com> <1776351430.10902.1530585009519.JavaMail.zimbra@efficios.com> <20180703081449.GT2494@hirez.programming.kicks-ass.net> MIME-Version: 1.0 In-Reply-To: <20180703081449.GT2494@hirez.programming.kicks-ass.net> X-TM-AS-GCONF: 00 x-cbid: 18070308-0020-0000-0000-000002A28749 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18070308-0021-0000-0000-000020EE9D55 Message-Id: <20180703082955.GH3704@osiris> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-03_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030097 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 03, 2018 at 10:14:49AM +0200, Peter Zijlstra wrote: > On Mon, Jul 02, 2018 at 10:30:09PM -0400, Mathieu Desnoyers wrote: > > > Use "get_user()". It works for 64-bit objects too, and it will be > > > atomic in the 32-bit sub-parts on a 32-bit architecture. > > > > Is it really ? Last time we had this discussion, not all architectures > > guaranteed that reading a 64-bit integer would happen in two atomic > > 32-bit sub-parts. This was the main motivation for the LINUX_FIELD_u32_u64() > > macro as it stands today (rather than using a union). > > Just state, as a requirement for supporting rseq, that the arch > {get,put}_user(u64) on 32bit targets must be exactly 2 u32 loads/stores. > > We're piece-wise enabling rseq across architectures anyway, and when the > relevant maintains do this, they can have a look at their > {get,put}_user() implementations and fix them. > > If you rely on get_user(u64) working, that means microblaze is already > broken, but I suppose it already was, since their rseq enablement patch > is extremely dodgy. Michal? s390 uses the mvcos instruction to implement get_user(). That instruction is not defined to be atomic, but may copy bytes piecemeal.. I had the impression that the rseq fields are supposed to be updated within the context of a single thread (user + kernel space). However if another user space thread is allowed to do this as well, then the get_user() approach won't fly on s390. That leaves the question: does it even make sense for a thread to update the rseq structure of a different thread?