From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by sourceware.org (Postfix) with ESMTPS id 1F0F43857C43 for ; Tue, 26 Apr 2022 12:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F0F43857C43 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=opteya.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=opteya.com Received: from [IPV6:2a01:e35:39f2:1220:3aa4:81f8:44d1:2822] (unknown [IPv6:2a01:e35:39f2:1220:3aa4:81f8:44d1:2822]) by smtp5-g21.free.fr (Postfix) with ESMTPS id 486CF5FFB6; Tue, 26 Apr 2022 14:42:39 +0200 (CEST) Message-ID: Date: Tue, 26 Apr 2022 14:42:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2] nptl: Add backoff mechanism to spinlock loop Content-Language: en-US To: Florian Weimer , Noah Goldstein Cc: =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Wangyang Guo , Adhemerval Zanella via Libc-alpha References: <20220328084705.468207-1-wangyang.guo@intel.com> <97b1105f-42e8-a347-f82e-c81e548f0c2f@linaro.org> <82d5d195-aea0-f817-bfc1-5822829728c7@linaro.org> <87wnfufrh2.fsf@oldenburg.str.redhat.com> <6d934a2c-8f89-50ca-11b8-e2eaeb046add@opteya.com> <87o80ts0pa.fsf@oldenburg.str.redhat.com> <874k2gkp4n.fsf@oldenburg.str.redhat.com> From: Yann Droneaud Organization: OPTEYA In-Reply-To: <874k2gkp4n.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 26 Apr 2022 12:42:46 -0000 Hi, Le 26/04/2022 à 14:25, Florian Weimer a écrit : > * Noah Goldstein: > >> On Fri, Apr 22, 2022 at 8:35 AM Cristian Rodríguez via Libc-alpha >> wrote: >>> On Fri, Apr 22, 2022 at 9:32 AM Florian Weimer via Libc-alpha >>> wrote: >>> >>>>> As each running threads has its own stack, thread' stack address can >>>>> be used as a seed for such PRNG. >>>> We would broadcast the stack address though, which is generally fround >>>> upon. >> Why is that? > Potential bypass of ASLR hardening. The attack would be to monitor the behavior of multiple threads in a process contending for a lock, and get precise timings to recover the few bits of each thread stack address that leaked as part of the backoff mechanism. It may sound possible, but I find it unlikely possible without full compromise of the running process .... That said, using the stack address as the key in SipHash, it's cryptographically unlikely to recover it from its output, thus no exploitable leakage would happen. Regards. -- Yann Droneaud OPTEYA