On Mon, May 19, 2014 at 12:27:29PM +0400, Pavel Emelyanov wrote:
> >
> > What happens if you try to checkpoint a program that's in the vdso or,
> > worse, in a signal frame with the vdso on the stack?
>
> Nothing good, unfortunately :( And this is one of the things we're
> investigating.
> Cyril
On 05/15/2014 11:42 PM, Andy Lutomirski wrote:
> On May 14, 2014 8:36 PM, "Pavel Emelyanov" wrote:
>>
>> On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
>>> On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> On Wed, M
On Fri, May 16, 2014 at 03:40:48PM -0700, Andy Lutomirski wrote:
> >>
> >> There are other ways how to find where additional pages are laying but it
> >> would be great if there a straightforward interface for that (ie some mark
> >> in /proc/pid/maps output).
> >
> > I'll try to write a patch in t
On 05/16/2014 03:40 PM, Andy Lutomirski wrote:
>
> My current draft is here:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups
>
> On 64-bit userspace, it results in:
>
> 7fffa1dfd000-7fffa1dfe000 r-xp 00:00 0
> [vdso]
> 7fff
On Thu, May 15, 2014 at 3:15 PM, Andy Lutomirski wrote:
> On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov wrote:
>> On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
>>> >
>>> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
>>> > variables
>>> > be kind
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov wrote:
> On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
>> >
>> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
>> > variables
>> > be kind of immutable constants? If yes, we could calculate where the
>>
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
> >
> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
> > variables
> > be kind of immutable constants? If yes, we could calculate where the
> > additional
> > vma lives without requiring any kind of [vdso]
On Thu, May 15, 2014 at 2:31 PM, Cyrill Gorcunov wrote:
> On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
>>
>> I see what you mean. We're rather targeting on bare x86-64 at the moment
>> but compat mode is needed as well (not yet implemented though). I'll take
>> a precise look i
On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
>
> I see what you mean. We're rather targeting on bare x86-64 at the moment
> but compat mode is needed as well (not yet implemented though). I'll take
> a precise look into this area. Thanks!
Indeed, because we were not running 32
On Thu, May 15, 2014 at 12:59:04PM -0700, Andy Lutomirski wrote:
> >>
> >> What version and bitness is this?
> >
> > x86-64, 3.15-rc5
>
> Aha. Give tip/x86/vdso or -next a try or boot a 32-bit 3.15-rc kernel
> and you'll see it.
I see what you mean. We're rather targeting on bare x86-64 at the m
On Thu, May 15, 2014 at 12:53 PM, Cyrill Gorcunov wrote:
> On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
>> On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
>> > On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
>> >> I can summarize:
>> >>
>> >> On 3.14 a
On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
> On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
> > On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
> >> I can summarize:
> >>
> >> On 3.14 and before, the vdso is just a bunch of ELF headers and
> >> execu
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
> On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
>> I can summarize:
>>
>> On 3.14 and before, the vdso is just a bunch of ELF headers and
>> executable data. When executed by 64-bit binaries, it reads from the
>> fixmap to
On May 14, 2014 8:36 PM, "Pavel Emelyanov" wrote:
>
> On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
> > On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
> >> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> >>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
> >>> wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
> I can summarize:
>
> On 3.14 and before, the vdso is just a bunch of ELF headers and
> executable data. When executed by 64-bit binaries, it reads from the
> fixmap to do its thing. That is, it reads from kernel addresses that
>
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
> On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
>> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
>>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
>>> wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
wro
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
>
>> > In my linux-next all that code got deleted by Andy's "x86, vdso:
>> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
>> > were you looking at?
>>
>> Deleted?
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
>> wrote:
>> > On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
>> > wrote:
>> >
>> >> > In my linux-next all that code got
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
> wrote:
> > On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
> > wrote:
> >
> >> > In my linux-next all that code got deleted by Andy's "x86, vdso:
> >> > Reimplement vdso.so preparat
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
>
>> > In my linux-next all that code got deleted by Andy's "x86, vdso:
>> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
>> > were you looking at?
>>
>> Deleted?
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
> > In my linux-next all that code got deleted by Andy's "x86, vdso:
> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
> > were you looking at?
>
> Deleted? It appears in today's -next. arch/x86/vdso/vma.c:124 .
>
> I
On Wed, May 14, 2014 at 2:03 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
>
>> On 05/14/2014 04:23 PM, Andrew Morton wrote:
>> > On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
>> > wrote:
>> >
>> >> Hi all,
>> >>
>> >> While fuzzing with trinity inside a KVM
On 05/14/2014 05:03 PM, Andrew Morton wrote:
> On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
>
>> On 05/14/2014 04:23 PM, Andrew Morton wrote:
>>> On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
>>> wrote:
>>>
Hi all,
While fuzzing with trinity inside a KVM tools guest run
On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
> On 05/14/2014 04:23 PM, Andrew Morton wrote:
> > On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
> > wrote:
> >
> >> Hi all,
> >>
> >> While fuzzing with trinity inside a KVM tools guest running the latest
> >> -next
> >> kernel I've stum
On 05/14/2014 04:23 PM, Andrew Morton wrote:
> On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin wrote:
>
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel I've stumbled on the following spew:
>>
>> [ 1634.969408] BUG: unable to handle kernel NUL
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
>
> [ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [ 1634
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1634.970538] IP: special_mapping_fault (mm/mmap.c:2961)
[ 1634.971420] PGD 3
27 matches
Mail list logo
