Date: Sat, 02 Aug 2025 15:27:07 -0700
> On Aug 2, 2025, at 3:22 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Saturday, 2 August 2025 13:34:03 Pacific Daylight Time connor horman via
> Std-Proposals wrote:
>> There is a way usually on an OS to determine whether or not a particular
>> address is mapped (linux, for example, you can examine `/proc/self/map`).
>
> Actually, no.
>
> It might tell you that accessing the memory won't produce a SIGSEGV (assuming
> you access it correctly), but you may still get a SIGBUS if this is a file-
> mapped memory and the file is too small. So you also need to have an open file
> handle to the file in question or a means to open one (/proc/self/map_files on
> Linux) so you can stat(2) it to find out if it is big enough.
I was also unsure about whether the info you get from that source allows you to distinguish
“mapped” from “mapped and readable”, “mapped and writable”? It sounds like you have
more familiarity with doing such queries (for my work I only ever need the darwin “is this
permanently readonly” check for root of trust checks).
> In a multithreaded application, any information you get about a pointer may be
> stale by the time you use it. And in a multi-process OS, any information you
> get about a file may also be stale, unless you have means to force a file not to
> shrink -- Linux only supports file sealing on memfds.
>
> Therefore, this is a TOCTOU problem. There's no reliable way to get the
> correct information cross-platform and there's no way make it reliable to use.
> And this was in no way what the OP was asking for.
It is also possible to have an access be valid on one thread but not on another, so
if you tried to use/cache a query on one thread and then reuse it on another it may
fail, even if you are doing it immediately.
—Oliver
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> On Saturday, 2 August 2025 13:34:03 Pacific Daylight Time connor horman via
> Std-Proposals wrote:
>> There is a way usually on an OS to determine whether or not a particular
>> address is mapped (linux, for example, you can examine `/proc/self/map`).
>
> Actually, no.
>
> It might tell you that accessing the memory won't produce a SIGSEGV (assuming
> you access it correctly), but you may still get a SIGBUS if this is a file-
> mapped memory and the file is too small. So you also need to have an open file
> handle to the file in question or a means to open one (/proc/self/map_files on
> Linux) so you can stat(2) it to find out if it is big enough.
I was also unsure about whether the info you get from that source allows you to distinguish
“mapped” from “mapped and readable”, “mapped and writable”? It sounds like you have
more familiarity with doing such queries (for my work I only ever need the darwin “is this
permanently readonly” check for root of trust checks).
> In a multithreaded application, any information you get about a pointer may be
> stale by the time you use it. And in a multi-process OS, any information you
> get about a file may also be stale, unless you have means to force a file not to
> shrink -- Linux only supports file sealing on memfds.
>
> Therefore, this is a TOCTOU problem. There's no reliable way to get the
> correct information cross-platform and there's no way make it reliable to use.
> And this was in no way what the OP was asking for.
It is also possible to have an access be valid on one thread but not on another, so
if you tried to use/cache a query on one thread and then reuse it on another it may
fail, even if you are doing it immediately.
—Oliver
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-02 22:27:23