Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp930090pxb; Mon, 25 Oct 2021 22:46:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAiuURWNNRSpuIyTDzwcDZFnAdvqgyLDcCM924LE6ouj/AZqgkYHoH+2lBhspY+nvDv17l X-Received: by 2002:a17:90b:3e86:: with SMTP id rj6mr26277163pjb.78.1635227175484; Mon, 25 Oct 2021 22:46:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635227175; cv=none; d=google.com; s=arc-20160816; b=qHbKXeF7fpaIEDBvz4WPMTuh7rf9XDwkX4gySXuplv/DHNXpjJ+hVzh+0bKI9fmLR4 u1jaUL+tHcwvbgzCltvT9aSkzU4JdBIX5c4+FkOeqcUbn33ngcvzCTjQobdRNERyZ73m AuG9+ey/xQkIgyUpOwvK2z6GMzEn/IU87vPfAoWqodL2IdseI3x/M2ttBkeHgd4FJdIW /avtMKNf+ykE4KlTHGGgGftLqU6mFd4ixa/YGyAwFvsXFn9s/z4sTKsjM4fyCp+ItNaf mWaEoZy3vajJnAbWuM9/SgBn6HItSle4s6iCK1azonNerOZ9esH6U/RYlyZJLREE66gC dIrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:cc:to:from :date:references:in-reply-to:message-id:mime-version:user-agent :dkim-signature; bh=ngSDJrKocM8gFuJkhaqJFf/bMhZrd9yaBVDBf8M+n8g=; b=mGQ3RO2TNg4eOTpHDhZt/oMNHeAh6P3fze7YVZ3b+7VsQmNDYh+RShDXQNsO3KFPUY ofp3izSCv/zrttsc44TII+QUl+wsDVRR+g/BjGen2OBT/LhqsgsVKsE5iwoB3TIiAwEd 7GHxE9i+5r/5zVoZ35Hph0UnOFySEeGmn5/LWH3n4U1bYBdyutCPLh90K3u9IYrM3wB4 PXCFXMcBe6W0RDo62trGk/PnBjrmbKT6nY3n/TVJm5LRYRvn4+5hsCB3vuMNL+5FJFkv UTKi+IMJ5fE/RbJv5sUsuAdC927jFrhDxPv8kgoxJ2WovsTtkZGs3r1Xgee1VtlczwIE iNQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lF213LU0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z18si34255342plg.159.2021.10.25.22.46.02; Mon, 25 Oct 2021 22:46:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lF213LU0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232743AbhJZAYY (ORCPT + 99 others); Mon, 25 Oct 2021 20:24:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:44128 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234866AbhJZAYY (ORCPT ); Mon, 25 Oct 2021 20:24:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C9FAD60F92; Tue, 26 Oct 2021 00:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635207721; bh=aByDMtm3gGKxScX4G2tD1RLvvDygFh/kqrDSV2GhxG0=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=lF213LU0mk7Ej8/XpvzNTo7z53XPnsopWYAHXbKFnbwpvROZfLC5ALRQIHTjqyCfp 2fs2vKSqKCVHSiTTBN+9NeiTp+v/GU97jH4UeMRJAS+vdcPNtQ7SipsutcEtG/jQfH vygdAsuJ8+e8ggZFgmO7lY/+TS9ww7baF+UkkMlZECvjHE4x2jxa/T7f4Cu9YeopmH SrGirG0vCOQglQMoOHdI/gvyBnAMQ6ZgnC/wLFcvYWwgRpquTSBBvlNbFkSssMP3oR zpp2ztmtOK1XX4adk2LKPJhKCkutd0//wxRoXTo5NQLbN/IEYk21DzLhjIX2gfLqPA oCXUh4V9N389A== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id A235027C005A; Mon, 25 Oct 2021 20:21:58 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute6.internal (MEProxy); Mon, 25 Oct 2021 20:21:58 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefiedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdelheejjeevhfdutdeggefftdejtdffgeevteehvdfgjeeiveei ueefveeuvdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 48FCC21E0072; Mon, 25 Oct 2021 20:21:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <530952e5-27d7-40b8-ac9a-debc36bb4fdf@www.fastmail.com> In-Reply-To: References: <87y26nmwkb.fsf@disp2133> <20211020174406.17889-10-ebiederm@xmission.com> <875ytkygfj.fsf_-_@disp2133> <4b203254-a333-77b1-0fa9-75c11fabac36@kernel.org> Date: Mon, 25 Oct 2021 17:21:36 -0700 From: "Andy Lutomirski" To: "Linus Torvalds" Cc: "Eric W. Biederman" , "Linux Kernel Mailing List" , linux-arch , "Oleg Nesterov" , "Al Viro" , "Kees Cook" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "the arch/x86 maintainers" , "H. Peter Anvin" Subject: Re: [PATCH v2 10/32] signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved. Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 25, 2021, at 4:45 PM, Linus Torvalds wrote: > On Mon, Oct 25, 2021 at 3:25 PM Andy Lutomirski wrot= e: >> >> I think the result would be nicer if, instead of adding an extra goto, >> you just literally moved all the cleanup under the unsafe_put_user()s >> above them. Unless I missed something, none of the put_user stuff re= ads >> any state that is written by the cleanup code. > > Sure it does: > > memcpy(®s->pt, &vm86->regs32, sizeof(struct pt_regs)); > > is very much part of the cleanup code, and overwrites that regs->pt th= ing. > > Which is exactly what we're writing back to user space in that > unsafe_put_user() thing. D=E2=80=99oh, right. > > That said, thinking more about this, and looking at it again, I take > back my statement that we could just make it a catchable SIGSEGV > instead. > > If we can't write the vm86 state to user space, we will have > fundamentally lost it, and while it's not fatal to the kernel, and > while we've recovered the original 32-bit state, it's not something > that user space can sanely recover from because the register state at > the end of the vm86 work has now been irrecoverably thrown away. There=E2=80=99s =E2=80=9Crecoverable=E2=80=9D and there=E2=80=99s =E2=80= =9Crecoverable=E2=80=9D. Sure, the vm86 state is gone, but the process = is getting a signal that doesn=E2=80=99t indicate that one can freely re= turn and carry on as if nothing happened. But one can catch the signal = and go on to do something else. > > So I think Eric's patch is fine. Me too. > > Except, as mentioned as part of the other patch, the "force_sigsegv()" > conversion to use "force_fatal_sig()" was broken, because that > function wasn't actually fatal at all. > > Linus