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
