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 o
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 e
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 mentione
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 certainly
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 reserve
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 ]
H
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?
>> > 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 u
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 *n
* 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
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: http:
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.
>
> I
* 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 with
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 go
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 ker
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* reaso
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 you
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 CONFIG_
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 make
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 down
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 a
* 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 stil
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 confused..
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 to
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 the
* 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 pointer
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 "gen
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 sc
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 ca
* 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 w
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 i
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 t
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 sh
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 if
* 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 kASLR
* 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 av
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...)
N
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 t
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 r
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 offset
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 2014-01-20 14:54:12, Linus Torvalds wrote:
> So I pulled this, but one question:
>
> On Mon, Jan 20, 2014 at 8:47 AM, H. Peter Anvin wrote:
> > +config RANDOMIZE_BASE
> > + bool "Randomize the address of the kernel image"
> > + depends on RELOCATABLE
> > + depends on !HIB
On Tue, Jan 21, 2014 at 6:20 AM, H. Peter Anvin wrote:
> On 01/21/2014 01:00 AM, Peter Zijlstra wrote:
>>>
>>> So this is presumably something that needs to be fixed in perf?
>>
>> Where do we learn about the offset from userspace?
>
> Now this is tricky... if this offset is too easy to get it com
* H. Peter Anvin wrote:
> > The thing is, one of my first remarks on this whole KASLR series
> > was that tooling needs to work. I suggested that the kernel should
> > only expose non-randomized addresses and that all facilities need
> > to continue to 'just work' with those. That argument wa
On 01/21/2014 06:39 AM, Ingo Molnar wrote:
>>
>> Now this is tricky... if this offset is too easy to get it
>> completely defeats kASLR. On the other hand, I presume that if we
>> are exporting /proc/kcore we're not secure anyway. Kees, I assume
>> that in "secure" mode perf annotations simply
* H. Peter Anvin wrote:
> On 01/21/2014 01:00 AM, Peter Zijlstra wrote:
> >>
> >> So this is presumably something that needs to be fixed in perf?
> >
> > Where do we learn about the offset from userspace?
> >
>
> Now this is tricky... if this offset is too easy to get it
> completely defeats
On 01/21/2014 01:00 AM, Peter Zijlstra wrote:
>>
>> So this is presumably something that needs to be fixed in perf?
>
> Where do we learn about the offset from userspace?
>
Now this is tricky... if this offset is too easy to get it completely
defeats kASLR. On the other hand, I presume that if
On 01/21/2014 06:14 AM, Ingo Molnar wrote:
>
> Ah, I didn't mean to suggest that it's an old upstream feature: what I
> mean is that the KASLR patch is pretty old, and it has been deployed
> by the Chromium guys for quite some time, and by others?
>
> It was just never combined with perf live a
* H. Peter Anvin wrote:
> On 01/21/2014 06:03 AM, Ingo Molnar wrote:
> >
> > * H. Peter Anvin wrote:
> >
> >> On 01/21/2014 02:27 AM, Ingo Molnar wrote:
> >>>
> >>> Hm, live annotation of the kernel image is a relatively new perf
> >>> feature, and KASLR predated that (by years) - which woul
On 01/21/2014 06:03 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> On 01/21/2014 02:27 AM, Ingo Molnar wrote:
>>>
>>> Hm, live annotation of the kernel image is a relatively new perf
>>> feature, and KASLR predated that (by years) - which would at least in
>>> part explain why it went
* H. Peter Anvin wrote:
> On 01/21/2014 02:27 AM, Ingo Molnar wrote:
> >
> > Hm, live annotation of the kernel image is a relatively new perf
> > feature, and KASLR predated that (by years) - which would at least in
> > part explain why it went unnoticed. (Although it does not excuse the
> >
On 01/21/2014 02:27 AM, Ingo Molnar wrote:
>
> Hm, live annotation of the kernel image is a relatively new perf
> feature, and KASLR predated that (by years) - which would at least in
> part explain why it went unnoticed. (Although it does not excuse the
> lack of testing.)
>
kASLR is new, bu
* Linus Torvalds wrote:
> On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
> wrote:
> > So I pulled this, but one question:
>
> .. oh, and since I decided to test it, and was looking for problems:
> enabling kaslr breaks "perf". The *profile* looks fine, but the
> disassembly doesn't work.
>
On Mon, Jan 20, 2014 at 03:13:33PM -0800, H. Peter Anvin wrote:
> On 01/20/2014 03:12 PM, Linus Torvalds wrote:
> > On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
> > wrote:
> >> So I pulled this, but one question:
> >
> > .. oh, and since I decided to test it, and was looking for problems:
> >
On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
wrote:
> So I pulled this, but one question:
>
> On Mon, Jan 20, 2014 at 8:47 AM, H. Peter Anvin wrote:
>> +config RANDOMIZE_BASE
>> + bool "Randomize the address of the kernel image"
>> + depends on RELOCATABLE
>> + depends on !HI
On 01/20/2014 03:12 PM, Linus Torvalds wrote:
> On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
> wrote:
>> So I pulled this, but one question:
>
> .. oh, and since I decided to test it, and was looking for problems:
> enabling kaslr breaks "perf". The *profile* looks fine, but the
> disassembly
On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
wrote:
> So I pulled this, but one question:
.. oh, and since I decided to test it, and was looking for problems:
enabling kaslr breaks "perf". The *profile* looks fine, but the
disassembly doesn't work.
I'm not entirely surprised. I decided I want
On 01/20/2014 02:54 PM, Linus Torvalds wrote:
> So I pulled this, but one question:
>
> On Mon, Jan 20, 2014 at 8:47 AM, H. Peter Anvin wrote:
>> +config RANDOMIZE_BASE
>> + bool "Randomize the address of the kernel image"
>> + depends on RELOCATABLE
>> + depends on !HIBERNATION
So I pulled this, but one question:
On Mon, Jan 20, 2014 at 8:47 AM, H. Peter Anvin wrote:
> +config RANDOMIZE_BASE
> + bool "Randomize the address of the kernel image"
> + depends on RELOCATABLE
> + depends on !HIBERNATION
How fundamental is that "!HIBERNATION" issue? Right no
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 at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-k
70 matches
Mail list logo
