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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31508C433FE for ; Tue, 26 Oct 2021 00:22:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E55960EFE for ; Tue, 26 Oct 2021 00:22:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235259AbhJZAYZ (ORCPT ); Mon, 25 Oct 2021 20:24:25 -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