Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: John Savard <quadibloc@servername.invalid>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Mon, 10 Jun 2024 17:11:47 -0600
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <hp1f6jlmst27ddu0m13e4ti42bnv8c7nui@4ax.com>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <2ad84effd7f284445e0d8b90e0170f09@www.novabbs.org> <4fhb6jdpr1tlonfum9cccq9j1h2vrlo60j@4ax.com> <v45bfr$3rcpa$9@dont-email.me> <qhad6j5tluqudv4ibkdahri14u5bpfch7f@4ax.com> <47ca0814d4cb268763a6dab951f6c828@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 11 Jun 2024 01:11:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f752231138247ec5b6f53ce61cda1d0c";
	logging-data="722759"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Le/A4qajcGc9mYUTQmXPHni7XEc8ynZg="
Cancel-Lock: sha1:XRZtv9oWLU9mArEaJlmNbLhhCak=
X-Newsreader: Forte Free Agent 3.3/32.846
Bytes: 3057

On Mon, 10 Jun 2024 18:43:09 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>John Savard wrote:
>
>> On Sun, 9 Jun 2024 22:48:28 -0000 (UTC), Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote:
>
>>>And just as a further nitpick (if the above weren?t enough), what
>>> happens
>>> 
>>>if the ?file? your C compiler is writing to is in a RAM disk?
>
>> Well, the output could be stored with no problem, because while it's
>> on the RAM disk, it can't be executed. It has to be copied from the
>> RAM disk, into memory that's not pretending to be a disk, by the
>> loader. So this case doesn't change anything from the case of a real
>> disk.
>
>One can create a PTE pointing at that RAM disk page and then allow
>someone to execute it directly.
>OR
>One can copy it somewhere that has execute permission in a single
>instruction (MM = memory to memory move)
>
>Neither is any real burden to enabling execute.

I'm not claiming that locating code in a RAM disk would _prevent_ a
program from enabling its execution. Normally, though, that wouldn't
be done just because it would mess things up for the software that is
supposed to be in charge of reading and writing from the RAM disk if
anything else accessies it.

My point was entirely different. Just as a JIT compiler doesn't run
into issues because it writes code to memory, but because it writes
code to memory with the intent of executing it later - and enabling
both write and execute is restricted in the case of the sort of
security-focused system we're discussing - an ordinary compiler
writing to a RAM disk instead of a physical disk runs into no issues.

Writing code in memory is not an issue. Write can be enabled to
memory. Only enabling write and execute together is potentially
subject to restricions.

So the idea of a RAM disk doesn't change anything.

John Savard