| 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
| ||
|
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/
Powered by blists - more mailing lists