linux-kernel - Re: Using remap_pfn_range() to increase total_vm beyond RLIMIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4ADC7EDD.9030307@agilent.com>
Date:	Mon, 19 Oct 2009 07:59:41 -0700
From:	Earl Chew <earl_chew@...lent.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Using remap_pfn_range() to increase total_vm beyond RLIMIT_AS

Jeremy Fitzhardinge wrote:
>> I think this means that a device driver can map pages into
>> a process and thus effectively increase address space of
>> a process above and beyond the limit set by RLIMIT_AS.
> 
> I suspect this is justified because remap_pfn_range is generally
> (always?) used to map device memory, and other memory which isn't
> represented by struct pages, so it doesn't really count as real memory
> usage.

Well, perhaps not always.

http://lkml.org/lkml/2008/12/3/453

http://www.scs.ch/~frey/linux/memorymap.html

While DMA related activity is the most obvious reason a driver
might want to allocate memory and inject it into userspace,
I could imagine other reasons (though not necessarily good ones)
where it is more efficient to simply copy data to/from a buffer
shared with a driver.

In both the scenarios outlined, this would be real memory
and not simply IO space.

As to whether it's even justified for IO space, I'm uncertain.

The reference material at www.opengroup.org is not crystal clear:

http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html

> RLIMIT_AS
> This is the maximum size of a process' total available memory, in
> bytes. If this limit is exceeded, the malloc() and mmap() functions
> shall fail with errno set to [ENOMEM]. In addition, the automatic stack
> growth fails with the effects outlined above.

I think controlling the size of the address space of the process
is the intent (likely evidenced by the name RLIMIT_AS), but the
text only speaks of user space APIs malloc() and mmap(). The
text does hint that this should apply to other indirect
means of address space expansion by describing stack growth.

One could also regard memory injected by device drivers as mmap()
by other means.

Earl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/