From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) by sourceware.org (Postfix) with ESMTPS id 638213858D20 for ; Wed, 31 May 2023 18:23:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 638213858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1a2188fdf17so81199fac.0 for ; Wed, 31 May 2023 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685557437; x=1688149437; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wEdMi0o3aO7AB338zQPygT0cBdMmq8aKtGKuzA3XoLk=; b=NpFTsG6LxeUvEm0odBQl8R5RFecOvCXOIpSkVlXnQE472Q7gjC50DIdrIiYZqddG+5 VeZVcjN6Le2zIs/pqopEhzhIts9cpLc2QSeGxIaudv+g2LKBLiKqrkp7KmjPe+wH5WL+ X8/6u3rczM3Og84ycvGfSL1at56aAdrrwWbvnjrA8oZsdYbIjch5z7E7U0Mz0r/VxRBB Wr7Joo4bKmS1ldWAA8Yxpp6uEzjDN3pbLg35GHYq92NnkSsZzA2qaYmha9Q4DVfTQtKR WRZgnV7GxBjD+dpT19hIErRqSbTkhgeOKu7Tkd4C3S7fD+s2jd+Px9WhgsL/dGexW2Jj yUpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685557437; x=1688149437; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wEdMi0o3aO7AB338zQPygT0cBdMmq8aKtGKuzA3XoLk=; b=B8rC+X7QmQdyKcqiGqupeHfiDbbCTEWc4sRBhk6Iz8zOwhlvo00ENza2KOINfDYLyh O3z86ghoFNUcdfUJfMKPDcEstqLR08uJo0FGTsgfwtv6Mirlp7DVGA44j47uU5tOAQfY ChhSgkMh6sxzRvjM4A9ncFT3NzmkXfz/cXexMFfBY62V1NHPE3UMImEl8XHVedT24lF/ 4UM0DOpn0KHLNsxTDVrymaUDIu8wK2fSK4NCrFLo39eTWu2SFZqG/qDabUdPEbMojxvm 2eTcjslstxIQ2T6FXLogCuNe6lXtjBGOSyLmyTAPsdD5x5Gu5wlBLV0SjrCOWxgAPnML ZAUA== X-Gm-Message-State: AC+VfDz1d821cyMwU9kNkS2JmbTmNkPoHN/5ETKVAog+G4hqXV/n2PWF e3DUckvdMexbsAwKDK3s2hiQ45JHbZGsnGBuYTFSlKW6 X-Google-Smtp-Source: ACHHUZ570h8wRY+rc610NeY25OKCcuQ+vm8Z+t+GUqOr0pkh0AGOGPO1vIvoL7a8RHg4Pd1t3JQioi1d509O/T22nAg= X-Received: by 2002:a05:6870:c803:b0:192:cb3d:c069 with SMTP id ee3-20020a056870c80300b00192cb3dc069mr3444969oab.2.1685557437606; Wed, 31 May 2023 11:23:57 -0700 (PDT) MIME-Version: 1.0 References: <20230424150353.1469397-1-josimmon@redhat.com> <20230424150353.1469397-2-josimmon@redhat.com> <20230525180743.GN176347@oak> <877csvk1zt.fsf@oldenburg.str.redhat.com> <20230526125947.GP176347@oak> <87sfbeunxo.fsf@oldenburg.str.redhat.com> In-Reply-To: <87sfbeunxo.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Wed, 31 May 2023 13:23:44 -0500 Message-ID: Subject: Re: [PATCH v6 1/3] x86_64: Set the syscall register right before doing the syscall. To: Florian Weimer Cc: Joe Simmons-Talbott , Noah Goldstein via Libc-alpha Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, May 30, 2023 at 5:13=E2=80=AFAM Florian Weimer = wrote: > > * Noah Goldstein: > > > On Fri, May 26, 2023 at 5:59=E2=80=AFAM Joe Simmons-Talbott wrote: > >> > >> On Fri, May 26, 2023 at 09:04:06AM +0200, Florian Weimer wrote: > >> > * Noah Goldstein via Libc-alpha: > >> > > >> > > I'm minorly opposed to this patch. Even if GLIBC guarantees all > >> > > syscalls will set the number the instruction before, that's no gua= rantee > >> > > for the entire program. Furthermore in the event of: > >> > > `movl $VAL, %eax; syscall` > >> > > It's still not safe to *always* assume that `VAL` correspond to th= e > >> > > syscall number as a jump (direct or indirect) could still go betwe= en > >> > > the instructions (i.e there is no guarantee in the assembly that t= he > >> > > `mov` dominates the `syscall). > >> > > So at the end of the day, we are bloating the library without, AFA= ICT, > >> > > providing any real guarantee. Maybe I'm missing something? > >> > > >> > Joe, is there a size change to libc.so.6 as the result of this chang= e? > >> > >> No, the size is the same with and with out this patchset on x86_64. > >> > > There aren't many syscalls so it's only a minor cost (hence the only > > minor opposition), but I don't see the value this provides given that i= t > > still won't be safe to assume the syscall number is always set the > > instruction beforehand for any robust purpose. So it still feels like > > why take any cost at all? > > I think there is any run-time cost at all, only the increased source > complexity. > > It's much easier to change glibc than to add full register tracking to a > the static analysis tool that discovers system calls in the disassembly. > Is the aim only to verify libc.so or to verify arbitrary binaries? If the former then sure I guess we know we only use the syscall wrapper so this may help (more on that), but if it's arbitrary binaries there is no guarantee they are using the GLIBC syscall wrapper for their syscalls. If it really is just GLIBC then this change seems unnecessary. Even if there can be separation between setting rax and the syscall, the way we have the wrappers setup we know there will always be a dominating write to rax with the syscall number so would rather see the case where that isn't trivial to find as a motivator first. Or we could just do source code level analysis as we will always have the syscall number in macro invocation. > Thanks, > Florian >