From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oAZpJtgalGjwugUAWB0awg (envelope-from ) for ; Wed, 06 Aug 2025 23:17:44 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=jZ5CqG17; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 878D81E100; Wed, 6 Aug 2025 23:17:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2D7001E089 for ; Wed, 6 Aug 2025 23:17:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A20883858C24 for ; Thu, 7 Aug 2025 03:17:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A20883858C24 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=jZ5CqG17 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 16AF63858D26 for ; Thu, 7 Aug 2025 03:17:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16AF63858D26 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 16AF63858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1754536631; cv=none; b=otkudNrVXNuB9TfFGvQmJIK9BEFnLnwSR9VFJY67inX4kgmL2YXtE236UvETQemnl6a6bw949BgC7Posq6yVJfL7vMj07QOqTvbJn8IFmJWqkqbCgLOTaXKd/avfOzybdG4XIO1VNpX0POVua8t33k9kLqdbuRSuRs3LFKmbkBQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1754536631; c=relaxed/simple; bh=TViLa8o61j7KctSOKBbmGH6RUXe8skhLJ+RbA0LFoaU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=eHAIJnsgcN+MdfZq9wV0N3nSuzFP8DLd1L+Cjujg6fj2zizHdKt8GLkMJ9Z7qUWiEAfuUdWGvfa7tMojRA2ivdmR6Bv0QToc2a2Ei1iu8vGBqV0THcTQI6+hkiW5zWgcAjtnvT5+nzGvb5r6QEqgpxtQt9Pf9vb0um5Piga9SfY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 16AF63858D26 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-24063eac495so3994745ad.0 for ; Wed, 06 Aug 2025 20:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1754536630; x=1755141430; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=uPjZfZqVBe6mwlZma92dy7DJ0XL0f9PjB1scoSBiQEU=; b=jZ5CqG17d8Fi6bU2KW085xHtkzlLxz5sfgnQX9VmQAitBsgcApSFENzNHHiFLlKIkX xpWndo86G+/z2zZ4j71hnldh/q0OwKzUpNUcUb9l93Jh3Hbsft+kGfeNIquDM3t1HZAr 3u1GExVvoQmMHwpv9mwQ0g3djxC/9h9hSDxnJ5HRveFKmVA2EVBniE3fRK7Ti93lpg43 /dgnjvAdh+ZwStAJaterKoRkeOIhX3AyCKkq4f3jo+52NQwWTkhae9Ck4Qma+y3MCxlE RXu/CTwcFWMaYwWon1abF5i3hhGQQC7L5vOblob8bX5WlVy2BDFQEv+8I8er7orNkckp EgJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754536630; x=1755141430; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uPjZfZqVBe6mwlZma92dy7DJ0XL0f9PjB1scoSBiQEU=; b=B6X4/ihc+0U0ympbMZaDlV8tZ71436Ie4jkQaMDPV2ELtKbaImxZUK6l7r8KmVCUs5 xsD+qg2R2NUHSHWsL2GW7Lc+RiAYWqwX1xQln2+dqPcBzPWbDVVtaWXSrvGRy2jXYcPr hcHa8pu0tY3ml8r8m1G4TMiIkrjw/Olb2KsPEaqxiZjhfeaDWuymR8CtMRNtVBNGVj7R YhQdu0qY/IJDic1vDzlld1X1ZuoAT3WWenhQqSqssWgPD6guYjSgJUAIMnV9eeL+FmzB z1JgoYKUXmwKcjVWGFXGWLVPQvc2s5H8XFqRoweRTORd8WLfu6/vib33el4wO5LOW1Ks GY2g== X-Gm-Message-State: AOJu0YwZ29+5SFJ0/u6bryIido6XBA7nMAMTe1Bj7Ym8hSrYiX5LhtGZ cveblf7GucdrsUqCtbqGH3VWp9D5FDbXwViHvRS5rfSXfB232weoZEsNb8nsZBjoaDU= X-Gm-Gg: ASbGncsSdx1xb2vxo8NeXxhj3w9r+1vfScdbyKECqw1KWQI7Q2NA/N0Juhzyv4t6kN5 ZLEomqwP8dlkTmxeUFduQLN5ZjNrRcRseyZoxtINbZAK/F7pzyGselhZv8wH9dt9EaceLm/E995 oCZ7nQ4iscMrr6gvuakWOfwnG9vA/mErtUoiROsE20JfHlDidPwzDjlDBjFGjx0h1GypZeNfIu1 WYn2MKfSVrMeheeSzPkAzgjFHPcBenQGTHPte4WAyZTBndeRba5ESwc4VDeH9Lq2VaQ97dXKFdB DbXx6DBetmCcU1tEROTcP+/SseQt+a9IFPp30QQerY3yzoz5vPrDiKMTcX4If6LPyJfnZ5Yxu4/ QRQxAtLi50lHuV3ZZI80BiMO+hccE7asT X-Google-Smtp-Source: AGHT+IH5We43LhgyxgfI8oaSnfBtiWZ8ruAbk6o7uMJRJZ05uGqvDsxoS1foV6hsD/IylpEWmSJfLg== X-Received: by 2002:a17:902:da89:b0:235:f298:cbbd with SMTP id d9443c01a7336-242a0b03585mr72071285ad.21.1754536629966; Wed, 06 Aug 2025 20:17:09 -0700 (PDT) Received: from localhost ([2804:14d:7e39:88d6:6361:26c3:af8a:c79f]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-241d1f0e9bdsm169924355ad.53.2025.08.06.20.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Aug 2025 20:17:09 -0700 (PDT) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: "gdb-patches@sourceware.org" , "luis.machado@arm.com" , Andrew Burgess Subject: Re: [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. In-Reply-To: (Christina Schimpe's message of "Wed, 6 Aug 2025 19:54:54 +0000") References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-7-christina.schimpe@intel.com> <87cy9oe8pc.fsf@redhat.com> <87qzxpan2h.fsf@redhat.com> User-Agent: mu4e 1.12.11; emacs 30.1 Date: Thu, 07 Aug 2025 00:17:07 -0300 Message-ID: <87v7mzizws.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hello Christina, "Schimpe, Christina" writes: >> > >> > + # Read PL3_SSP register. >> > >> > + set ssp_main [get_hexadecimal_valueof "\$pl3_ssp" "read >> > >> > + pl3_ssp value"] >> > >> > + >> > >> > + # Write PL3_SSP register. >> > >> > + gdb_test "print /x \$pl3_ssp = 0x12345678" "= 0x12345678" >> > >> > + "set pl3_ssp >> > >> value" >> > >> > + gdb_test "print /x \$pl3_ssp" "= 0x12345678" "read pl3_ssp >> > >> > + value after >> > >> setting" >> > >> > + >> > >> > + # Restore original value. >> > >> > + gdb_test "print /x \$pl3_ssp = $ssp_main" "= $ssp_main" >> > >> > + "restore >> > >> original pl3_ssp" >> > >> > + >> > >> > + # Potential CET violations often only occur after resuming >> > >> > + normal >> > >> execution. >> > >> > + # Therefore, it is important to test normal program >> > >> > + continuation >> > after >> > >> > + # configuring the shadow stack pointer. >> > >> > + gdb_continue_to_end >> > >> >> > >> I assume that if we continue with the bogus value in place the >> > >> inferior would either give an error or terminate. Is it worth >> > >> trying this and checking that the inferior behaves as expected? >> > > >> > > If we don't reset the shadow stack pointer to it's original value we >> > > will see >> > a SEGV. >> > > Dependent on the address of the wrong shadow stack pointer it's >> > > either a SEGV with si code that points to a control flow protection >> > > fault or a >> > different si code. >> > > >> > > So if I stay in a valid address range for configuring pl3_ssp but >> > > don't restore the original value I'll see a control flow protection >> exception: >> > > >> > > [...] >> > > breakpoint 1, 0x0000555555555148 in main ()^M >> > > (gdb) print /x $pl3_ssp^M >> > > $1 = 0x7ffff7bfffe8^M >> > > (gdb) PASS: gdb.arch/amd64-ssp.exp: get hexadecimal valueof >> "$pl3_ssp" >> > > print /x $pl3_ssp = 0x7ffff7bfffe0^M >> > > $2 = 0x7ffff7bfffe0^M >> > > (gdb) PASS: gdb.arch/amd64-ssp.exp: set pl3_ssp value print /x >> > > $pl3_ssp^M >> > > $3 = 0x7ffff7bfffe0^M >> > > (gdb) PASS: gdb.arch/amd64-ssp.exp: read pl3_ssp value after setting >> > > continue^M Continuing.^M ^M Program received signal SIGSEGV, >> > > Segmentation fault.^M >> > > 0x0000555555555158 in main ()^M >> > > (gdb) FAIL: gdb.arch/amd64-ssp.exp: continue until exit >> > > >> > > Siginfo shows si_code = 10, which indicates a control protection fault. >> > > >> > > p $_siginfo^M >> > > $4 = {si_signo = 11, si_errno = 0, si_code = 10, [...] >> > > >> > > If I set the value of pl3_ssp as in the current test (0x12345678) >> > > I'll see a different SEGV actually >> > > >> > > p $_siginfo >> > > $4 = {si_signo = 11, si_errno = 0, si_code = 1, [...] >> > > >> > >> >> > >> What if, say, the $pl3_ssp value only ever made it as far as the >> > >> register cache, and was never actually written back to the inferior? >> > >> I don't think the above test would actually spot this bug, right? >> > > >> > > Hm, if I understand you correctly here and you mean the scenario as >> > > shown above the above test would spot this bug I think (as we saw a >> fail). >> > > >> > > Does my example above show what you described or do you mean a >> > > different scenario? >> > >> > Yes, something like the above would check that the register is >> > actually being written back to the hardware, and is written to the expected >> location. >> > >> > The current test, as written in the patch, writes a bad value to the >> > shadow stack, then restores the correct value. What if the bad value >> > never actually got written back to the hardware at all, and was just >> > being held in the register cache? >> > >> > Having a test that writes a bad value, then does 'continue', and >> > expects to see something like 'Program received signal ...' would be a >> > reasonable indication that the write to the shadow stack actually made it >> to the h/w. >> > >> > Thanks, >> > Andrew >> >> >> Yes, I agree, I'll add: >> >> ~~~ >> with_test_prefix "invalid ssp" { >> write_invalid_ssp >> >> # Continue until SIGSEV to test that the value is written back to HW. >> gdb_test "continue" \ >> [multi_line \ >> "Continuing\\." \ >> "" \ >> "Program received signal SIGSEGV, Segmentation fault\\." \ >> "$hex in main \\(\\)"] \ >> "continue to SIGSEGV" >> } >> >> clean_restart ${binfile} >> if { ![runto_main] } { >> return -1 >> } >> >> with_test_prefix "restore original ssp" { >> # Read PL3_SSP register. >> set ssp_main [get_hexadecimal_valueof "\$pl3_ssp" "read pl3_ssp >> value"] >> >> write_invalid_ssp >> >> # Restore original value. >> gdb_test "print /x \$pl3_ssp = $ssp_main" "= $ssp_main" "restore >> original value" >> >> # Now we should not see a SIGSEV, since the original value is >> restored. >> gdb_continue_to_end >> } >> >> ~~~ >> >> Regards, >> Christina > > Do you have a test for actual write back to HW (as above). If not, it > might make sense to add it also for GCS? I don't have a test for it, but I agree it's worth adding one. Will do. Thanks for pointing out. -- Thiago