Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <148522e4-a4ec-a35b-df25-e04eeb5f51c4@intel.com>
Date:   Fri, 1 Sep 2023 15:19:17 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.0
Subject: Re: [PATCH] selftests/x86: Update map_shadow_stack syscall nr
Content-Language: en-US
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "Lutomirski, Andy" <luto@kernel.org>,
        "bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC:     "broonie@kernel.org" <broonie@kernel.org>
References: <20230901181652.2583861-1-rick.p.edgecombe@intel.com>
 <e2ae1d89-9abf-338e-e56a-dc4be19b9bfc@intel.com>
 <b92afa6dbd074409095e525204d538f451ee4823.camel@intel.com>
From:   Sohil Mehta <sohil.mehta@intel.com>
In-Reply-To: <b92afa6dbd074409095e525204d538f451ee4823.camel@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dXdJWEh4b0VaTmxhQmN6TDByaTZCMnJSbkFoQ0FKL1lwM3pzT0k5V1AzdmRn?=
 =?utf-8?B?SjFnakhFMDRianlrOEZqT3hkWWxmcnN2UlBJY2FSblFoUGIrN1RpVFhuTUtQ?=
 =?utf-8?B?c3dCQndxRDlZeFk4U2ZySjVQZWJCcXcxMzhCK0VSYmpWdlhGK2p5UGJSbHV5?=
 =?utf-8?B?SFBRQ2pRSkhLUi9MdXMzYnYyVmV0SUpQZ1I0eVEzRUVtNGN5am9MQ3k0RVh4?=
 =?utf-8?B?Rzg2K21RWFBxenlJNVpXQzVwanR0R1JFOHQ0VnhrZjBFS0dIOUgySTBYMTVQ?=
 =?utf-8?B?eXJWNzc1NmdkUTA3aFgzT21nbHV5Q204eDJpaFFCYXpDZk5kNkQrM2t2WlY0?=
 =?utf-8?B?NHg5RU5XZDdxOFc4cmo5MXdwL21CaWJrOU9jUWxTUTdCbjdTRkdiQnFrOHNh?=
 =?utf-8?B?Z00wYjdpQTZVL1dEaS9JNURKeFkvb0RvK0ttdXZqWTZtTGd5RjZMdTJkVWtG?=
 =?utf-8?B?ejZualB6cmlpejRDRENheTVxM0pNTHp0M2prQzdrcGErYmR6WmlHTEEzc05K?=
 =?utf-8?B?bThyQnR2NHpNNGhHWGFJQlo3a3F2OTBnS3RNQUdSblZPQjhncmoxWHJGUFlI?=
 =?utf-8?B?anpPSTJTcnVHS25iVnVLRk9URFJaTUFid0w3WEtwbzB4Z0E4N2JzWUxmRnhO?=
 =?utf-8?B?Rnh1MTBPYUtxNXBqZDNmU1NRVm5LVE5WdVBjMXRCUXNCYlo0S0huSHVBbmt4?=
 =?utf-8?B?K2FnZkhpSXpMdTBtOWN6K2tDeEpVTUdRcmplczJMSjlGVVAyOGxIVko2YWRT?=
 =?utf-8?B?RVEwVGVFV1JkV2VDZnZpejhFeElubkFrMmN0ald4YmFVSU5ydXlDMFdleUtw?=
 =?utf-8?B?azhoTmJNdFFWbyswN0Eyc0tUd1ZSTXZyU2gxbjNRL1poQVp6eTR3VzFMRHlP?=
 =?utf-8?B?RTJhcUllOUhvUWUwdkxkUUNXSjJ0WWxodFhMU2tDdDgvQUZhSUJNdDUySEM2?=
 =?utf-8?B?UWFWYzNFODhGMU4xWGd5UGFseisyY0lYRXp3dnZCSG9LSVh4SkdhTk9LTFcx?=
 =?utf-8?B?QnpPNmY1Y3Fjb1JQTTNGZnB5K01VUkxaZnZ3YThSdFU2RVdVa0R3clcwemFK?=
 =?utf-8?B?K0ZwK2VOVTBnN1FHTEJvazBtK0pJRFMxMjh1cUtHd2RuOFptc29yN09DbzFQ?=
 =?utf-8?B?TVlLaUwvZVNoSTcwOFNSeVFlc1RJN2hmYno2aE40L0c0Yko5TXUya283emgz?=
 =?utf-8?B?b096THpYelEwdnR2dDUySDhYeUlwNzlOaVhDTmJ0YmcwNnBUeEdNRHBtSGdG?=
 =?utf-8?B?SGFmVmRPQUgyZGdqSUNrU1pSUEtSSVlZN3oyNXA1ODUyT1NpbjFRbUI0ZVFC?=
 =?utf-8?B?eVQ2dWpPNkFocm1BcldSZTNZSXJrRkVKNWxaeVdjREt3aUY4UXpTR2VEeC9j?=
 =?utf-8?B?WjNydjF3UmZCTFd0NUtyazMvck4reVc4YkttMDVvV3FYWHArTE04bkQ0QnJw?=
 =?utf-8?B?VFZpY2xNRk9YQ3VUQWZwNm0yaE15Ym9FbDVyMlFMeGZpYkNtMS9FdHZMWWdQ?=
 =?utf-8?B?TzZQQ2plOVJ5em1VdTBLaEZSVW92cmVNSm52Z0lvSzRabHVxZVZjOTQ1NzM1?=
 =?utf-8?B?UHd4dmxVQm5YcnpRR0lMZjQ3eVVtdUIzL3hqUG1qVHM3VWRzVG54Ym9ZSTBY?=
 =?utf-8?B?ZmowRUJDVHNoQWVpeUpPcHlQdFhYMEZvd1hzc3dINjZXdXJ5NEIxVGY4THpQ?=
 =?utf-8?B?N1p4U1EwVStYRVJlbXNNa0hEZXNwTHAydVNvaFkvTEhBZDZybUdDVmdDMXV6?=
 =?utf-8?B?WEUrNmtGUXJZYTdyVzFtK0w1R2p0alVvVG5uM1FyRXJLVUFuajlUbGJ4UDFy?=
 =?utf-8?B?ZTR5MzQxM3BXN2JXQTdYaERnOVNYM3FGdmVCSUZRdTJEWStmdUM1UHliYW1v?=
 =?utf-8?B?Zy80OEJzQkJwN1ZzRkZDdGJQeEJoYnJIWm9Jd1FhTU5hMllweEpxV0Q0UVdL?=
 =?utf-8?B?YUZRci9xNEI4bTFXZkV1Q09YQ3F3blVmRVBnZDJJR09pZEZENGg2K216WHE2?=
 =?utf-8?B?TnczdkYwQmZ4b0tpcXhFWmZ2SDFaZ0ZCQzlCbnFIYkFMeTNhMUU0eUVYOTlL?=
 =?utf-8?B?M1dBNUg3bmR6MHpPdW16dmxTR1dMLzd1V1JXMi9aaFFaUkF0UERWVzFEbzI5?=
 =?utf-8?Q?avu4uDjESO7UMt9B/ejUfZFg4?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 7abcbfb2-990a-464a-eca1-08dbab397c6d
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2023 22:19:19.3456
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: kwWweHX6yC+mVI+z7sR4JXzM/weum5s059fadDPv0RnYlEn8pyrst0MWfZHfyAzva61QvuCkselxdDrlkMg9yA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB7182
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/1/2023 1:35 PM, Edgecombe, Rick P wrote:
> On Fri, 2023-09-01 at 12:33 -0700, Sohil Mehta wrote:

>> I am wondering why a definition for __NR_map_shadow_stack is
>> missing in include/uapi/asm-generic/unistd.h?
>> 
>> Wouldn't this mean that even if someone were to install the
>> headers they still wouldn't get the syscall number definition. Am I
>> missing something?
> 
> There is some autogeneration that happens from the .tbl files.

Hmm.. I wasn't aware of this auto-generation. The last few system calls
additions have all updated the unistd.h file manually to add the
__NR_foo defines. So I assumed that's what gets included in the header
packages and eventually gets used by userspace in some form. But maybe
x86 headers might be built differently. I need to educate myself on this.

> But maybe also this whole duplicate defines thing is questionable.
> 

Yeah, having 2 defines is a bit annoying but as mentioned in the link it
makes it easier for someone to run selftests so it's probably worth the
effort. Also since syscall numbers typically never change it is just a
one time thing and not a big maintenance burden :)

FWIW, I see these syscall nr defines all across the selftests (io_uring,
powerpc/pkeys, seccomp, etc).

> 
>>
>> Apart from this patch, I think we also need something like commit
>> 78252deb023c ("arch: Register fchmodat2, usually as syscall 452") to
>> reserve the 453 syscall number for the rest of the architectures.
>>
>> Should I send one out if you don't have something prepared already?
> 
> Originally there were no other shadow stack features, and so it was
> maybe going to be an x86-only syscall. I followed in the footsteps of 
> the secret mem syscall, but that one seems to have grown some similar
> reservation comments since then. It probably makes more sense for that
> one though, since it's sort of a generic functionality. An analogous
> x86 specific syscall would maybe be modify_ldt, which doesn't really
> have reservations.
> 
> But now we also have arm that plans to use it. So maybe it is worth
> trying to match syscall numbers? I could imagine scenarios where it
> could be useful. And I guess there is also the scenario where a generic
> type syscall is added, but only implemented on non-shadow stack
> architectures. So then when it makes it's way around, it can't match. I
> hadn't thought about it before, so just thinking it through...
> 

My suggestion is originating from the belief that at somepoint the
community decided that all *new* system call numbers would be the
consistent across architectures (except alpha). So that would mean
syscall number 453 has to be reserved on others even if it is an
x86-only syscall.

If we don't do this, and let say a generic sys_foo comes along which
uses the next available syscall number 453 on other archs, it would lead
to an inconsistency because 453 it is already used up on x86.

My memory of this is a bit hazy from my implementation of User
Interrupts more than a couple of years back. Also, I couldn't find any
handy documentation to support my belief. I'll try to dig more.

Sohil