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: <f8e85a6bf8890b1e9c5d3e61e1ffde23.squirrel@webmail.greenhost.nl>
Date:	Fri, 20 Jan 2012 03:02:03 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Jamie Lokier" <jamie@...reable.org>,
	"Andi Kleen" <andi@...stfloor.org>, "Martin Mares" <mj@....cz>,
	"Andi Kleen" <ak@...ux.intel.com>,
	"Andrew Lutomirski" <luto@....edu>,
	"Oleg Nesterov" <oleg@...hat.com>,
	"Will Drewry" <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi,
	viro@...iv.linux.org.uk, mingo@...e.hu, akpm@...ux-foundation.org,
	khilman@...com, borislav.petkov@....com, amwang@...hat.com,
	eric.dumazet@...il.com, gregkh@...e.de, dhowells@...hat.com,
	daniel.lezcano@...e.fr, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com,
	"Roland McGrath" <mcgrathr@...omium.org>
Subject: Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re:
 [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

On Fri, January 20, 2012 01:53, Linus Torvalds wrote:
> On Thu, Jan 19, 2012 at 4:21 PM, Indan Zupancic <indan@....nu> wrote:
>>
>> With current ptrace you can do exactly that. It's just very slow, because
>> you have to copy the data word by word via PTRACE_PEEKDATA. But if Linux
>> would support something like BSD's PT_IO ptrace request, then it could be
>> limited to one extra ptrace command. (PTRACE_STRNCPY would be handy.)
>
> Actually, you could use the new "process_vm_readv/writev()" system
> calls. No need to do the crazy slow ptrace stuff.

Oh wow, that's great! I tried pread on /proc/$PID/mem before, but that
didn't work for some reason and would eat many fd's if there were a lot
of prisoners.

When did it got merged?

> I dunno. It got merged through Andrew, and the code looks sane, but
> I've never actually seen anybody *use* it. So maybe there is something
> wrong there. And no, it doesn't have a "strncpy" interface, I'm
> afraid.

My main problem is that I don't know beforehand how much I have to read,
and if I always reada fixed amount it may go across a page border and
error out. So if process_vm_readv() reads the accessible data only and
doesn't give up halfway, it's perfect. That seems to be the behaviour,
but the manpage is fuzzy enough that it may not be true. I'll take a
look at the source later.

Thanks,

Indan


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ