Diego Nieto Cid, le dim. 22 déc. 2024 00:11:09 -0300, a ecrit:
> On Sun, Dec 22, 2024 at 02:35:08AM +0100, Samuel Thibault wrote:
> >
> > What do you refer to by hard/soft?
> >
>
> I just didn't understand the hard/soft limits. It's better described
> by the structure members and not the comments:
Read the documentation, man setrlimit:
The soft limit is the value that the kernel enforces for the correspond-
ing resource. The hard limit acts as a ceiling for the soft limit: an
unprivileged process may set only its soft limit to a value in the range
from 0 up to the hard limit, and (irreversibly) lower its hard limit. A
privileged process (under Linux: one with the CAP_SYS_RESOURCE capabil-
ity in the initial user namespace) may make arbitrary changes to either
limit value.
or posix:
The rlim_cur member specifies the current or soft limit and the
rlim_max member specifies the maximum or hard limit. Soft limits may
be changed by a process to any value that is less than or equal to
the hard limit. A process may (irreversibly) lower its hard limit
to any value that is greater than or equal to the soft limit. Only
a process with appropriate privileges can raise a hard limit. Both
hard and soft limits can be changed in a single call to setrlimit()
subject to the constraints described above.
Sergey Bugaev, le dim. 22 déc. 2024 09:33:22 +0300, a ecrit:
> Hm so now that I think of it, it could make sense to enforce soft
> limits in userland,
But I don't think it'll really be easy from inside userland since you'd
have to intercept all vm_allocate etc. calls done by applications.
> if we care about "memory allocated" and not "size
> of address space" (because the latter is influenced by memory received
> in messages etc).
Here we really care about the latter. The potential to get memory
allocated (overcommit)
> You'd track the amount of memory allocated, increase
> it in mmap (when making anonymous or private mappings) and sbrk, and
> compare it with the soft value
> Maybe I'm describing the same thing as RLIMIT_DATA?
It looks so.
> The Linux man page
> says Linux applies it to mmap as well as sbrk since 4.7.
Uh? That doesn't make sense. Posix says
RLIMIT_DATA
This is the maximum size of a data segment of the process, in bytes.
It doesn't talk about mmaps.
> > Luca, le ven. 20 déc. 2024 10:25:02 +0100, a ecrit:
> > > are you working on x86_64? if yes, that could be the redzone configured
> > > here:
> > >
> > > https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/exec/exec.c#n1247
> >
> > That's indeed a very good candidate.
> >
> > One thing is: it's a VM_PROT_NONE/VM_PROT_NONE area. We wouldn't really
> > want to make such area account for RLIMIT_AS, as they are not meant to
> > store anything.
>
> This complicates a bit the accounting. I can keep a count of memory allocated
> whit that protection. But I supose I need to check for calls to `vm_protect`
> or
> its underlying implementation.
No, as mentioned in Sergey vm_protect cannot raise the max part, it's
cast in stone. Only vm_deallocate will be able to just remove that
mapping.
> > Even that patch shouldn't be needed nowadays: the support was commited
> > upstream, and it's only very old-built netdde/rumpdisk that would need the
> > debian patch.
>
> A small nuisance I'm getting is that the gnumach.gz I build from source
> does not have a proper verison and dpkg firends complain when regenerating
> GRUB configuration.
grub doesn't care about what's inside gnumach.gz. Just rename it to
gnumach-mine.gz and for grub it'll have "mine" version.
Sergey Bugaev, le dim. 22 déc. 2024 09:33:22 +0300, a ecrit:
> > > Yes, with the host port being an optional parameter for the case when
> > > the limit is getting requested to be increased.
> >
> > Great.
>
> FWIW, this means that the caller would be potentially sending the host
> priv port to someone who's not necessarily the kernel. That's fine if
> we're acting on mach_task_self (since if someone is interposing our
> task port, we can trust them), but not fine if we're a privileged
> server who's willing to raise the given task's memory allowance
> according to some policy.
Task ports are created only by task_create, so only managed by gnumach.
Privileges servers do trust that their task ports are indeed from that.
Samuel
