From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sat, 04 Jan 2025 11:29:46 +0000 Message-ID: <871pxiizrq.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21716"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75322@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 12:31:18 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tU2NC-0005UZ-7w for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 12:31:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU2N0-00087I-P5; Sat, 04 Jan 2025 06:31:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU2Mx-000872-1X for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:31:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tU2Mw-0008RI-Cz for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:31:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=WHjIZ0W4ASWbmuLrZY/mLmM3BlcBK1YldQpbKYwDHMI=; b=tX2Lz75+dMGhMnTKqixVlodtJTdSkj47AHz/vGjrVBx1A9VfUizuBqEtuWQUJyKsCSe036+0OqqtdDKUYZ7jf5LGDrCEzti4hB1L8xSghfkMPoh+FmxDXdHWJG31IEQbwrlaD4y2pRFC1SUawStJyfraTu8XxIjk23rMnH++4nYc1n95HL1INVZXGrMV78dGrf0wAI+2tfbt+xl7lV8mW2sBgcSSve/n65b7uuQlKX+4qr5tJ3HTV1OZn+6X5UORwicRZ95V5wERPzNhb/RIjWhjLftCZGDpAPwb95rhQrszFKD1C5j9QKeZ7bKsaF9uQ3jPbIAfWrMLDvG4iNiEDQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU2Mw-0002cY-7H for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2025 11:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.17359902049561 (code B ref 75322); Sat, 04 Jan 2025 11:31:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 11:30:04 +0000 Original-Received: from localhost ([127.0.0.1]:53585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU2Ly-0002Tq-Tg for submit@debbugs.gnu.org; Sat, 04 Jan 2025 06:30:04 -0500 Original-Received: from mail-10629.protonmail.ch ([79.135.106.29]:37219) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU2Lv-0002T2-4P for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 06:30:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735990190; x=1736249390; bh=WHjIZ0W4ASWbmuLrZY/mLmM3BlcBK1YldQpbKYwDHMI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=T4eubTgPFhKwuenAOut7DillSXmZMPnFlugxnx7IWJzzITf4pF26OoVVA11oIeVMg jHxjjaKbx7EO56llQUEJ7tvQ0o1Any2ekTXaRICOM911ocVI6w60fgKkRKILQP6Iqp +rfwiH44cK782io769yf8a9sy7bmCuzSShPn8iPxZqlTcmmBHIYtqd/KNb8uH6eoeF 6t9iDUOXDRHEX4f6E4ZNHDzGjMyr+xoHMp5oouYTYnFazQDlSuyVmM7VSBE1/s2m2Q OIiIiLusehGmmLp8vCsHiu2S+RainkArpBZ43HBfsa/gE7peYJpR48vBLo6pWHslPQ o2TSIRQZHGfAw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ade87087739d1b037ae0d0db3b13d056b565bdd9 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298363 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> Gerd M=C3=B6llmann writes: >> >>> Gerd M=C3=B6llmann writes: >>> >>>> >>>> The pointers to string data case probably requires adding yet another >>>> macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >>>> possibly and exact one which would be good. >> >> Note that might still EFAULT if there's a memory barrier. I think. >> >> Do we really need to move all arguments to syscalls and libc functions >> which might use a syscall into non-MPS memory? That would be bad. >> >> And which libc functions might use a syscall? I think we can agree >> fprintf might, and memcpy() doesn't (note to self: destroy all evidence >> I ever considered making memcpy() use MMU tricks for very large >> buffers), but what about all the others? >> >> Maybe I'm panicking too much and fixing read/write/exec* is good >> enough? > > Don't Panic! Quote from The Hitchhiker's Guide to Emacs (non-NS edition) > :-). > TBH, I couldn't follow your thoughts above with the EFAULT, syscalls and > so on. My understanding is that if there is a memory barrier in place for a string that a syscall tries to access, we get an -EFAULT from Linux, an EFAULT from glibc, and the syscall won't work. This is what makes valid_pointer_p work, for example. (To the extent it does: valid_pointer_p assumes 16 bytes after the pointer are readable; I don't see why that is true for small objects). What makes this more difficult is that glibc and GCC disagree about what to do with invalid pointers even in the simplest case: glibc documents printf ("%s\n", NULL) to work, but GCC will rewrite it into puts (NULL), which crashes. I'm worried that glibc might wrap a syscall incorrectly wrt EFAULT and SIGSEGV, in this case. Worse, if the syscall is in a fork()ed process, MPS machinery to remove the memory barrier might not be in place after the fork. And who knows about posix_spawn action descriptors? Or vfork? >>> Or one does it as you did in b0a209e9204, that's of course also safe. >>> For both old and new GC. (Don't remember if you mentioned it Pip, but >>> old GC moves string data as well, during string compaction, should GC >>> run). >> >> Ouch. Yes, I remember now. >> >> Pip > > And today I see you reverted that commit. Is there something wrong with > it? I couldn't see something wrong, and for me VALUE(no root) > > VALUE(exact) VALUE(ambig). There were two reasons for the revert: 1. Eli asked me not to push the change right after I pushed. I thought it would be best to restore the "before" state so we could discuss the solution. 2. For the non-MPS case, I rashly assumed it would be okay to remove the no-GC assumption that call_process apparently establishes (even though there is no comment saying so). I'm not sure what I would do now; the old code seems buggy to me because Fexpand_file_name can call Lisp, but that bug affects only argv, not envp. It may be best to fix the argv code but leave the envp code in its (once again) current fragile state, documenting precisely which assumptions are made there. > WRT Lisp_Object allocas, please tell if I should do that. Sorry, I don't understand. Lisp_Objects shouldn't be allocated with SAFE_ALLOCA, but allocating them with SAFE_ALLOCA_LISP_EXTRA is fine. Pointers to string data cannot currently be safely allocated with SAFE_ALLOCA, but I'm not sure whether SAFE_ALLOCA_AMBIGUOUS or SAFE_ALLOCA_EXACT_POINTER would be the right thing to do. Pip