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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA7A3C3DA49 for ; Thu, 18 Jul 2024 16:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=48lM8jd+alFpBX/YD03KnSzOLd 9JXXd+2yebAmmxPtGTVHF9SLSwkIi5qcbBvXXsXNI/A2AEGqKBD9Xd6mdUt+ADMOD0I6guvT5nTbq UzGFBpRezEFyY+4w1lQW401Am7RuwU/ALmcTghFv9HfX9WTw+mQHur+4TQ1aj1/tCWZ9Psud/qjSN t6MxlI1A77e+rG+Fn4mVNRNgGyrB+oyOJiJBcJjBnvi4J8WGB/Kxgyt5OnSw78kFMNk7xhQV1NLFv MbJfOcaSC2ar2XVhfwVAQofY2F/ZoAVfBDzFrgGWk4DysJrO/2afdn+hBG7QtRAYnErokGKh1Yatn N3gju5CA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTmg-0000000HY8O-0Bcb; Thu, 18 Jul 2024 16:15:10 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTmJ-0000000HXzz-0NpZ for linux-arm-kernel@lists.infradead.org; Thu, 18 Jul 2024 16:14:48 +0000 Received: by mail-io1-xd35.google.com with SMTP id ca18e2360f4ac-7fb93b2e2a3so34396239f.1 for ; Thu, 18 Jul 2024 09:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1721319285; x=1721924085; darn=lists.infradead.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=YGTeyyHil/vS7xOYHGXaITKXBfrOMLNEUzAXL2pOPfOSIPo5RUGkVV+5iuHCoQ9Igk 9j3Z0tgxiflkpu+BXiEeyP/afqJeKiBuNu1TOAju1qoX51G29WeWxLRRNwQogiQOhHv5 RvZY1cp9OOc3tHdGVpUI8LSQUP80JLQrSDPetqt9YgdKrU4n2m2CRrFlNJHh4rMrC3Rs VIL1L77aV8dmZNC52kExZ/vWzDcWpMHYe2uqoK1ME90OK90luYUEBhCDVEg7hbR35SEj pOY7A5qAnTPGtSAztQUJKFcHGz5FVDdeRGkTdPDKXwaQhRUqIAdqF9MXkmp1fcduaVKG XMxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721319285; x=1721924085; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=YW3epsFFLf1Vv5X9esSpDYBjo+rC73rlpY5BBSx+vADKAoA5HOshjn1WdLxLlzJn9M +jRSUFgVi3KaRGUPnD2UeFL7XwzF3XOHSDoF/PS7TaynsG0FnhWWq2aNhrC2N/s6opA6 9TcN0cHDwEKhk1jR381OSqw14o90CoIzyVRbf+po95yHTKYKqE86rsI5q8ZACbkTM1vo I//i4qas7oPdENuconbYIZqrnn9IPvBYgNY4Ja4PVs2gDDkON6kqAphiP5Ia37ke+Ubv PqQXzuZuDdborgqyJWHWf3WZ+KZUjpslXZWZK76V4XXe66Hq1cA25xXwtEkIwhV+Be3H lABg== X-Forwarded-Encrypted: i=1; AJvYcCVk+SxNmgug9VCJHNF8KKiRET1PWS0EHLVJYjeMn+K4UuPq/RdG/MV8mtL38f0PS0BKDYxj0ujdQNhAY+dWa/MTe0MveLvXSvA79OD7MT8iXxTi+T8= X-Gm-Message-State: AOJu0YwjDqJOFfHs/HufLgd1Twy4WKgm1DWCwZh37A+/4b1QtcpOuUni YPOGk10MmFLPf4q555jktwV9JQzO5UoH0eDlYZelliSeHf3WaMg5eczi36XSg60= X-Google-Smtp-Source: AGHT+IGBl5SUOSetZ7hpvAsBcsY+3Cb2iftUEXypwidAC9j+tfeb4FVk4PWmNhC4HY+kt6K5hLBh4A== X-Received: by 2002:a05:6602:3fcc:b0:804:657d:92fc with SMTP id ca18e2360f4ac-817123e1bb4mr642950839f.18.1721319284795; Thu, 18 Jul 2024 09:14:44 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:49aa:ec5c:43c8:2afb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-78e34d2c7e2sm7993415a12.54.2024.07.18.09.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 09:14:44 -0700 (PDT) From: Thiago Jung Bauermann To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v9 35/39] kselftest/arm64: Add a GCS test program built with the system libc In-Reply-To: <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> (Mark Brown's message of "Tue, 25 Jun 2024 15:58:03 +0100") References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> Date: Thu, 18 Jul 2024 13:14:41 -0300 Message-ID: <87plray8we.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240718_091447_148414_C114DED5 X-CRM114-Status: GOOD ( 16.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Mark Brown writes: > There are things like threads which nolibc struggles with which we want > to add coverage for, and the ABI allows us to test most of these even if > libc itself does not understand GCS so add a test application built > using the system libc. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > tools/testing/selftests/arm64/gcs/.gitignore | 1 + > tools/testing/selftests/arm64/gcs/Makefile | 4 +- > tools/testing/selftests/arm64/gcs/gcs-util.h | 10 + > tools/testing/selftests/arm64/gcs/libc-gcs.c | 736 +++++++++++++++++++++++++++ > 4 files changed, 750 insertions(+), 1 deletion(-) In my FVP VM, this test gets a GCS SIGSEGV before running the first test: $ sudo ./run_kselftest.sh -t arm64:libc-gcs [sudo] password for bauermann: TAP version 13 1..1 # timeout set to 45 # selftests: arm64: libc-gcs # TAP version 13 # 1..118 # # Starting 118 tests from 32 test cases. # # RUN global.can_call_function ... # Segmentation fault not ok 1 selftests: arm64: libc-gcs # exit=139 $ It happens when returning from the syscall() glibc function that does the clone3 syscall in kselftest_harness.h: $ /var/tmp/gdb-gcs/bin/gdb -q arm64/libc-gcs Reading symbols from arm64/libc-gcs... (gdb) r Starting program: /var/tmp/selftests-v9/arm64/libc-gcs [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". TAP version 13 1..118 # Starting 118 tests from 32 test cases. # RUN global.can_call_function ... [Detaching after vfork from child process 823] Program received signal SIGSEGV, Segmentation fault Guarded Control Stack error. syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] warning: 41 ../sysdeps/unix/sysv/linux/aarch64/syscall.S: No such file or directory (gdb) p $_siginfo.si_signo $1 = 11 (gdb) p $_siginfo.si_code $2 = 10 (gdb) p $_siginfo._sifields._sigfault.si_addr $3 = (void *) 0xfffff7ed96b0 (gdb) disassemble Dump of assembler code for function syscall: 0x0000fffff7ed9680 <+0>: nop 0x0000fffff7ed9684 <+4>: mov w8, w0 0x0000fffff7ed9688 <+8>: mov x0, x1 0x0000fffff7ed968c <+12>: mov x1, x2 0x0000fffff7ed9690 <+16>: mov x2, x3 0x0000fffff7ed9694 <+20>: mov x3, x4 0x0000fffff7ed9698 <+24>: mov x4, x5 0x0000fffff7ed969c <+28>: mov x5, x6 0x0000fffff7ed96a0 <+32>: mov x6, x7 0x0000fffff7ed96a4 <+36>: svc #0x0 0x0000fffff7ed96a8 <+40>: cmn x0, #0xfff 0x0000fffff7ed96ac <+44>: b.cs 0xfffff7ed96b4 // b.hs, b.nlast => 0x0000fffff7ed96b0 <+48>: ret 0x0000fffff7ed96b4 <+52>: b 0xfffff7e18660 <__GI___syscall_error> 0x0000fffff7ed96b8 <+56>: b 0xfffff7e18660 <__GI___syscall_error> End of assembler dump. (gdb) bt #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] #1 0x0000aaaaaaaa4acc in clone3_vfork () at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:93 #2 __run_test (f=f@entry=0xaaaaaaac0b88 <_fixture_global>, variant=variant@entry=0xffffffffee00, t=t@entry=0xaaaaaaac0018 <_can_call_function_object>) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1239 [GCS error] #3 0x0000aaaaaaaa2c40 in test_harness_run (argv=0xfffffffff008, argc=1) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1314 #4 main (argc=1, argv=0xfffffffff008) at libc-gcs.c:735 [GCS error] (gdb) And indeed, the svc call in the disassemble above corrupts the GCS. This is the GCS and lr values right before the svc call: (gdb) x/i $pc => 0xfffff7ed96a4 : svc #0x0 (gdb) p/x $lr $3 = 0xaaaaaaaa4acc (gdb) p/x $gcspr $4 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4acc So far so good, the tip of the GCS matches $lr. But then: (gdb) stepi [Detaching after vfork from child process 2491] 39 in ../sysdeps/unix/sysv/linux/aarch64/syscall.S (gdb) x/i $pc => 0xfffff7ed96a8 : cmn x0, #0xfff (gdb) p/x $gcspr $5 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4c04 (gdb) p/x $lr $6 = 0xaaaaaaaa4acc So, right after svc returns, the tip of the GCS is corrupted and will cause the GCS error. -- Thiago