From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 6C481385700A for ; Thu, 14 Jan 2021 16:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6C481385700A Received: by mail-qt1-x82e.google.com with SMTP id h19so3893588qtq.13 for ; Thu, 14 Jan 2021 08:36:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cCQy47Hx17zlVg38ps+guwH7+RKjSJpqo8tAzTTQw70=; b=PG7SrtezKWyib78naevcgNZISY84+zbm1uXw4G19ShCkF+rKh7KAo2KJINtnt68I/N 8y7oA9bvTY4/8vUKF1vuDk0+3nGx12db8szHPgnhk+JOxOPy7m6UrfEV6sUoHc3DVwjM /+Ai2tysCW7w1JELYymCLje5rg6bL0eslj+3OykZQUcimqymB16NObJuXTOPEApcpgHj IjGniW0m7HiXoU2CEcGEhUmGRbkW0xAx3vaakJNdjDcA9KB4siKwzGleMt+Y5WMbUYbm XOPgvGN3oWVBFIicQRwjLUK6mIluFD5b2nkQHa7p8c/OgNvq3dBbCAXtYgyp08QwWbvX OxKw== X-Gm-Message-State: AOAM531+hfc61hhALn2LbzLAPxuNpMNKaJrzRSiUAZJ2cIFsbgbhPNCH IQDV0G87TpTXchYUIXcLZqguQ6OdBoWH5w== X-Google-Smtp-Source: ABdhPJxUR5d2S+YZHbEVSrY0s/58LZ9XbX4zyWiqIRqBKbs8XEGqEtsJ1vInHIlEH9gbtAgpMMiJfQ== X-Received: by 2002:ac8:678f:: with SMTP id b15mr2562751qtp.209.1610642172777; Thu, 14 Jan 2021 08:36:12 -0800 (PST) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id h75sm3174494qke.130.2021.01.14.08.36.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Jan 2021 08:36:12 -0800 (PST) To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <87pn27ranx.fsf@oldenburg2.str.redhat.com> <442773f2-7744-aa65-e162-0805a9184811@linaro.org> <877dofr3bq.fsf@oldenburg2.str.redhat.com> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: Should legacy fstat (via __fxstat) and fstat@GLIBC_2.33 call the same syscall? Message-ID: <724b6e18-1c79-8fae-86b1-50f8787b856b@linaro.org> Date: Thu, 14 Jan 2021 13:36:09 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <877dofr3bq.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 16:36:15 -0000 On 14/01/2021 11:38, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 14/01/2021 09:00, Florian Weimer via Libc-alpha wrote: >>> Currently, __fxstat may get mapped to the fstat system call, while fstat >>> goes to fstatat. This makes sandboxing issues less obvious to debug: >>> >>> >>> >>> Should we change this before the release? And if yes, in what >>> direction? >> >> Implementing fstat/lstat/stat through fstatat does really simplify >> the code at *lot* for some architectures. And on others and on some >> ABI (32-bit with 64-bit time_t), it would require to use the same >> syscall anyway (statx). >> >> I don't really see any gain in adding back this complexity back on >> stat calls, specially with y2038 support requirement. > > But we currently have this code for the x*stat interfaces. For example, > in sysdeps/unix/sysv/linux/xstat.c: > > __xstat (int vers, const char *name, struct stat *buf) > { > switch (vers) > { > case _STAT_VER_KERNEL: > { > # if STAT_IS_KERNEL_STAT > /* New kABIs which uses generic pre 64-bit time Linux ABI, > e.g. csky, nios2 */ > int r = INLINE_SYSCALL_CALL (fstatat64, AT_FDCWD, name, buf, 0); > return r ?: stat_overflow (buf); > # else > /* Old kABIs with old non-LFS support, e.g. arm, i386, hppa, m68k, > microblaze, s390, sh, powerpc, and sparc32. */ > return INLINE_SYSCALL_CALL (stat, name, buf); > # endif > } > > default: > { > # if STAT_IS_KERNEL_STAT > return INLINE_SYSCALL_ERROR_RETURN_VALUE (EINVAL); > # else > struct stat64 buf64; > int r = INLINE_SYSCALL_CALL (stat64, name, &buf64); > return r ?: __xstat32_conv (vers, &buf64, buf); > #endif > } > } > } For instance for !XSTAT_IS_XSTAT64 (xstat.c) we have that _STAT_VER is set for _STAT_VER_LINUX on arm and _STAT_VER_KERNEL on csky. It means that we will need to do something like: #if STAT_IS_KERNEL_STAT /* csky, nios2 */ int r = INLINE_SYSCALL_CALL (fstatat64, AT_FDCWD, name, buf, 0); return r ?: stat_overflow (buf); #else /* Old kABIs with old non-LFS support, e.g. arm, i386, hppa, m68k, microblaze, s390, sh, powerpc, and sparc32. */ struct stat64 buf64; int r = INLINE_SYSCALL_CALL (stat64, name, &buf64); return r ?: __xstat32_conv (vers, &buf64, buf); #endif And it would have something similar to other implementation. I don't think this is really an improvement here. The main issue is this kind of sandboxing implemented by chromium and other projects are not really future-proof and constrains the libc implementation to keep using the old syscalls where the kernel contract allows to use a more broad one. In fact, this is *exactly* what kernel intends to provide a more generic interface instead of multiple ones to implement the POSIX interfaces.