Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1236047imu; Sat, 15 Dec 2018 18:16:50 -0800 (PST) X-Google-Smtp-Source: AFSGD/WZU/3j+Qm3u2v27jI23/gYVFwS9mfBEkH7W5sMNOEAuZ8oL02OP+CvPa+bl4X8mJgeb/w+ X-Received: by 2002:a63:5ec6:: with SMTP id s189mr7582308pgb.357.1544926610707; Sat, 15 Dec 2018 18:16:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544926610; cv=none; d=google.com; s=arc-20160816; b=QAAANsjPzIgk4iWDvdB8jHB4D52x4W2IWQ62wAStuLZ5dGnOO41/EAshR5i0z74t+T BFQ95ANde4APcQwagbPe7/b7DYaLjSlFqVmlbmqFo2dY6ZA3q900Atbj6wEvOQspPCTA MDFSOTr9xA2qjQ5l8qhLEDFnPM2KZprzkiQKtCYO6aYqxT2JC2uDnceZ4OAZF+HaBjre Y7dHT5KZnh2Q69pwJ/7/dGpiTtIfFS+u0ZiKeonnBgtFPN1gUytM7umUpKMofgRZOTkV bjFRwrgGR5dasvXVNpnD/acjfhnxTGRbgpMh4ufySzyShbgf8HsIZ9mefYYK+mvLytOI w9tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=TC7V6xKSWuriLdB/omZ8J3JmMcSz2UntljmLgF4AZVc=; b=rQCWJBMR0Si4jq99VS8zQPlJ78MhN7B9qSKy/WfTepiAu7te48Hxhc9c/fKE46C4jr tYNm67pfpvwPVVmDNCaNcAadHz/Z1m6uCZJfpRFmLi6w+BgWH/R9Aeal/36gdpLA1aNh JPvMY9vd5ip/ZhMSBjwmn/1JPJim/62KTk74+HRTpv9NzMFXeJEbBXmGYLvz9qBALbQs /9Mgra/3kahYsceJjisrM5mgUSj3QOFEDrjFc1g7ormUORm1zeL/vXo4B87WscYQg7QK 0yH8pOvgxrNFSZ+6k1qm6EIuBVj9STUFWi5N+U7GbkdVcCeCBCOyzQ794WqUJn/8lGTp vcEg== 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 f21si7425078pgv.111.2018.12.15.18.16.34; Sat, 15 Dec 2018 18:16:50 -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 S1729681AbeLPCPl (ORCPT + 99 others); Sat, 15 Dec 2018 21:15:41 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:51210 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727227AbeLPCPl (ORCPT ); Sat, 15 Dec 2018 21:15:41 -0500 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23992922AbeLPCPi4P1nj (ORCPT ); Sun, 16 Dec 2018 03:15:38 +0100 Date: Sun, 16 Dec 2018 02:15:38 +0000 (GMT) From: "Maciej W. Rozycki" To: Rich Felker cc: Andy Lutomirski , Linux MIPS Mailing List , LKML , Paul Burton , David Daney , Ralf Baechle , Paul Burton , James Hogan Subject: Re: Fixing MIPS delay slot emulation weakness? In-Reply-To: <20181215225009.GB23599@brightrain.aerifal.cx> Message-ID: References: <20181215225009.GB23599@brightrain.aerifal.cx> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 15 Dec 2018, Rich Felker wrote: > > A possibly nicer way to accomplish more or less the same thing would > > be to allocate the area with _install_special_mapping() and arrange to > > keep a reference to the struct page around. > > > > The really nice but less compatible fix would be to let processes or > > even the whole system opt out by promising not to put anything in FPU > > branch delay slots, of course. > > As I noted on Twitter when Mudge brought this topic back up, there's a > much more compatible, elegant, and safe fix possible that does not > involve any W+X memory. Emulate the delay slot in kernel-space. This > is trivial to do safely for pretty much everything but loads/stores. I think "trivial" is an understatement, you at least need to decode the delay-slot instruction enough to tell privileged and user instructions apart and send SIGILL where appropriate. Some user instructions send exceptions too and you need to handle them accordingly. OTOH, for things like ADDIUPC you need to interpret the instruction anyway, as the value of the PC used for calculation will be wrong except in the original location. > For loads/stores, where you want them to execute with user privilege > level, what you do is compute the effective address in kernel-space, > then return to a fixed instruction in the vdso page that performs a > generic load/store using the register the kernel put the effective > address result in, then restores registers off the stack and jumps to > the branch destination. What about all the odd and especially vendor-specific load/store instructions like ASET, SAA or SWAPW? Would we need to have all the possible encodings provided in the VDSO? Maciej