[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] enforced immutability - proposed research project

From: Bruno Haible
Subject: Re: [Tinycc-devel] enforced immutability - proposed research project
Date: Mon, 18 Jan 2021 22:53:00 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; )

Michael Matz wrote:
> ... you also need to invalidate all _copies_ of wp:
>    wp = malloc(); init(wp);
>    p = freeze(wp);
>    globalp->foo = ...;  // should be disallowed
> where init(wp) is something like:
>     struct S *globalp;
>     void init(struct S *x) { x->foo = 1; globalp = x; }

This is a perfectly valid code, with no "bad" cast. I would say that
assigning to globalp->foo should be allowed.

Many programs don't make copies of wp. The typical idiom is that the
function that allocates an object also fills it and selectively stores or
returns writable and read-only views to the object. Enforced immutability
should only verify that some code that received a read-only pointer does
not do a write access.

> Doing things at runtime also isn't super-easy: you either waste full pages 
> for each allocation, no matter how small (in order to write-protect them 
> at freeze), or you need to copy contents around (to write-controlled 
> areas) invalidating addresses already pointing to it, or you need to do 
> checked-writes for each memory write.

The cited implementation (immutable.h, immutable.c) does none of these.
Each allocation uses only a few percent of additional memory (like a normal
malloc()). It does not copy contents around. And it does not require
checked writes in software; it delegates this checking to the hardware
(the MMU).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]