On 02/07/14 at 03:20pm, H. Peter Anvin wrote:
> On 02/07/2014 03:16 PM, Dave Young wrote:
> >
> > Hi Vivek,
> >
> > Chaowang is looking into passing setup_data
> > SETUP_E820_EXT
> > instead of using exactmap. Previously Thomas Renninger tried passing them
> > in e820.
> > I did not find the
On 02/07/2014 03:16 PM, Dave Young wrote:
>
> Hi Vivek,
>
> Chaowang is looking into passing setup_data
> SETUP_E820_EXT
> instead of using exactmap. Previously Thomas Renninger tried passing them in
> e820.
> I did not find the old thread, but I remember it's not enough because of the
> 128
On 02/07/14 at 11:24am, Vivek Goyal wrote:
> On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote:
> > On 02/07/2014 06:49 AM, Vivek Goyal wrote:
> > >
> > > Hi Kees,
> > >
> > > Dave Young is testing kdump with kaslr enabled. He is facing some issues.
> > >
> > > One issue he
On Fri, Feb 7, 2014 at 11:07 AM, H. Peter Anvin wrote:
> On 02/07/2014 06:49 AM, Vivek Goyal wrote:
>>
>> As a workaround, Dave is currently using "nokaslr" command line parameter
>> for second kernel. He is still facing issues where makedumpfile segment
>> faults. He is looking into it further.
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
>
> As a workaround, Dave is currently using "nokaslr" command line parameter
> for second kernel. He is still facing issues where makedumpfile segment
> faults. He is looking into it further.
>
Now, let's state this: kaslr for kdump is almost
On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote:
> On 02/07/2014 06:49 AM, Vivek Goyal wrote:
> >
> > Hi Kees,
> >
> > Dave Young is testing kdump with kaslr enabled. He is facing some issues.
> >
> > One issue he mentioned is that when second kernel boots, it might be
> > placed
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
>
> Hi Kees,
>
> Dave Young is testing kdump with kaslr enabled. He is facing some issues.
>
> One issue he mentioned is that when second kernel boots, it might be
> placed in an area which is outside the reserved area for second kernel.
>
> We
On Fri, Jan 31, 2014 at 08:57:03AM -0800, Kees Cook wrote:
[..]
> I have no intention of that. Mentioned earlier in the thread, hiding
> it from root will be pretty ugly/hard/pointless:
> https://lkml.org/lkml/2014/1/27/287
> I would like to just keep the offset out of dmesg.
[ CC Dave Young ]
On Fri, Jan 31, 2014 at 08:57:03AM -0800, Kees Cook wrote:
[..]
I have no intention of that. Mentioned earlier in the thread, hiding
it from root will be pretty ugly/hard/pointless:
https://lkml.org/lkml/2014/1/27/287
I would like to just keep the offset out of dmesg.
[ CC Dave Young ]
Hi
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
Hi Kees,
Dave Young is testing kdump with kaslr enabled. He is facing some issues.
One issue he mentioned is that when second kernel boots, it might be
placed in an area which is outside the reserved area for second kernel.
We reserve a
On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote:
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
Hi Kees,
Dave Young is testing kdump with kaslr enabled. He is facing some issues.
One issue he mentioned is that when second kernel boots, it might be
placed in an area
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
As a workaround, Dave is currently using nokaslr command line parameter
for second kernel. He is still facing issues where makedumpfile segment
faults. He is looking into it further.
Now, let's state this: kaslr for kdump is almost certainly
On Fri, Feb 7, 2014 at 11:07 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
As a workaround, Dave is currently using nokaslr command line parameter
for second kernel. He is still facing issues where makedumpfile segment
faults. He is looking into it
On 02/07/14 at 11:24am, Vivek Goyal wrote:
On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote:
On 02/07/2014 06:49 AM, Vivek Goyal wrote:
Hi Kees,
Dave Young is testing kdump with kaslr enabled. He is facing some issues.
One issue he mentioned is that when
On 02/07/2014 03:16 PM, Dave Young wrote:
Hi Vivek,
Chaowang chaow...@redhat.com is looking into passing setup_data
SETUP_E820_EXT
instead of using exactmap. Previously Thomas Renninger tried passing them in
e820.
I did not find the old thread, but I remember it's not enough because of
On 02/07/14 at 03:20pm, H. Peter Anvin wrote:
On 02/07/2014 03:16 PM, Dave Young wrote:
Hi Vivek,
Chaowang chaow...@redhat.com is looking into passing setup_data
SETUP_E820_EXT
instead of using exactmap. Previously Thomas Renninger tried passing them
in e820.
I did not find
On Thu, Jan 30, 2014 at 2:07 PM, Vivek Goyal wrote:
> On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
>> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
>> >>
>> >> No, because that information is available to user space unless we panic.
>> >
>> > Didn't you mean non-root?
>> >
On Thu, Jan 30, 2014 at 2:07 PM, Vivek Goyal vgo...@redhat.com wrote:
On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
Didn't you mean non-root?
I
On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> >>
> >> No, because that information is available to user space unless we panic.
> >
> > Didn't you mean non-root?
> > I thought one has to set dmesg_restrict anyways if kASLR is
On Thu, Jan 30, 2014 at 1:23 AM, Ingo Molnar wrote:
>
> Well, if the consensus is that they help then we better make them
> correct in the KASLR case as well ...
In the kaslr case, the hex values cannot possibly help, since they are
meaningless due to the random offset (the external tools will
* Mathias Krause wrote:
> On 29 January 2014 09:11, Ingo Molnar wrote:
> >> But you can see that the symbol is perfectly fine:
> >>
> >> (gdb) list *(schedule+0x45)
> >
> > Oh, cool. Thanks for that trick - this will save me quite some time in
> > the future.
> >
> > So we can strip absolute
* Mathias Krause mini...@googlemail.com wrote:
On 29 January 2014 09:11, Ingo Molnar mi...@kernel.org wrote:
But you can see that the symbol is perfectly fine:
(gdb) list *(schedule+0x45)
Oh, cool. Thanks for that trick - this will save me quite some time in
the future.
So we
On Thu, Jan 30, 2014 at 1:23 AM, Ingo Molnar mi...@kernel.org wrote:
Well, if the consensus is that they help then we better make them
correct in the KASLR case as well ...
In the kaslr case, the hex values cannot possibly help, since they are
meaningless due to the random offset (the external
On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
Didn't you mean non-root?
I thought one has to set dmesg_restrict anyways if kASLR is used.
On Wed, Jan 29, 2014 at 09:25:05AM +0100, Ingo Molnar wrote:
> That would default to Y and would disable debuginfo by default.
>
> ( And yeah, it's a bit ugly, but it beats having to hack the kconfig
> language! )
Yeah, that could be another solution - I came up with another hack last
night:
On 29 January 2014 09:11, Ingo Molnar wrote:
>> But you can see that the symbol is perfectly fine:
>>
>> (gdb) list *(schedule+0x45)
>
> Oh, cool. Thanks for that trick - this will save me quite some time in
> the future.
>
> So we can strip absolute addresses just fine from oopses - cool.
>
>
* H. Peter Anvin wrote:
> On 01/28/2014 12:28 PM, Richard Weinberger wrote:
> > Am 28.01.2014 21:25, schrieb Linus Torvalds:
> >> On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
> >>>
> >>> Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
> >>> Something like:
> >>>
* Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar wrote:
> >
> > I really meant it when I said I build without debuginfo! :)
>
> Ok, but so what?
>
> As mentioned, nobody sane should build with DEBUG_INFO. But a normal
> vmlinux file has the symbol information even
* Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
I really meant it when I said I build without debuginfo! :)
Ok, but so what?
As mentioned, nobody sane should build with DEBUG_INFO. But a normal
vmlinux file
* H. Peter Anvin h...@zytor.com wrote:
On 01/28/2014 12:28 PM, Richard Weinberger wrote:
Am 28.01.2014 21:25, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something
On 29 January 2014 09:11, Ingo Molnar mi...@kernel.org wrote:
But you can see that the symbol is perfectly fine:
(gdb) list *(schedule+0x45)
Oh, cool. Thanks for that trick - this will save me quite some time in
the future.
So we can strip absolute addresses just fine from oopses - cool.
On Wed, Jan 29, 2014 at 09:25:05AM +0100, Ingo Molnar wrote:
That would default to Y and would disable debuginfo by default.
( And yeah, it's a bit ugly, but it beats having to hack the kconfig
language! )
Yeah, that could be another solution - I came up with another hack last
night:
On Tue, 2014-01-28 at 16:08 -0500, Dave Jones wrote:
> On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
> > >
> > > Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
> > > Something like:
> > >
>
On Tue, Jan 28, 2014 at 09:49:06PM +0100, Borislav Petkov wrote:
> On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
> > Probably. And then we should make sure that allyesconfig/allmodconfig
> > don't pick it.
>
> I'd need to think about that a bit longer as scripts/kconfig/conf.c
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
> >
> > Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
> > Something like:
> >
> > "You don't need to enable this if you want symbolic names for
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
> Probably. And then we should make sure that allyesconfig/allmodconfig
> don't pick it.
I'd need to think about that a bit longer as scripts/kconfig/conf.c goes
and sets those. Unless someone has a better idea...
> There *are*
On 01/28/2014 12:28 PM, Richard Weinberger wrote:
> Am 28.01.2014 21:25, schrieb Linus Torvalds:
>> On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
>>>
>>> Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
>>> Something like:
>>>
>>> "You don't need to enable this if
Am 28.01.2014 21:25, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
>>
>> Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
>> Something like:
>>
>> "You don't need to enable this if you want symbolic names for kernel
>> objects. Enable
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov wrote:
>
> Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
> Something like:
>
> "You don't need to enable this if you want symbolic names for kernel
> objects. Enable CONFIG_KALLSYMS instead."
Probably. And then we should
On Tue, Jan 28, 2014 at 12:07:26PM -0800, Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar wrote:
> >
> > I really meant it when I said I build without debuginfo! :)
>
> Ok, but so what?
>
> As mentioned, nobody sane should build with DEBUG_INFO.
Shouldn't we hold that
On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar wrote:
>
> I really meant it when I said I build without debuginfo! :)
Ok, but so what?
As mentioned, nobody sane should build with DEBUG_INFO. But a normal
vmlinux file has the symbol information even without it.
> So, when I build a kernel, such
* Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar wrote:
> >
> > Well, I often use the hex numbers to look them up and disassemble them
> > in a vmlinux via gdb and 'list *0x1234123412341234' - where the
> > vmlinux has no debuginfo. (Debuginfo takes longer to build so I
>
Am 28.01.2014 18:56, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger wrote:
>>
>> x/10i schedule+0x45 works.
>
> Ok, so it's just list that is braindamaged. Maybe it wants a
> *(schedule+0x45) or something. I dunno. You can obviously get the hex
> number from just
On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger wrote:
>
> x/10i schedule+0x45 works.
Ok, so it's just list that is braindamaged. Maybe it wants a
*(schedule+0x45) or something. I dunno. You can obviously get the hex
number from just doing "p schedule+0x45" and then do that.
Whatever. I
Am 28.01.2014 18:35, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger wrote:
>>
>> Hmm, my gdb does not like that notion.
>>
>> (gdb) list schedule+0x45
>> Function "schedule+0x45" not defined.
>
> I don't have a debug build, so maybe it's something specific to gdb
>
On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger wrote:
>
> Hmm, my gdb does not like that notion.
>
> (gdb) list schedule+0x45
> Function "schedule+0x45" not defined.
I don't have a debug build, so maybe it's something specific to gdb
actually seeing type information and then being
Am 28.01.2014 18:12, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar wrote:
>>
>> Well, I often use the hex numbers to look them up and disassemble them
>> in a vmlinux via gdb and 'list *0x1234123412341234' - where the
>> vmlinux has no debuginfo. (Debuginfo takes longer
On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar wrote:
>
> Well, I often use the hex numbers to look them up and disassemble them
> in a vmlinux via gdb and 'list *0x1234123412341234' - where the
> vmlinux has no debuginfo. (Debuginfo takes longer to build so I
> generally build without it.)
Why
* Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin wrote:
> >
> > I don't think there is any way to not break anything... we're
> > introducing a new kind of object ("normalized kernel pointer") here.
>
> I suspect we could just drop the addresses entirely if we have a
On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin wrote:
>
> I don't think there is any way to not break anything... we're
> introducing a new kind of object ("normalized kernel pointer") here.
I suspect we could just drop the addresses entirely if we have a
symbolic version. It's not like the hex
On 01/28/2014 08:25 AM, Richard Weinberger wrote:
>
> I fear both solutions will break various scripts.
> For example scripts/markup_oops.pl looks for \[\<([a-z0-9]+)\>\].
>
I don't think there is any way to not break anything... we're
introducing a new kind of object ("normalized kernel
Am 28.01.2014 16:55, schrieb H. Peter Anvin:
> On 01/28/2014 12:25 AM, Richard Weinberger wrote:
>>
>> Yep.
>> I like Ingo's idea (capital letters as indicators).
>> Are we all fine with that?
>>
>
> I guess it is extremely unlikely that we'd have a kernel address without
> any letters... the
On 01/28/2014 12:25 AM, Richard Weinberger wrote:
>
> Yep.
> I like Ingo's idea (capital letters as indicators).
> Are we all fine with that?
>
I guess it is extremely unlikely that we'd have a kernel address without
any letters... the "general solutions only please" part of my brain
wants to
Am 28.01.2014 07:28, schrieb Ingo Molnar:
>
> * Kees Cook wrote:
>
>> On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger wrote:
>>> Am 27.01.2014 18:05, schrieb Kees Cook:
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset
Am 28.01.2014 07:28, schrieb Ingo Molnar:
* Kees Cook keesc...@chromium.org wrote:
On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger rich...@nod.at wrote:
Am 27.01.2014 18:05, schrieb Kees Cook:
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is,
On 01/28/2014 12:25 AM, Richard Weinberger wrote:
Yep.
I like Ingo's idea (capital letters as indicators).
Are we all fine with that?
I guess it is extremely unlikely that we'd have a kernel address without
any letters... the general solutions only please part of my brain
wants to scream
Am 28.01.2014 16:55, schrieb H. Peter Anvin:
On 01/28/2014 12:25 AM, Richard Weinberger wrote:
Yep.
I like Ingo's idea (capital letters as indicators).
Are we all fine with that?
I guess it is extremely unlikely that we'd have a kernel address without
any letters... the general solutions
On 01/28/2014 08:25 AM, Richard Weinberger wrote:
I fear both solutions will break various scripts.
For example scripts/markup_oops.pl looks for \[\([a-z0-9]+)\\].
I don't think there is any way to not break anything... we're
introducing a new kind of object (normalized kernel pointer)
On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin h...@zytor.com wrote:
I don't think there is any way to not break anything... we're
introducing a new kind of object (normalized kernel pointer) here.
I suspect we could just drop the addresses entirely if we have a
symbolic version. It's not
* Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin h...@zytor.com wrote:
I don't think there is any way to not break anything... we're
introducing a new kind of object (normalized kernel pointer) here.
I suspect we could just drop the
On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar mi...@kernel.org wrote:
Well, I often use the hex numbers to look them up and disassemble them
in a vmlinux via gdb and 'list *0x1234123412341234' - where the
vmlinux has no debuginfo. (Debuginfo takes longer to build so I
generally build without
Am 28.01.2014 18:12, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar mi...@kernel.org wrote:
Well, I often use the hex numbers to look them up and disassemble them
in a vmlinux via gdb and 'list *0x1234123412341234' - where the
vmlinux has no debuginfo. (Debuginfo takes
On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger rich...@nod.at wrote:
Hmm, my gdb does not like that notion.
(gdb) list schedule+0x45
Function schedule+0x45 not defined.
I don't have a debug build, so maybe it's something specific to gdb
actually seeing type information and then being
Am 28.01.2014 18:35, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger rich...@nod.at wrote:
Hmm, my gdb does not like that notion.
(gdb) list schedule+0x45
Function schedule+0x45 not defined.
I don't have a debug build, so maybe it's something specific to gdb
On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger rich...@nod.at wrote:
x/10i schedule+0x45 works.
Ok, so it's just list that is braindamaged. Maybe it wants a
*(schedule+0x45) or something. I dunno. You can obviously get the hex
number from just doing p schedule+0x45 and then do that.
Am 28.01.2014 18:56, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger rich...@nod.at wrote:
x/10i schedule+0x45 works.
Ok, so it's just list that is braindamaged. Maybe it wants a
*(schedule+0x45) or something. I dunno. You can obviously get the hex
number from
* Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar mi...@kernel.org wrote:
Well, I often use the hex numbers to look them up and disassemble them
in a vmlinux via gdb and 'list *0x1234123412341234' - where the
vmlinux has no debuginfo.
On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
I really meant it when I said I build without debuginfo! :)
Ok, but so what?
As mentioned, nobody sane should build with DEBUG_INFO. But a normal
vmlinux file has the symbol information even without it.
So, when I build a
On Tue, Jan 28, 2014 at 12:07:26PM -0800, Linus Torvalds wrote:
On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
I really meant it when I said I build without debuginfo! :)
Ok, but so what?
As mentioned, nobody sane should build with DEBUG_INFO.
Shouldn't we hold
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something like:
You don't need to enable this if you want symbolic names for kernel
objects. Enable CONFIG_KALLSYMS instead.
Probably. And then we
Am 28.01.2014 21:25, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something like:
You don't need to enable this if you want symbolic names for kernel
objects. Enable
On 01/28/2014 12:28 PM, Richard Weinberger wrote:
Am 28.01.2014 21:25, schrieb Linus Torvalds:
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something like:
You don't need to enable this if you
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
Probably. And then we should make sure that allyesconfig/allmodconfig
don't pick it.
I'd need to think about that a bit longer as scripts/kconfig/conf.c goes
and sets those. Unless someone has a better idea...
There *are*
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something like:
You don't need to enable this if you want symbolic names for
On Tue, Jan 28, 2014 at 09:49:06PM +0100, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
Probably. And then we should make sure that allyesconfig/allmodconfig
don't pick it.
I'd need to think about that a bit longer as scripts/kconfig/conf.c goes
On Tue, 2014-01-28 at 16:08 -0500, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov b...@alien8.de wrote:
Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
Something like:
* Kees Cook wrote:
> On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger wrote:
> > Am 27.01.2014 18:05, schrieb Kees Cook:
> >> I would argue that decoding a non-panic oops on a running system is
> >> entirely possible as-is, since the offset can be found from
> >> /proc/kallsyms as root. It
Am 27.01.2014 18:05, schrieb Kees Cook:
> I would argue that decoding a non-panic oops on a running system is
> entirely possible as-is, since the offset can be found from
> /proc/kallsyms as root. It was the dead system that needed the offset
> exported: via text in the panic, or via an ELF note
On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger wrote:
> Am 27.01.2014 18:05, schrieb Kees Cook:
>> I would argue that decoding a non-panic oops on a running system is
>> entirely possible as-is, since the offset can be found from
>> /proc/kallsyms as root. It was the dead system that needed
On Sun, Jan 26, 2014 at 10:49 PM, Richard Weinberger
wrote:
> On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin wrote:
>> On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>>>
>>> Currently we print the kernel offset only upon a panic() using the
>>> panic notifier list.
>>> This way it does not
Am 27.01.2014 08:38, schrieb Ingo Molnar:
>
> * H. Peter Anvin wrote:
>
>> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
>>>
>>> Didn't you mean non-root?
>>> I thought one has to set dmesg_restrict anyways
Am 27.01.2014 08:38, schrieb Ingo Molnar:
* H. Peter Anvin h...@zytor.com wrote:
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
Didn't you mean non-root?
I thought one has to set dmesg_restrict anyways if kASLR
On Sun, Jan 26, 2014 at 10:49 PM, Richard Weinberger
richard.weinber...@gmail.com wrote:
On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 01/26/2014 02:16 AM, Richard Weinberger wrote:
Currently we print the kernel offset only upon a panic() using the
panic
On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger rich...@nod.at wrote:
Am 27.01.2014 18:05, schrieb Kees Cook:
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset can be found from
/proc/kallsyms as root. It was the dead system that
Am 27.01.2014 18:05, schrieb Kees Cook:
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset can be found from
/proc/kallsyms as root. It was the dead system that needed the offset
exported: via text in the panic, or via an ELF note in a
* Kees Cook keesc...@chromium.org wrote:
On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger rich...@nod.at wrote:
Am 27.01.2014 18:05, schrieb Kees Cook:
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset can be found from
* Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
> > On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> > >>
> > >> No, because that information is available to user space unless we panic.
> > >
> > > Didn't you mean non-root?
> > > I thought one has to set dmesg_restrict anyways if
* H. Peter Anvin wrote:
> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> >>
> >> No, because that information is available to user space unless we panic.
> >
> > Didn't you mean non-root?
> > I thought one has to set dmesg_restrict anyways if kASLR is used.
> >
> > And isn't the offset
Am 27.01.2014 07:52, schrieb H. Peter Anvin:
> Of course, stack traces themselves contain that information, so one
> could argue that oops=panic is required in order for kASLR to provide
> any kind of security against root. (oops=panic is probably a good idea
> in secure environments anyway...)
Of course, stack traces themselves contain that information, so one
could argue that oops=panic is required in order for kASLR to provide
any kind of security against root. (oops=panic is probably a good idea
in secure environments anyway...)
-hpa
--
To unsubscribe from this list: send
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
>>
>> No, because that information is available to user space unless we panic.
>
> Didn't you mean non-root?
> I thought one has to set dmesg_restrict anyways if kASLR is used.
>
> And isn't the offset available to perf too?
> Of course only for
On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin wrote:
> On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>>
>> Currently we print the kernel offset only upon a panic() using the
>> panic notifier list.
>> This way it does not show up if the kernel hits a BUG() in process
>> context or something
On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>
> Currently we print the kernel offset only upon a panic() using the
> panic notifier list.
> This way it does not show up if the kernel hits a BUG() in process
> context or something less critical.
> Wouldn't make more sense to report the
On Mon, Jan 20, 2014 at 5:47 PM, H. Peter Anvin wrote:
> Hi Linus,
>
> This enables kernel address space randomization for x86.
>
> The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
>
> Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
>
> are available in the git repository
On Mon, Jan 20, 2014 at 5:47 PM, H. Peter Anvin h...@zytor.com wrote:
Hi Linus,
This enables kernel address space randomization for x86.
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git
On 01/26/2014 02:16 AM, Richard Weinberger wrote:
Currently we print the kernel offset only upon a panic() using the
panic notifier list.
This way it does not show up if the kernel hits a BUG() in process
context or something less critical.
Wouldn't make more sense to report the offset in
On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 01/26/2014 02:16 AM, Richard Weinberger wrote:
Currently we print the kernel offset only upon a panic() using the
panic notifier list.
This way it does not show up if the kernel hits a BUG() in process
context or
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
Didn't you mean non-root?
I thought one has to set dmesg_restrict anyways if kASLR is used.
And isn't the offset available to perf too?
Of course only for root, but
Of course, stack traces themselves contain that information, so one
could argue that oops=panic is required in order for kASLR to provide
any kind of security against root. (oops=panic is probably a good idea
in secure environments anyway...)
-hpa
--
To unsubscribe from this list: send
Am 27.01.2014 07:52, schrieb H. Peter Anvin:
Of course, stack traces themselves contain that information, so one
could argue that oops=panic is required in order for kASLR to provide
any kind of security against root. (oops=panic is probably a good idea
in secure environments anyway...)
Now
1 - 100 of 140 matches
Mail list logo
