linux-kernel - [patch 00/18] remove nopage

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

Message-Id: <20071205071547.701344000@nick.local0.net>
Date:	Wed, 05 Dec 2007 18:15:47 +1100
From:	npiggin@...e.de
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org
Subject: [patch 00/18] remove nopage

This patchset removes the 'nopage' from the tree.

I've gone through all the drivers and converted them to use fault as best
I can. When using fault, I've also tried to use vmf->pgoff rather than the
virtual address to index the content (which is preferred). Mostly it has
been OK, but DRM is a bit difficult, as it seems to use vma->vm_pgoff as
a 2nd dimension of addressing, so it remains unconverted.

I've also done some other things while going through at the code...

Converted incorrect OOM returns to SIGBUS.  OOM should only be returned as a
result of a memory allocation failure. We will actually want the fault path OOM
handling to be unified with the normal OOM killing path in future, and so
OOMing when we should be SIGBUSing means the box will panic if panic_on_oom is
set, or it will oom-kill random processes before retrying the fault, etc.
SIGBUS means something like "physical address (ie. after translation) does not
exist", which is appropriate AFAIKS in all cases I've converted.

Got rid of some bogus looking "disallow mremap" checks that just check for
address > vma->vm_end. Presumably this is supposed to prevent an mremap
expanding the mapping outside the limit of the underlying resource, but
actually mremap will update vma->vm_end, and anyway this condition is already
checked in the page fault code. Others seem to get this right by checking the
underlying resource itself. Others don't seem to even care.

There looks like a fair number of corruption / security problems with mremap,
so I've done an audit of the tree and tried to plug them.

-- 

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