Deutsch   English   Français   Italiano  
<20250613084205.09e4fc9f@mateusz>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mateusz Viste <mateusz@x.invalid>
Newsgroups: comp.lang.c
Subject: Re: Memory protection between compilation units?
Date: Fri, 13 Jun 2025 08:42:05 +0200
Organization: ...
Lines: 21
Message-ID: <20250613084205.09e4fc9f@mateusz>
References: <20250611153239.6bc43323@mateusz>
	<20250612102857.1632c026@mateusz>
	<20250612114200.143@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 Jun 2025 08:42:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="be0ae288ae1b46b70a4e7a2b5ac6f308";
	logging-data="3444324"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19g0c+S6GhGEfL0fjR4Zt6v"
Cancel-Lock: sha1:1O8czPBcn1yVItUl5mUbFr6qzIA=
X-Newsreader: Claws Mail 4.2.0 (GTK 3.24.43; x86_64-suse-linux-gnu)

On Thu, 12 Jun 2025 18:59 Kaz Kylheku wrote:
> Below is a proof-of-concept program that works in GNU/Linux.  For
> rapidity of prototyping, I have assumed a page size of 4096; this is
> not right for all systems.

This is very cool! A variation of the classic "sentinel-guarded
memory" concept, where sentinels are write-protected rather than
requiring runtime checks against some magic signature.

Another potential strategy would be to safeguard the static array
itself, or any other data storage for that matter, immediately after the
legitimate code has finished using it. Then unprotect it only when
needed again. While this might not be a good performer for
high-frequency operations, it could be an interesting practice
for memory regions that are rarely modified.

man mprotect() suggests that it should be used only on mmap-ed memory,
but apparently under Linux it works with everything.

Mateusz