On Fri, Jan 23, 2015 at 3:07 AM, Kees Cook wrote:
> On Wed, Jan 21, 2015 at 5:24 PM, Roman Peniaev wrote:
>> On Thu, Jan 22, 2015 at 8:32 AM, Kees Cook wrote:
>>> On Tue, Jan 20, 2015 at 3:04 PM, Russell King - ARM Linux
>>> wrote:
[snip]
>>>
>>> Native ARM64 hides the restart from both seccomp
On Wed, Jan 21, 2015 at 5:24 PM, Roman Peniaev wrote:
> On Thu, Jan 22, 2015 at 8:32 AM, Kees Cook wrote:
>> On Tue, Jan 20, 2015 at 3:04 PM, Russell King - ARM Linux
>> wrote:
>>> On Tue, Jan 20, 2015 at 10:45:19PM +, Russell King - ARM Linux wrote:
Well, the whole question is this: is
On Thu, Jan 22, 2015 at 8:32 AM, Kees Cook wrote:
> On Tue, Jan 20, 2015 at 3:04 PM, Russell King - ARM Linux
> wrote:
>> On Tue, Jan 20, 2015 at 10:45:19PM +, Russell King - ARM Linux wrote:
>>> Well, the whole question is this: is restarting a system call like
>>> usleep() really a separate
On Tue, Jan 20, 2015 at 3:04 PM, Russell King - ARM Linux
wrote:
> On Tue, Jan 20, 2015 at 10:45:19PM +, Russell King - ARM Linux wrote:
>> Well, the whole question is this: is restarting a system call like
>> usleep() really a separate system call, or is it a kernel implementation
>> detail?
On Tue, Jan 20, 2015 at 10:45:19PM +, Russell King - ARM Linux wrote:
> Well, the whole question is this: is restarting a system call like
> usleep() really a separate system call, or is it a kernel implementation
> detail?
>
> If you wanted seccomp to see this, what would be the use case? Wh
On Tue, Jan 20, 2015 at 10:31:57AM -0800, Kees Cook wrote:
> On Mon, Jan 19, 2015 at 1:20 AM, Will Deacon wrote:
> > I'm fine either way for the native case, but we should stick with whetever
> > we end up with. Being compatible with ARM is probably a good idea. Do you
> > have a preference?
>
>
On Sun, Jan 18, 2015 at 9:58 PM, Roman Peniaev wrote:
> On Sat, Jan 17, 2015 at 8:54 AM, Kees Cook wrote:
>> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
>>> On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
>>> wrote:
On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev w
On Mon, Jan 19, 2015 at 1:20 AM, Will Deacon wrote:
> On Fri, Jan 16, 2015 at 11:54:45PM +, Kees Cook wrote:
>> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
>> > On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
>> > wrote:
>> >> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman
On Fri, Jan 16, 2015 at 11:54:45PM +, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
> > On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
> > wrote:
> >> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
> >>> On Sat, Jan 17, 2015 at 12:59 AM, Russ
On Sat, Jan 17, 2015 at 8:54 AM, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
>> On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
>> wrote:
>>> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
On Sat, Jan 17, 2015 at 12:59 AM, Russell King - A
On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
> wrote:
>> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
>>> On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
>>> wrote:
>>> > On Sat, Jan 17, 2015 at 12:57:
On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
wrote:
> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
>> On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
>> wrote:
>> > On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
>> >> On Fri, Jan 16, 2015
On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
> On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
> wrote:
> > On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
> >> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook wrote:
> >> > One interesting thing I noticed (wh
On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
wrote:
> On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
>> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook wrote:
>> > One interesting thing I noticed (which is unchanged by this series),
>> > but pulling ARM_r7 during the secc
On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook wrote:
> On Wed, Jan 14, 2015 at 5:54 PM, Roman Peniaev wrote:
>> On Thu, Jan 15, 2015 at 5:51 AM, Kees Cook wrote:
>>> On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
> On Sun, Jan 1
On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook wrote:
> > One interesting thing I noticed (which is unchanged by this series),
> > but pulling ARM_r7 during the seccomp ptrace event shows __NR_poll,
> > not __NR_restart_syscall, even tho
On Wed, Jan 14, 2015 at 5:54 PM, Roman Peniaev wrote:
> On Thu, Jan 15, 2015 at 5:51 AM, Kees Cook wrote:
>> On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
>>> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
> threa
On Thu, Jan 15, 2015 at 5:51 AM, Kees Cook wrote:
> On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
>> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
>>> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
thread_info->syscall is used only for ptrace, but syscall number
>
On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
>> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
>>> thread_info->syscall is used only for ptrace, but syscall number
>>> is also used by syscall_get_nr and returned to usersp
On Tue, Jan 13, 2015 at 5:35 PM, Roman Peniaev wrote:
> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
>> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
>>> thread_info->syscall is used only for ptrace, but syscall number
>>> is also used by syscall_get_nr and returned to userspa
On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
>> thread_info->syscall is used only for ptrace, but syscall number
>> is also used by syscall_get_nr and returned to userspace by the
>> following proc file access:
>>
>> $ cat /proc/
On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
> thread_info->syscall is used only for ptrace, but syscall number
> is also used by syscall_get_nr and returned to userspace by the
> following proc file access:
>
> $ cat /proc/self/syscall
> 0 0x3 0xbe928bd8 0x1000 0x0 0xac9e0 0x3 0xb
thread_info->syscall is used only for ptrace, but syscall number
is also used by syscall_get_nr and returned to userspace by the
following proc file access:
$ cat /proc/self/syscall
0 0x3 0xbe928bd8 0x1000 0x0 0xac9e0 0x3 0xbe928bb4 0xb6f5dfbc
^
The first number is the syscall number, currently
23 matches
Mail list logo