linux-kernel - Re: [PATCH 5/5] ipc,msg: loosen check for full queue

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5373AF39.7030406@colorfullife.com>
Date:	Wed, 14 May 2014 20:00:25 +0200
From:	Manfred Spraul <manfred@...orfullife.com>
To:	Davidlohr Bueso <davidlohr@...com>, akpm@...ux-foundation.org
CC:	aswin@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] ipc,msg: loosen check for full queue

Hi Davidlohr, Hi Andrew,

On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
> When sending a message, we must guarantee that there will be
> enough room in the queue to add it, otherwise wait until space
> becomes available -- which requires blocking the calling task.
> Currently, this relies meeting both of the following conditions:
>
> (i) The new msg size + current size is lower than the queue's max size.
> (ii) The current amount of messages in the queue + 1 (this msg) is lower
>       than the queue's max size.
>
> While (i) is obvious and well documented in the msgsnd(2) manpage, the
> second one is far more ambiguous and does not serve the purpose, as we do
> not control the amount of messages in the queue (unlike posix queues do).
> Thus remove (ii) and loosen how we check for space.
I know that (ii) is undocumented and not part of SUS, but I think it is 
required:
Otherwise it would be possible to use up an infinite amount of locked 
memory by sending 0-byte messages.

I added it some long time ago, and at that time I didn't check what the 
other sysv msg implementation were doing.

 From a quick search:

FreeBSD:
- Optional: RACCT_MSGQQUEUED
- Always: The number of messages is limited due to a global array 
(limited to MSGTQL entries: array msghdrs, free list  free_msghdrs)

http://fxr.watson.org/fxr/source/kern/sysv_msg.c

Opensolaris:
- Also a limit of the number of messages:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L1166

- it appears that it is related to MSGTQL:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L652

I.e.: We cannot remove the check unless we add another mechanism that 
limits the number of messages.

--
     Manfred
--
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/