On Sun, Dec 22, 2024 at 1:45 PM Samuel Thibault wrote:
> > 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
Diego Nieto Cid, le dim. 22 déc. 2024 16:19:08 -0300, a ecrit:
> On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
> > 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 th
Hello,
On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
>
> 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'v
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
On Sun, Dec 22, 2024 at 6:11 AM Diego Nieto Cid wrote:
> I just didn't understand the hard/soft limits. It's better described
> by the structure members and not the comments:
>
> struct rlimit {
> rlim_t rlim_cur; /* Soft limit */
> rlim_t rlim_max; /* Hard limit (ceiling for
Hi,
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:
struct rlimit {
rlim_t rlim_cur; /* Soft limit */
Hello,
Diego Nieto Cid, le jeu. 19 déc. 2024 12:47:50 -0300, a ecrit:
> After playing a bit with the setrlimit calls in Linux to see how the
> resource RLIMIT_AS actually works, it seems to be limiting the amount
> of virtual memory available to the process (and not the available
> virtual address
Hi,
On Sat, Dec 21, 2024 at 10:06:10PM +0300, Sergey Bugaev wrote:
>
> In case you don't realize, there's more than one kernel map.
> kernel_map is the main one, but there are also ipc_kernel_map and
> device_io_map, which are submaps of kernel_map, and others could
> potentially be added.
>
> T
On Fri, Dec 20, 2024 at 5:17 PM Diego Nieto Cid wrote:
> >Also make sure to avoid limiting the kernel's own maps.
>
> Oh right, I need to check for the kernel map, even though the default
> means no limit it may be nice to check at the enforcing point whether
> the allocation happens against the k
Hello,
On Fri, Dec 20, 2024 at 12:18:36PM +0300, Sergey Bugaev wrote:
> On Thu, Dec 19, 2024 at 6:56 PM Diego Nieto Cid wrote:
> > I thought of adding an RPC call that sets the `hard_limit` field
> > which, I guess, should be located among the other task related RPCs.
>
> Indeed, this could be s
Hi,
On Fri, Dec 20, 2024 at 10:25:02AM +0100, Luca wrote:
>
> 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
>
Yes I'm on x86_64, it looks like that's the allocation.
>
> I think the on
Il 20/12/24 02:54, Diego Nieto Cid ha scritto:
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
Il 19/12/24 23:54, Diego Nieto Cid ha scritto:
On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
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 i
On Thu, Dec 19, 2024 at 6:56 PM Diego Nieto Cid wrote:
> Hello,
Hi,
a few pointers from me:
> I started with hard limit beacause I still need to research how
> soft limits work. So, for now, it's a plain rejection with ENOMEM.
>
> 2. At vm_map_setup, initialize the `hard_limit` fiel
Hi,
I've been testing RLIMIT_DATA...
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 usi
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
Hi,
Il 19/12/24 16:47, Diego Nieto Cid ha scritto:
Hello,
After playing a bit with the setrlimit calls in Linux to see how the
resource RLIMIT_AS actually works, it seems to be limiting the amount
of virtual memory available to the process (and not the available
virtual address range).
I see
17 matches
Mail list logo
