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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 5ED20C433ED for ; Wed, 28 Apr 2021 00:05:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D75561401 for ; Wed, 28 Apr 2021 00:05:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236782AbhD1AGY (ORCPT ); Tue, 27 Apr 2021 20:06:24 -0400 Received: from terminus.zytor.com ([198.137.202.136]:41307 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235653AbhD1AGX (ORCPT ); Tue, 27 Apr 2021 20:06:23 -0400 Received: from tazenda.hos.anvin.org ([IPv6:2601:646:8602:8be0:7285:c2ff:fefb:fd4]) (authenticated bits=0) by mail.zytor.com (8.16.1/8.15.2) with ESMTPSA id 13S05LvS952011 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Apr 2021 17:05:23 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 13S05LvS952011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2021032801; t=1619568327; bh=tNUNXGHMIILCFNhZ+vmwXye4RudA6BzWEic674v0qHE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FUD2HzcYBwpmlty4glmomzJ8xM6793gFMKME7usQFqRBakyDxw+rZ5sNNgKzHDm4E GqBvSM45OzjPdNXP8jfybkz1w/vZYZgWZLzsDQzxZsj3HUmbj7SN08RWQJGzN465b5 TeBR1jg9iwuktfvsHT+WQXY+1ZF+8aHE/bD8H2vhpc+7HzD6wbOHFJbjBhV40mzqms BY0vJZaY1skIOkPXXju/3mOwJZEsbWl82E3bLoodKXs0EtVTyWyxcOKmynvkALNQj4 JgE4DQUkT4jfaAdB9mc7yj5DI0wFR+tideeTuzr815pFs2hRfAKFBBAHZosdxLvXyQ MjuobgbD3PeJQ== Subject: Re: pt_regs->ax == -ENOSYS To: Andy Lutomirski Cc: Linus Torvalds , Ingo Molnar , Thomas Gleixner , Andrew Lutomirski , Borislav Petkov , LKML , Oleg Nesterov , Kees Cook , Will Drewry References: <06a5e088-b0e6-c65e-73e6-edc740aa4256@zytor.com> From: "H. Peter Anvin" Message-ID: <3626eea3-524e-4dbd-78dd-9ade5a346a08@zytor.com> Date: Tue, 27 Apr 2021 17:05:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/27/21 4:23 PM, Andy Lutomirski wrote: > > I much prefer the model of saying that the bits that make sense for > the syscall type (all 64 for 64-bit SYSCALL and the low 32 for > everything else) are all valid. This way there are no weird reserved > bits, no weird ptrace() interactions, etc. I'm a tiny bit concerned > that this would result in a backwards compatibility issue, but not > very. This would involve changing syscall_get_nr(), but that doesn't > seem so bad. The biggest problem is that seccomp hardcoded syscall > nrs to 32 bit. > > An alternative would be to declare that we always truncate to 32 bits, > except that 64-bit SYSCALL with high bits set is an error and results > in ENOSYS. The ptrace interaction there is potentially nasty. > > Basically, all choices here kind of suck, and I haven't done a real > analysis of all the issues... > OK, I really don't understand this. The *current* way of doing it causes a bunch of ugly corner conditions, including in ptrace, which this would get rid of. It isn't any different than passing any other argument which is an int -- in fact we have this whole machinery to deal with that subcase. If it makes you feel better, we could even sign-extend the value in orig_ax, but that seems unnecessary and a bit broken to me. -hpa