linux-kernel - Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu

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: <200907101256.13881.rgetz@blackfin.uclinux.org>
Date:	Fri, 10 Jul 2009 12:56:13 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"David Howells" <dhowells@...hat.com>
CC:	"Mike Frysinger" <vapier.adi@...il.com>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>
Subject: Re: truncate on MAP_SHARED files in ramfs filesystems on no-mmu

On Thu 9 Jul 2009 12:07, David Howells pondered:
> Note that it would be very easy to add (if such does not already exist)
> an LTP test that creates a file, expands it, maps it, shrinks it and then
> attempts to alter the removed part of the mapping in the expectation 
> of receiving a SIGBUS.
> 
> As it stands, such a test will work on MMU, but go wrong on NOMMU in a
> different way in these two cases.  With the current behaviour, the
> shrink request will be rejected, but the system will survive.  With your
> proposed behaviour, the system will potentially be wrecked.
> 
> The NOMMU situation behaves differently to the MMU situation in either
> case.

I guess what we were looking at - was the normal case of when userspace 
doesn't go wrong.

The kernel (today in noMMU) assumes the userspace is going to do something bad 
after it does the shrink - but for those people who are using things 
properly - it doesn't allow it to work at all.
--
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/