Not if we do it right, but there is a huge potential boot time penalty.
Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> On 04/05/2013 01:04 AM, Ingo Molnar wrote:
>> >
>> > Random runtime shuffling of the kernel image - is that possible
>with
>> > existing toolchains?
>> >
>>
>> Yes... t
* Borislav Petkov wrote:
> On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote:
> > I think it'd be perfectly ok for OOPS to print out the kernel base.
>
> Yeah, ok, this still would need some massaging of the oops output per
> script, but it shouldn't be a big problem.
Doesn't kalls
* H. Peter Anvin wrote:
> On 04/05/2013 01:04 AM, Ingo Molnar wrote:
> >
> > Random runtime shuffling of the kernel image - is that possible with
> > existing toolchains?
> >
>
> Yes... the question is how much work we'd be willing to go through to make it
> happen.
>
> One approach: the k
On Fri, Apr 05, 2013 at 04:18:49PM -0700, Kees Cook wrote:
> There is already a hook in the patch that prints the offset:
>
> +dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
> +{
> + pr_emerg("Kernel Offset: 0x%lx\n",
> +(unsigned long)&_text - __ST
On Fri, Apr 5, 2013 at 1:43 PM, Borislav Petkov wrote:
> On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote:
>> I think it'd be perfectly ok for OOPS to print out the kernel base.
>
> Yeah, ok, this still would need some massaging of the oops output per
> script, but it shouldn't be a b
On Fri, Apr 5, 2013 at 3:08 PM, H. Peter Anvin wrote:
> On 04/05/2013 03:06 PM, Julien Tinnes wrote:
>>
>> Speaking of IDT, and to capture some off-thread discussion here, we
>> should remember that the "SGDT" and "SIDT" instructions aren't
>> privileged on x86, so user-land can leak these out wit
On 04/05/2013 03:06 PM, Julien Tinnes wrote:
>
> Speaking of IDT, and to capture some off-thread discussion here, we
> should remember that the "SGDT" and "SIDT" instructions aren't
> privileged on x86, so user-land can leak these out without any way for
> the kernel to intercept that.
>
> Adding
On Fri, Apr 5, 2013 at 12:11 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
>> can be randomized at boot.
>>
>> This makes kernel vulnerabilities harder to reliably exploit, especially
>> from remote attacks and local p
On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote:
> I think it'd be perfectly ok for OOPS to print out the kernel base.
Yeah, ok, this still would need some massaging of the oops output per
script, but it shouldn't be a big problem.
Also, you probably need to make clear in the oops i
On 04/05/2013 01:19 PM, Yinghai Lu wrote:
> On Fri, Apr 5, 2013 at 1:05 PM, H. Peter Anvin wrote:
>
>> That makes zero difference, since the issue at hand is the *virtual*
>> addresses the kernel are running at. Currently, the 64-bit kernel
>> always runs at 0x8100 virtual. We can't
On Fri, Apr 5, 2013 at 1:05 PM, H. Peter Anvin wrote:
> That makes zero difference, since the issue at hand is the *virtual*
> addresses the kernel are running at. Currently, the 64-bit kernel
> always runs at 0x8100 virtual. We can't run out of
> arbitrary bits of the 64-bit addres
On Fri, Apr 5, 2013 at 7:49 AM, Borislav Petkov wrote:
> On Thu, Apr 04, 2013 at 01:07:35PM -0700, Kees Cook wrote:
>> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
>> can be randomized at boot.
>
> Right,
>
> if I'm reading this whole deal correctly, I have an issue wi
On 04/05/2013 01:01 PM, Yinghai Lu wrote:
> On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote:
>> I have to admit to being somewhat skeptical toward KASLR with only 8
>> bits of randomness. There are at least two potential ways of
>> dramatically increasing the available randomness:
>>
>> 1. a
On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote:
> I have to admit to being somewhat skeptical toward KASLR with only 8
> bits of randomness. There are at least two potential ways of
> dramatically increasing the available randomness:
>
> 1. actually compose the kernel of multiple independen
On 04/05/2013 01:04 AM, Ingo Molnar wrote:
>
> The cost of 64-bit RIPs is probably measurable both in cache footprint and
> in execution speed.
>
Well, "probably" usually translates to "worth measuring" to me.
> Random runtime shuffling of the kernel image - is that possible with
> existing t
On 04/05/2013 01:04 AM, Ingo Molnar wrote:
>
> Random runtime shuffling of the kernel image - is that possible with
> existing toolchains?
>
Yes... the question is how much work we'd be willing to go through to
make it happen.
One approach: the kernel already contains a linker -- used for modu
On Thu, Apr 04, 2013 at 01:07:35PM -0700, Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
Right,
if I'm reading this whole deal correctly, I have an issue with this
in the sense that if this thing is enabled by default and
On Thu, 4 Apr 2013, Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
>
> This makes kernel vulnerabilities harder to reliably exploit, especially
> from remote attacks and local processes in seccomp containers. Keeping
> the
* H. Peter Anvin wrote:
> I have to admit to being somewhat skeptical toward KASLR with only 8
> bits of randomness. There are at least two potential ways of
> dramatically increasing the available randomness:
>
> 1. actually compose the kernel of multiple independently relocatable
>piec
* Eric Northup wrote:
> On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
> > It seems to me that you are assuming that the attacker is targeting a
> > specific system, but a bot might as well target 256 different systems and
> > see what sticks...
>
> The alarm signal from the ones that
* Kees Cook wrote:
> +config RANDOMIZE_BASE_MAX_OFFSET
> + hex "Maximum ASLR offset allowed"
> + depends on RANDOMIZE_BASE
> + default "0x1000"
> + range 0x0 0x1000
> + ---help---
> + Determines the maximal offset in bytes that will be applied to the
> + ker
* Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
>
> This makes kernel vulnerabilities harder to reliably exploit, especially
> from remote attacks and local processes in seccomp containers. Keeping
> the location of ker
* Julien Tinnes wrote:
> On Thu, Apr 4, 2013 at 1:27 PM, H. Peter Anvin wrote:
> > On 04/04/2013 01:23 PM, Julien Tinnes wrote:
> >> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote:
> >>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
> On 04/04/2013 01:07 PM, Kees Cook wrote:
On 04/04/2013 01:47 PM, Eric Northup wrote:
>>
>> 1. actually compose the kernel of multiple independently relocatable
>>pieces (maybe chunk it on 2M boundaries or something.)
>
> Without increasing the entropy bits, does this actually increase the #
> of tries necessary for an attacker to gue
If an attacker targets multiple distinct systems across a wide range
of system owners, instead of landing the exploit against all of them,
they'll get less than 1% of them, and crash all the rest, removing
them (for a while) from the target pool. Without KASLR, they would
have landed 100% of the at
On Thu, Apr 4, 2013 at 2:01 PM, H. Peter Anvin wrote:
> What system monitoring? Most systems don't have much...
The security of an unmonitored system is going to be much lower than
of a well-monitored system. That's true independent of whether kASLR
is deployed.
>
> Kees Cook wrote:
>
>>On Th
On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
> It seems to me that you are assuming that the attacker is targeting a
> specific system, but a bot might as well target 256 different systems and see
> what sticks...
The alarm signal from the ones that don't stick is, in my opinion, the
p
What system monitoring? Most systems don't have much...
Kees Cook wrote:
>On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
>> It seems to me that you are assuming that the attacker is targeting a
>specific system, but a bot might as well target 256 different systems
>and see what sticks..
Natural evolution: when the cluster is the computer, kernel panics are
recoverable like segfaults in a multi-process OS.
You have a point and 8 bits isn't perfect, but it's already useful
regardless, in certain scenarios.
On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
> It seems to me tha
On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
> It seems to me that you are assuming that the attacker is targeting a
> specific system, but a bot might as well target 256 different systems and see
> what sticks...
Certainly, but system monitoring will show 255 crashed machines, which
i
It seems to me that you are assuming that the attacker is targeting a specific
system, but a bot might as well target 256 different systems and see what
sticks...
Kees Cook wrote:
>On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
>> On 04/04/2013 01:07 PM, Kees Cook wrote:
>>> However, t
On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
> On 04/04/2013 01:07 PM, Kees Cook wrote:
>> However, the benefits of
>> this feature in certain environments exceed the perceived weaknesses[2].
>
> Could you clarify?
I would summarize the discussion of KASLR weaknesses into to two
general
On Thu, Apr 4, 2013 at 1:27 PM, H. Peter Anvin wrote:
> On 04/04/2013 01:23 PM, Julien Tinnes wrote:
>> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote:
>>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
On 04/04/2013 01:07 PM, Kees Cook wrote:
> However, the benefits of
On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote:
> I have to admit to being somewhat skeptical toward KASLR with only 8
> bits of randomness.
I agree that 8 bits is pretty low and more would be better. However,
even 8 bits provides a < 1% chance that any particular guess will be
correct. C
On 04/04/2013 01:23 PM, Julien Tinnes wrote:
> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote:
>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
>>> On 04/04/2013 01:07 PM, Kees Cook wrote:
However, the benefits of
this feature in certain environments exceed the perceived we
On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote:
> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
>> On 04/04/2013 01:07 PM, Kees Cook wrote:
>>> However, the benefits of
>>> this feature in certain environments exceed the perceived weaknesses[2].
>>
>> Could you clarify?
>
> I think p
I have to admit to being somewhat skeptical toward KASLR with only 8
bits of randomness. There are at least two potential ways of
dramatically increasing the available randomness:
1. actually compose the kernel of multiple independently relocatable
pieces (maybe chunk it on 2M boundaries or so
On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
> On 04/04/2013 01:07 PM, Kees Cook wrote:
>> However, the benefits of
>> this feature in certain environments exceed the perceived weaknesses[2].
>
> Could you clarify?
I think privilege reduction in general, and sandboxing in particular,
can
On 04/04/2013 01:07 PM, Kees Cook wrote:
> However, the benefits of
> this feature in certain environments exceed the perceived weaknesses[2].
Could you clarify?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
can be randomized at boot.
This makes kernel vulnerabilities harder to reliably exploit, especially
from remote attacks and local processes in seccomp containers. Keeping
the location of kernel addresses secret becomes very
40 matches
Mail list logo
