On 2016/5/31 21:40, Robin Murphy wrote:
> On 31/05/16 14:08, Russell King - ARM Linux wrote:
>> On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote:
>>> Arriving at read_kmem() with an offset representing a bogus kernel
>>> address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_
On 31/05/16 14:46, Catalin Marinas wrote:
On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote:
Arriving at read_kmem() with an offset representing a bogus kernel
address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user
faulting on the kernel-space read.
x86_64 happens to ge
On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote:
> Arriving at read_kmem() with an offset representing a bogus kernel
> address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user
> faulting on the kernel-space read.
>
> x86_64 happens to get away with this since the optimise
On 31/05/16 14:08, Russell King - ARM Linux wrote:
On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote:
Arriving at read_kmem() with an offset representing a bogus kernel
address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user
faulting on the kernel-space read.
x86_64 happ
On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote:
> Arriving at read_kmem() with an offset representing a bogus kernel
> address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user
> faulting on the kernel-space read.
>
> x86_64 happens to get away with this since the optimise
Arriving at read_kmem() with an offset representing a bogus kernel
address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user
faulting on the kernel-space read.
x86_64 happens to get away with this since the optimised implementation
uses "rep movs*", thus the user write (which is allowed
6 matches
Mail list logo