Re: [RFC] Implementing RLIMIT_AS

[Diego Nieto Cid]

On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
> 
> I see that some limits (e.g. RLIMIT_DATA) are managed in glibc instead of
> gnumach, maybe this could be a simpler way to add some minimal support? I
> guess that one might overcome these limits by using directly the mach rpc or
> hijacking glibc, but it could be enough for some use cases.
>

I saw RLIMIT_DATA, but I couldn't make it limit anything :/ I have to
play a bit more with it.
 
> > 
> >       I tried a lower value, like 2GB, but some process is mapping
> >       4GB at once during boot and it just hangs when the allocation
> >       fails.
> 
> Which process is that?
> 

Its task name is `exec` and it's using vm_map. The log in question is:

    [vm_map] [task exec] map size: 0, requested size: 4294967296, hard limit: 
2147483648

> 
> One big point to address is how to enforce the ability to change this limit,
> e.g. an unprivileged task shouldn't be able to increase its own memory
> limit. You could reuse the host privileged port, but maybe it could make
> sense to have a dedicated one for resource limits?

Correct. To be honest, at this poit, I haven't thought about it. I was just
toying with a POC implementation. Having the host privileged port means being
root essentially, right?

But if a dedicated port would make sense it may be worth exploring this option.
Do you know somewhere to look at for inspiration?

> 
> One additional point would be at least in task_create(), I guess the new
> task would have the same restriction as the one creating it.
>

Yes, indeed. A quick look at kern/task.c shows I should check vm_map_fork:

    } else if (inherit_memory) {
        new_task->map = vm_map_fork(parent_task->map);

>
> To experiment I'd suggest creating a test program as the ones in the tests/
> folder in gnumach source, so you can try every single case and easily debug
> it. Currently they can only be run on GNU/Linux as they require qemu.
>

I will try to set one up. But, I have an unusual environment for a FLOSS
developer, hehe.

> > ----
> > 
> > Index: gnumach-1.8+git20240714/vm/vm_map.c
> 
> It would be better to create the patches from the git repository instead of
> the debian package, and then use git-format-patch and git-send-mail.
>

Sorry, I've fallen in the temptation of `dpkg-buildpackage` and friends :)
 
>> @@ -81,6 +81,12 @@ kern_return_t vm_allocate(
> >             *addr = trunc_page(*addr);
> >     size = round_page(size);
> > +   if (map->size + size > map->hard_limit)
> > +     {
> > +           printf("map size: %lu, requested size: %lu, hard limit: %lu\n", 
> > map->size, size, map->hard_limit);
> > +           return(KERN_NO_SPACE);
> > +     }
> > +
> 
> Beware of unsigned integer wrap, e.g. if size is very big (see [0] for
> example).
>

Ah right. That's a source of slippery bugs, indeed.

Thanks for the review