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=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 6BF28C433DF for ; Thu, 27 Aug 2020 19:39:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C05420714 for ; Thu, 27 Aug 2020 19:39:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OdHs4L9U" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726243AbgH0TjQ (ORCPT ); Thu, 27 Aug 2020 15:39:16 -0400 Received: from mail-il1-f193.google.com ([209.85.166.193]:44211 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726120AbgH0TjP (ORCPT ); Thu, 27 Aug 2020 15:39:15 -0400 Received: by mail-il1-f193.google.com with SMTP id j9so5878685ilc.11; Thu, 27 Aug 2020 12:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NOB1L9Z2LmUKGGeFyj84nON/LDrM3AY4psgNY87vymw=; b=OdHs4L9Ujfp3PQmb2CnawHfr6pib3Mou2W4IqK9gK/q74g/vSmAY5IibNlwwPXjL0b 5NGlUNmZ6k0DF03WOSrOLhFPmdu4PzcoquTboVrApL8RmYXVgXNZKgzeq+f4YEDLMDof Su+ub46724WODtxB8KZL/mIuhurVshHcwRUK9T2XIgcbvO4O/tfNIgdbT1vkbDS4fdgw ekxI471ss7zqC1dsg9I9qcROP5g5MM+Zd9qCmotFs4sceCnUzxkMZnQbkZ8sM8X1hUmH oiHWjpk4l9W6NoyVS8q3C5saAs2d36saw/zDSuhCQVB8b95clOQwGeHMRd2NyEVAtBp/ 4BPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NOB1L9Z2LmUKGGeFyj84nON/LDrM3AY4psgNY87vymw=; b=QOoPcCABVccNguFA4Eo5W9IrN/Ej3/nhNQJcj48hd8yfO/hEAe282RkrdFRQJYDnBu Y5vyuRbCYwJRit1Z+IglW4NiWzcDd9j3LRXYUA65tRIXn58JIhUahAloGy+R2nFMi8Wz wa7P5WH6+5Uf4f1VlEOBtiAoruHSJjUuhJ4/hDbV34jpmcH/L46N1Xan5fhWMa9eKhJT qNkGbUP8BDtjOu4zxjcQZMc+yxUfuNRtdeN4ambChcMZiq3sw38fc9A/NDTfLvp2bmQF wBlKDpzqL0grFjJxTT9zzw/50UdbM9ezXf7Sd7dz03u5Bhyc4yEkp3GO4XX6pzouzbZf VkNQ== X-Gm-Message-State: AOAM532U/shoH0cTGRHR6lzIXGmyigPmVIRFfYOmjS1uljA1/9/OPdqN qe5yefnRXKV+Lh3p6ZNzlF2bC70iSq/dvIlaFOk= X-Google-Smtp-Source: ABdhPJz3AFlP3Kd2dCES2TE657Fj/aB8MwwtB77fXJN6/mzwzKCWE10R5tOLPhiUJGyp0tLFgg6gBnnGIoHe5BhRZaY= X-Received: by 2002:a92:5e4c:: with SMTP id s73mr18025364ilb.151.1598557093725; Thu, 27 Aug 2020 12:38:13 -0700 (PDT) MIME-Version: 1.0 References: <4BDFD364-798C-4537-A88E-F94F101F524B@amacapital.net> In-Reply-To: <4BDFD364-798C-4537-A88E-F94F101F524B@amacapital.net> From: "H.J. Lu" Date: Thu, 27 Aug 2020 12:37:37 -0700 Message-ID: Subject: Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack To: Andy Lutomirski Cc: "Yu, Yu-cheng" , Florian Weimer , Dave Martin , Dave Hansen , Andy Lutomirski , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Weijiang Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Thu, Aug 27, 2020 at 11:56 AM Andy Lutomirski wrot= e: > > > > > On Aug 27, 2020, at 11:13 AM, Yu, Yu-cheng wrot= e: > > > > =EF=BB=BFOn 8/27/2020 6:36 AM, Florian Weimer wrote: > >> * H. J. Lu: > >>>> On Thu, Aug 27, 2020 at 6:19 AM Florian Weimer = wrote: > >>>>> > >>>>> * Dave Martin: > >>>>> > >>>>>> You're right that this has implications: for i386, libc probably p= ulls > >>>>>> more arguments off the stack than are really there in some situati= ons. > >>>>>> This isn't a new problem though. There are already generic prctls= with > >>>>>> fewer than 4 args that are used on x86. > >>>>> > >>>>> As originally posted, glibc prctl would have to know that it has to= pull > >>>>> an u64 argument off the argument list for ARCH_X86_CET_DISABLE. Bu= t > >>>>> then the u64 argument is a problem for arch_prctl as well. > >>>>> > >>> > >>> Argument of ARCH_X86_CET_DISABLE is int and passed in register. > >> The commit message and the C source say otherwise, I think (not sure > >> about the C source, not a kernel hacker). > > > > H.J. Lu suggested that we fix x86 arch_prctl() to take four arguments, = and then keep MMAP_SHSTK as an arch_prctl(). Because now the map flags and= size are all in registers, this also solves problems being pointed out ear= lier. Without a wrapper, the shadow stack mmap call (from user space) will= be: > > > > syscall(_NR_arch_prctl, ARCH_X86_CET_MMAP_SHSTK, size, MAP_32BIT). > > I admit I don=E2=80=99t see a show stopping technical reason we can=E2=80= =99t add arguments to an existing syscall, but I=E2=80=99m pretty sure it= =E2=80=99s unprecedented, and it doesn=E2=80=99t seem like a good idea. prctl prototype is: extern int prctl (int __option, ...) and implemented in kernel as: int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5); Not all prctl operations take all 5 arguments. It also applies to arch_prctl. It is quite normal for different operations of arch_prctl to take different numbers of arguments. --=20 H.J.