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

Powered by blists - more mailing lists