Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Memory protection between compilation units?
Date: Sat, 14 Jun 2025 02:10:13 +0800
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <3de345c2bcf32d122addc3011bc6bdae15fa5a9c.camel@gmail.com>
References: <20250611153239.6bc43323@mateusz>
		<20250612102857.1632c026@mateusz>	<20250612114200.143@kylheku.com>
		<102gjib$39la2$1@dont-email.me> <20250613141420.25d81b43@mateusz>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 13 Jun 2025 20:10:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="304a1c71a32d3a5da8476aa61a8030f7";
	logging-data="3749742"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/T7eVPXAbUrIJus4mYIEiu"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:E3TjOQe/o/MDPKRyo/aEe1DsvHY=
In-Reply-To: <20250613141420.25d81b43@mateusz>

On Fri, 2025-06-13 at 14:14 +0200, Mateusz Viste wrote:
> On Fri, 13 Jun 2025 09:21 pozz wrote:
>=20
> > However this strategy assumes you already know there's some
> > instruction that write to the array at an out-of-bound position.
>=20
> Yes, though I see Kaz's idea is to proactively protect all memory used
> by the program. It's an interesting concept, though not particularly
> practical.
>=20
> > I think the situation of the original post is different. His program=
=20
> > crashed infrequently, very infrequently, and he didn't know anything=
=20
> > about the cause. I think it was a very big effort to link the crash
> > to the array (in another source module) and to the out-of-bound
> > access of the array.
>=20
> You are spot on indeed. Huge program with lots of modules, processing
> millions of data entries every minute. Realizing that the issue was an
> out of bounds situation was challenging because the symptoms were in a
> totally different part of the program. Very confusing.
>=20
> Hence why I was wondering if there is any way to make invalid memory
> accesses *within the same program* generate a segfault, so next time I
> have to deal with such self-sabotaging program I know at least which
> module (compilation unit) to look at. Since then I learned that:
> - There is no readily available mechanism for this today on x86

There will never be a cure for what you are looking for a 'auto range check=
'
Manually coding for out-of-range is the way to go.

> - CHERI shows great promise, possibly in the coming years
> - mprotect() can offer some degree of protection but must be used
> =C2=A0 carefully, as it primarily safeguards against writes in general ra=
ther
> =C2=A0 than restricting which parts of the code can access memory
>=20
> Mateusz