From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D587B3858408; Fri, 16 Feb 2024 05:29:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D587B3858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1708061376; bh=J82ifX/M5UzSCcCe16vumKXO9RDmMkOlpo8T2a2q0xk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tH25VKG6D4Zlktgq2UGKXAvMOLsc76jkLAkhQ9bEcNGicKkhKlR1r4EVTTIIUhzp4 luRhK7argnchlsgnzEr1hy30ivtpqQYSwyuCxIuJAadaVjAmsNvJAl8eNjYxMzjIYD urYjvf1HqC8RNWRQtsUa+ZmxYZrOwZ+TceSEv4Do= From: "adrian.ratiu at collabora dot com" To: gdb-prs@sourceware.org Subject: [Bug server/30453] gdbserver cannot set breakpoints when /proc/pid/mem is not writable Date: Fri, 16 Feb 2024 05:29:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: server X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adrian.ratiu at collabora dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30453 --- Comment #16 from Adrian Ratiu --- (In reply to Pedro Alves from comment #12) > "too risky", why? That position doesn't make any sense to me. >=20 > But I can't open: >=20 > > [1] https://issuetracker.corp.google.com/issues/268356054#comment61 >=20 > Does one have to be inside the google corporate network to open that? Sorry I messed up the link, here is the correct one: https://issuetracker.google.com/u/2/issues/268356054#comment61 the relevant part from that comment, referring to the attached kernel patch= is: ``` the kernel side needs a bit more thought. i understand the argument being m= ade, but focusing purely on ACLs seems to discount the complexity of the attack. reading/writing to mem can be abused via arbitrary shell code execution, an= d is a way of bypassing verified boot (where only executable code in the rootfs = is permitted). having arbitrary shell code is often a lot easier to pull off t= han arbitrary syscalls which is what ptrace() access requires. our verified boot story makes arbitrary code exec much more difficult even if arbitrary shell code exec is possible (although that is something we've worked on restricti= ng too with some success). i don't know that, in CrOS, we'd ever want to allow writes to /proc/self/mem even if ptrace() is wide open. ``` --=20 You are receiving this mail because: You are on the CC list for the bug.=