linux-kernel - Re: [RFC v2 00/35] optimize cost of inter-process communication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <380a64b9-e796-4345-a9a0-cf70d0f6c26f@zytor.com>
Date: Tue, 3 Jun 2025 10:49:35 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Bo Li <libo.gcs85@...edance.com>, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
        luto@...nel.org, kees@...nel.org, akpm@...ux-foundation.org,
        david@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
        peterz@...radead.org
Cc: dietmar.eggemann@....com, acme@...nel.org, namhyung@...nel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
        kan.liang@...ux.intel.com, viro@...iv.linux.org.uk, brauner@...nel.org,
        jack@...e.cz, lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
        vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com, mhocko@...e.com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        vschneid@...hat.com, jannh@...gle.com, pfalcato@...e.de,
        riel@...riel.com, harry.yoo@...cle.com, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, duanxiongchun@...edance.com,
        yinhongbo@...edance.com, dengliang.1214@...edance.com,
        xieyongji@...edance.com, chaiwen.cc@...edance.com,
        songmuchun@...edance.com, yuanzhu@...edance.com,
        chengguozhu@...edance.com, sunjiadong.lff@...edance.com
Subject: Re: [RFC v2 00/35] optimize cost of inter-process communication

On 5/30/25 02:27, Bo Li wrote:
> Changelog:
> 
> v2:
> - Port the RPAL functions to the latest v6.15 kernel.
> - Add a supplementary introduction to the application scenarios and
>   security considerations of RPAL.
> 
> link to v1:
> https://lore.kernel.org/lkml/CAP2HCOmAkRVTci0ObtyW=3v6GFOrt9zCn2NwLUbZ+Di49xkBiw@mail.gmail.com/
> 

Okay,

First of all, I agree with most of the other reviewers that this is
insane. Second of all, calling this "optimize cost of inter-process
communication" is *extremely* misleading, to the point that one could
worry about it being malicious.

What you are doing is attempting to provide isolation between threads
running in the same memory space. *By definition* those are not processes.

Secondly, doing function calls from one thread to another in the same
memory space isn't really IPC at all, as the scheduler is not involved.

Third, this is something that should be possible to do entirely in user
space (mostly in a modified libc). Most of the facilities that you seem
to implement already have equivalents (/dev/shm, ET_DYN, ld.so, ...)

This isn't a new idea; this is where the microkernel people eventually
ended up when they tried to get performant. It didn't work well for the
same reason -- without involving the kernel (or dedicated hardware
facilities; x86 segments and MPK are *not* designed for this), the
isolation *can't* be enforced. You can, of course, have a kernel
interface to switch the address space around -- and you have just
(re)invented processes.

>From what I can see, a saner version of this would probably be something
like a sched_yield_to(X) system call, basically a request to the
scheduler "if possible, give the rest of my time slice to process/thread
<X>, as if I had been continuing to run." The rest of the communication
can be done with shared memory.

The other option is that if you actually are OK with your workloads
living in the same privilege domain to simply use threads.

If this somehow isn't what you're doing, and I (and others) have somehow
misread the intentions entirely, we will need a whole lot of additional
explanations.

	-hpa

	-hpa