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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 E5694C10F16 for ; Sat, 27 Apr 2024 23:22:24 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1s0rLD-0000000072N-0Dsc; Sat, 27 Apr 2024 19:20:23 -0400 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1s0rL9-0000000071o-0IJM for kernelnewbies@kernelnewbies.org; Sat, 27 Apr 2024 19:20:21 -0400 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-6ee1c0ecfa5so44553a34.0 for ; Sat, 27 Apr 2024 16:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714259994; x=1714864794; darn=kernelnewbies.org; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:to:from:from:to:cc:subject:date:message-id :reply-to; bh=M1djVEthf7yI7n4dw9JPc1NWknpqTVAE/rv0cDHc9Tg=; b=IyfxnrY4d7I9filTuMeVuSCybwErzxpUi8DzdAGDiu9k78sE6aPy0CCrgPeo+lN7rP aSpddGlajjOnA3ukNkVsK0Sh3qGvZylxBZA5lzF2P8UA5pHYGs3AUGNqfO9+WUzqmtOY Z+vl9Ps8HN94MKDxGAngURkXI/7PZQxdR+4p7vTsgPsiH6crNn6m0Cq9b6+5nDxOx9z9 yWAeFWwlOEGe3A9ZzdHfHMPA9Ebt/zRrbhqiwOh602samcYsiqO0zbdg9JeHjSoult1s yAT+Vd1gwFJiCj3ob628MUpIasyE2Q4UkST24q3WDlHImosvMcrrjlAGqUU1+Ee0mEuM /yog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714259994; x=1714864794; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M1djVEthf7yI7n4dw9JPc1NWknpqTVAE/rv0cDHc9Tg=; b=tQtC/kY4cWPKFtA2yOrPzwM06fmnl9cI6h7GMKsRxex5EB4r52cF/13L7vuWvwCd8t J9YkWqQKUQBzvPPt8Zr6saBtFx56T87KMnlAq+ZfCWM5IDqYyysiijRpCQyXAfzRN2Wd wysbDASbw4JbhLY65Whahaf2JLj0761taLFQ09flNR8Je7SO/c3VRIEUjnakWOm85Df5 CzOvmYdF85yaYNvaXndhVmNEC/IUq0hPOspUVBvvVPOE04Whmvvx6EI8GFznqpixqYak mfrOPhrTcELcITThqp4nyLetIu8TY/hx6qnlgovOJ01do6OEJUDL3gGVztc0X5BbaEZk 9soQ== X-Gm-Message-State: AOJu0Yx7u0EDgcNkdAbXREJm1VbhH7XzgsUXjPV4J8rhJiDwmMLq2T3Z 7O2PoyULP3/T5gDTjzYmjccyPyxT4BYdqh0jci2CPmKdQl2EIv7/rqKD9Q== X-Google-Smtp-Source: AGHT+IEcNi9EPFxz2a/1VbYbTJjU88W7twFBZEvqe2gTSkpv23q8tdS5MGbtNbQ18irOKg2rZcAgYA== X-Received: by 2002:a05:6830:3295:b0:6ed:bd3f:70f8 with SMTP id m21-20020a056830329500b006edbd3f70f8mr6529869ott.12.1714259994268; Sat, 27 Apr 2024 16:19:54 -0700 (PDT) Received: from BryanDesktop (ip98-172-213-87.ok.ok.cox.net. [98.172.213.87]) by smtp.gmail.com with ESMTPSA id g10-20020a9d6a0a000000b006eb7ba9552dsm3535235otn.41.2024.04.27.16.19.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Apr 2024 16:19:54 -0700 (PDT) From: To: References: <031a01da98f9$0e5b3cf0$2b11b6d0$@gmail.com> In-Reply-To: <031a01da98f9$0e5b3cf0$2b11b6d0$@gmail.com> Subject: serial debug: permission denied Date: Sat, 27 Apr 2024 18:19:54 -0500 Message-ID: <032101da98f9$69798060$3c6c8120$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIQihN9XmdOguoZtLuEssOVXiijZ7EQ3oYQ Content-Language: en-us X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6515389319553672874==" Errors-To: kernelnewbies-bounces@kernelnewbies.org This is a multipart message in MIME format. --===============6515389319553672874== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0322_01DA98CF.80A3ED90" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0322_01DA98CF.80A3ED90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I'm attempting to use gdb to debug over a serial connection using two VM's. I'm getting a "Permission denied" when I try to connect over the serial com port. Gdb has the following output when I try to connect: Reading symbols from vmlinux... +target remote /dev/ttyS1 Remote debugging using /dev/ttyS1 [remote] start_remote_1: enter [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-e vents+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-taggin g+#ec [remote] Junk: d [remote] Junk: i [remote] Junk: a [remote] Junk: g [remote] Junk: : [remote] Junk: [remote] Received Nak [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-e vents+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-taggin g+#ec [remote] Junk: 2 [remote] Junk: 2 [remote] Junk: : [remote] Junk: [remote] Junk: P [remote] Junk: e [remote] Junk: r [remote] Junk: m [remote] Junk: i [remote] Junk: s [remote] Junk: s [remote] Junk: i [remote] Junk: o [remote] Junk: n [remote] Junk: [remote] Junk: d [remote] Junk: e [remote] Junk: n [remote] Junk: i [remote] Junk: e [remote] Junk: d [remote] Junk: ^M [remote] Junk: [remote] Junk: [ [remote] Junk: 2 [remote] Junk: ] [remote] Junk: k [remote] Junk: d [remote] Junk: b [remote] Junk: > [remote] Junk: [remote] Junk: : [remote] Junk: m [remote] Junk: u [remote] Junk: l [remote] Junk: t [remote] Junk: i [remote] Junk: p [remote] Junk: r [remote] Junk: o [remote] Junk: c [remote] Junk: e [remote] Junk: s [remote] Junk: s [remote] Received Ack [remote] read_frame: Bad checksum, sentsum=0xec, csum=0x8, buf=qSupporteddiag: -22: Permission denied\r\n[2]kdb> :multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec -events+;vContSupported+;QThreadEvents+;no-resumed+;memory-tagging+ [remote] getpkt: Timed out. [remote] getpkt: Timed out. Ignoring packet error, continuing... [remote] packet_ok: Packet qSupported (supported-packets) is supported [remote] Sending packet: $vCont?#49 [remote] Received Nak [remote] Sending packet: $vCont?#49 [remote] Received Ack [remote] Packet received: vCont? [remote] packet_ok: Packet vCont (verbose-resume) is NOT supported [remote] packet_ok: Packet vCont (verbose-resume) is NOT supported [remote] Sending packet: $vMustReplyEmpty#3a [remote] putpkt_binary: Packet instead of Ack, ignoring it [remote] Received Ack [remote] Packet received: vMustReplyEmpty [remote] start_remote_1: exit Remote replied unexpectedly to 'vMustReplyEmpty': vMustReplyEmpty +quit It seems the target is denying permission. I've been searching around but have not found anything similar. I tried opening the permissions on the /dev/ttyS1 on both VM's to rwxrwxrwx and that doesn't help. There are no SELinux warnings on the debugger VM. I don't know if SELinux is causing a problem on the target VM. More details about the configuration: I'm running two Rocky 9.3 VM's on Windows Hyper-V that I have connected over a named pipe using the Powershell Set-VMComport commands: Set-VMComport -VMName "Rocky-Debugger" -Number 2 -Path \\.\pipe\rocky-pipe-2 Set-VMComport -VMName "Rocky " -Number 2 -Path \\.\pipe\rocky-pipe-2 I downloaded the 6.8.5 kernel from the kernel.org website and compiled it on the "Rocky" vm using the following configuration: # # Generic Kernel Debugging Instruments # CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_MAGIC_SYSRQ_SERIAL=y CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE="" CONFIG_DEBUG_FS=y CONFIG_DEBUG_FS_ALLOW_ALL=y # CONFIG_DEBUG_FS_DISALLOW_MOUNT is not set # CONFIG_DEBUG_FS_ALLOW_NONE is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_HONOUR_BLOCKLIST=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set CONFIG_KGDB_LOW_LEVEL_TRAP=y CONFIG_KGDB_KDB=y CONFIG_KDB_DEFAULT_ENABLE=0x0 CONFIG_KDB_KEYBOARD=y CONFIG_KDB_CONTINUE_CATASTROPHIC=0 CONFIG_ARCH_HAS_EARLY_DEBUG=y CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y # CONFIG_UBSAN is not set CONFIG_HAVE_ARCH_KCSAN=y CONFIG_HAVE_KCSAN_COMPILER=y # CONFIG_KCSAN is not set # end of Generic Kernel Debugging Instruments I added the kernel args "console=tty0 console=ttyS0,115200 kgdboc=ttyS1,115200". I start the VM with the new kernel and run the command "echo g > /proc/sysrq-trigger". On the "Rocky-debugger" vm, I added my user to "dialout". The permissions on /dev/ttyS1 is rw for the group. I set the following in .gdbinit, "set serial baud 115200". Run "gdb vmlinux", then "target remote /dev/ttyS1". That's when I get the "Permission denied". I can connect to the console over serial using "sudo screen ttyS0" and that works just fine. So I don't believe it's a Windows Hyper-V permissions issue. I'm out of ideas. Any help is appreciated! Thanks, Bryan Carroll ------=_NextPart_000_0322_01DA98CF.80A3ED90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’m = attempting to use gdb to debug over a serial connection using two = VM’s. I’m getting a “Permission denied” when I = try to connect over the serial com port. Gdb has the following output = when I try to connect:

 

Reading = symbols from vmlinux...

+target = remote /dev/ttyS1

Remote debugging = using /dev/ttyS1

[remote] = start_remote_1: enter

  [remote] = Sending packet: = $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfor= k-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-= tagging+#ec

  [remote] Junk: = d

  [remote] Junk: = i

  [remote] Junk: = a

  [remote] Junk: = g

  [remote] Junk: = :

  [remote] = Junk:

  [remote] Received = Nak

  [remote] Sending packet: = $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfor= k-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-= tagging+#ec

  [remote] Junk: = 2

  [remote] Junk: = 2

  [remote] Junk: = :

  [remote] = Junk:

  [remote] Junk: = P

  [remote] Junk: = e

  [remote] Junk: = r

  [remote] Junk: = m

  [remote] Junk: = i

  [remote] Junk: = s

  [remote] Junk: = s

  [remote] Junk: = i

  [remote] Junk: = o

  [remote] Junk: = n

  [remote] = Junk:

  [remote] Junk: = d

  [remote] Junk: = e

  [remote] Junk: = n

  [remote] Junk: = i

  [remote] Junk: = e

  [remote] Junk: = d

  [remote] Junk: = ^M

  [remote] = Junk:

 

  [remote] Junk: [

  [remote] Junk: 2

  [remote] Junk: ]

  [remote] Junk: k

  [remote] Junk: d

  [remote] Junk: b

  [remote] Junk: >

  [remote] Junk:

  [remote] Junk: :

  [remote] Junk: m

  [remote] Junk: u

  [remote] Junk: l

  [remote] Junk: t

  [remote] Junk: i

  [remote] Junk: p

  [remote] Junk: r

  [remote] Junk: o

  [remote] Junk: c

  [remote] Junk: e

  [remote] Junk: s

  [remote] Junk: s

  [remote] Received Ack

  [remote] read_frame: Bad checksum, = sentsum=3D0xec, csum=3D0x8, buf=3DqSupporteddiag: -22: Permission = denied\r\n[2]kdb> = :multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;e= xec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-tagging+

  [remote] getpkt: Timed = out.

  [remote] getpkt: Timed = out.

Ignoring packet error, = continuing...

  [remote] = packet_ok: Packet qSupported (supported-packets) is = supported

  [remote] Sending = packet: $vCont?#49

  [remote] = Received Nak

  [remote] Sending = packet: $vCont?#49

  [remote] = Received Ack

  [remote] Packet = received: vCont?

  [remote] = packet_ok: Packet vCont (verbose-resume) is NOT = supported

  [remote] packet_ok: = Packet vCont (verbose-resume) is NOT supported

  [remote] Sending packet: = $vMustReplyEmpty#3a

  [remote] = putpkt_binary: Packet instead of Ack, ignoring it

  [remote] Received Ack

  [remote] Packet received: = vMustReplyEmpty

[remote] = start_remote_1: exit

Remote replied = unexpectedly to 'vMustReplyEmpty': vMustReplyEmpty

+quit

 

It seems the = target is denying permission. I’ve been searching around but have = not found anything similar. I tried opening the permissions on the = /dev/ttyS1 on both VM’s to rwxrwxrwx and that doesn’t help. = There are no SELinux warnings on the debugger VM. I don’t know if = SELinux is causing a problem on the target VM.

 

More details = about the configuration:

 

I’m = running two Rocky 9.3 VM’s on Windows Hyper-V that I have = connected over a named pipe using the Powershell Set-VMComport = commands:

 

Set-VMComport -VMName "Rocky-Debugger" = -Number 2 -Path \\.\pipe\rocky-pipe-2<= /p>

Set-VMComport -VMName "Rocky " -Number = 2 -Path \\.\pipe\rocky-pipe-2<= /p>

 

I = downloaded the 6.8.5 kernel from the kernel.org website and compiled it = on the “Rocky” vm using the following = configuration:

 

#

# Generic Kernel = Debugging Instruments

#

CONFIG_MAGIC_SYSRQ=3Dy

CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=3D0x1

<= p class=3DMsoNormal>CONFIG_MAGIC_SYSRQ_SERIAL=3Dy

CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE=3D""<= /o:p>

CONFIG_DEBUG_FS=3Dy

CONFIG_DEBUG_FS_ALLOW_ALL=3Dy

# CONFIG_DEBUG_FS_DISALLOW_MOUNT is not = set

# CONFIG_DEBUG_FS_ALLOW_NONE is = not set

CONFIG_HAVE_ARCH_KGDB=3Dy

CONFIG_KGDB=3Dy

CONFIG_KGDB_HONOUR_BLOCKLIST=3Dy

CONFIG_KGDB_SERIAL_CONSOLE=3Dy

CONFIG_KGDB_TESTS=3Dy

# CONFIG_KGDB_TESTS_ON_BOOT is not = set

CONFIG_KGDB_LOW_LEVEL_TRAP=3Dy

CONFIG_KGDB_KDB=3Dy

CONFIG_KDB_DEFAULT_ENABLE=3D0x0

CONFIG_KDB_KEYBOARD=3Dy

CONFIG_KDB_CONTINUE_CATASTROPHIC=3D0

CONFIG_ARCH_HAS_EARLY_DEBUG=3Dy

CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=3Dy

# CONFIG_UBSAN is not set

CONFIG_HAVE_ARCH_KCSAN=3Dy

CONFIG_HAVE_KCSAN_COMPILER=3Dy

# CONFIG_KCSAN is not set

# end of Generic Kernel Debugging = Instruments

 

I added the kernel args “console=3Dtty0 = console=3DttyS0,115200 kgdboc=3DttyS1,115200”. I start the VM with = the new kernel and run the command “echo g > = /proc/sysrq-trigger”.

 

On the = “Rocky-debugger” vm, I added my user to = “dialout”. The permissions on /dev/ttyS1 is rw for the = group.

 

I set the following in .gdbinit, “set serial = baud 115200”.

 

Run = “gdb vmlinux”, then “target remote /dev/ttyS1”. = That’s when I get the “Permission denied”. =

 

I can connect to the console over serial using = “sudo screen ttyS0” and that works just fine. So I = don’t believe it’s a Windows Hyper-V permissions = issue.

 

I’m out of ideas. Any help is = appreciated!

 

Thanks,

Bryan = Carroll

 

 

------=_NextPart_000_0322_01DA98CF.80A3ED90-- --===============6515389319553672874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============6515389319553672874==--