On Mon, Apr 15, 2013 at 7:40 PM, H. Peter Anvin wrote:
> On 04/15/2013 07:31 PM, H. Peter Anvin wrote:
>>
>> I also am starting to think that this really would be done better being
>> integrated with the decompressor code, since that code already ends up
>> moving the code around... no reason to
Well... G is it's own problem (doing actively broken thinks for political
reasons), but the real issue mostly is that there are a lot of them simply
because there are a lot of ways one may want to load the kernel.
This is why things like decompression and the BIOS and EFI stubs are part of
* H. Peter Anvin wrote:
> No. Fixing one bootloader is almost impossible. Fixing them all is a
> Sisiphyean task.
It's a self inflicted wound really: if only we had a reference bootloader in
the
kernel tree, which we could fix. The effort that went into fixing various
bootloader
No. Fixing one bootloader is almost impossible. Fixing them all is a
Sisiphyean task.
Yinghai Lu wrote:
>On Mon, Apr 15, 2013 at 7:36 PM, H. Peter Anvin wrote:
>> On 04/15/2013 03:00 PM, Yinghai Lu wrote:
>>>
>>> looks you are trying redo the work for bootloader to pick loaded
>phys addr.
No. Fixing one bootloader is almost impossible. Fixing them all is a
Sisiphyean task.
Yinghai Lu ying...@kernel.org wrote:
On Mon, Apr 15, 2013 at 7:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 03:00 PM, Yinghai Lu wrote:
looks you are trying redo the work for bootloader to
* H. Peter Anvin h...@zytor.com wrote:
No. Fixing one bootloader is almost impossible. Fixing them all is a
Sisiphyean task.
It's a self inflicted wound really: if only we had a reference bootloader in
the
kernel tree, which we could fix. The effort that went into fixing various
Well... G is it's own problem (doing actively broken thinks for political
reasons), but the real issue mostly is that there are a lot of them simply
because there are a lot of ways one may want to load the kernel.
This is why things like decompression and the BIOS and EFI stubs are part of
On Mon, Apr 15, 2013 at 7:40 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 07:31 PM, H. Peter Anvin wrote:
I also am starting to think that this really would be done better being
integrated with the decompressor code, since that code already ends up
moving the code around... no
On Mon, Apr 15, 2013 at 7:36 PM, H. Peter Anvin wrote:
> On 04/15/2013 03:00 PM, Yinghai Lu wrote:
>>
>> looks you are trying redo the work for bootloader to pick loaded phys addr.
>>
>
> Well, that is exactly what they are doing. On top of that they also
> need to randomize the 64-bit virtual
On 04/15/2013 07:31 PM, H. Peter Anvin wrote:
>
> I also am starting to think that this really would be done better being
> integrated with the decompressor code, since that code already ends up
> moving the code around... no reason to do this again.
>
Another good reason to do this in the
On 04/15/2013 03:00 PM, Yinghai Lu wrote:
>
> looks you are trying redo the work for bootloader to pick loaded phys addr.
>
Well, that is exactly what they are doing. On top of that they also
need to randomize the 64-bit virtual mapping.
I wonder if we need a bootloader bit to inhibit kaslr
On 04/15/2013 03:38 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
>> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>>> also do not overlap with boot_param, command_line, and initrd.
>>>
>>> and need to double check setup_header.init_size to make sure bss and
>>>
On 04/15/2013 02:59 PM, Kees Cook wrote:
>>
>> The *physical* mapping, where it lands in RAM, is completely
>> independent, and if you're going to randomize the latter, there is no
>> reason it has to match the former. Instead, randomize it freely.
>
> Ah, gotcha. I don't see much benefit in
On Mon, Apr 15, 2013 at 3:42 PM, Kees Cook wrote:
> On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu wrote:
>
>> so the decompressed image is not moved high?
>
> No, I mean the size of the relocated image is using z_extract_offset
> as the end size of the relocated memory. See select_aslr_address. It
On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
>> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>>> also do not overlap with boot_param, command_line, and initrd.
>>>
>>> and need to double check setup_header.init_size to make sure
On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>> also do not overlap with boot_param, command_line, and initrd.
>>
>> and need to double check setup_header.init_size to make sure bss and
>> etc will not
>> fall into memory hole or reserved
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
>> On 04/15/2013 02:41 PM, Kees Cook wrote:
>
>> Please read what I wrote.
>>
>> The 2 GB limit is for the *virtual* mapping.
>>
>> The *physical* mapping, where it lands in RAM, is
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
> On 04/15/2013 02:41 PM, Kees Cook wrote:
> Please read what I wrote.
>
> The 2 GB limit is for the *virtual* mapping.
>
> The *physical* mapping, where it lands in RAM, is completely
> independent, and if you're going to randomize the
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
> On 04/15/2013 02:41 PM, Kees Cook wrote:
>>>
>>> You seem to be missing something here...
>>>
>>> There are *two* mappings in 64-bit mode. Physically, if you're going to
>>> randomize you might as well randomize over the entire range...
On 04/15/2013 02:41 PM, Kees Cook wrote:
>>
>> You seem to be missing something here...
>>
>> There are *two* mappings in 64-bit mode. Physically, if you're going to
>> randomize you might as well randomize over the entire range... except
>> not too far down (on either 32 or 64 bit mode)... in
W/the relocation information, we can pick the virtual address to load
at independent from the physical load address.
On Mon, Apr 15, 2013 at 2:41 PM, Kees Cook wrote:
> On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin wrote:
>> On 04/15/2013 02:06 PM, Eric Northup wrote:
>>> On Sat, Apr 13, 2013
On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin wrote:
> On 04/15/2013 02:06 PM, Eric Northup wrote:
>> On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin wrote:
>>> On 04/13/2013 05:37 PM, Yinghai Lu wrote:
so decompress code position is changed?
You may push out bss and other
On 04/15/2013 02:06 PM, Eric Northup wrote:
> On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin wrote:
>> On 04/13/2013 05:37 PM, Yinghai Lu wrote:
>>>
>>> so decompress code position is changed?
>>>
>>> You may push out bss and other data area of run-time kernel of limit
>>> that boot loader
>>>
On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin wrote:
> On 04/13/2013 05:37 PM, Yinghai Lu wrote:
>>
>> so decompress code position is changed?
>>
>> You may push out bss and other data area of run-time kernel of limit
>> that boot loader
>> chose according to setup_header.init_size.
>> aka that
On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/13/2013 05:37 PM, Yinghai Lu wrote:
so decompress code position is changed?
You may push out bss and other data area of run-time kernel of limit
that boot loader
chose according to setup_header.init_size.
aka that
On 04/15/2013 02:06 PM, Eric Northup wrote:
On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/13/2013 05:37 PM, Yinghai Lu wrote:
so decompress code position is changed?
You may push out bss and other data area of run-time kernel of limit
that boot loader
chose
On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 02:06 PM, Eric Northup wrote:
On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/13/2013 05:37 PM, Yinghai Lu wrote:
so decompress code position is changed?
You may push out bss and
W/the relocation information, we can pick the virtual address to load
at independent from the physical load address.
On Mon, Apr 15, 2013 at 2:41 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 02:06 PM, Eric Northup
On 04/15/2013 02:41 PM, Kees Cook wrote:
You seem to be missing something here...
There are *two* mappings in 64-bit mode. Physically, if you're going to
randomize you might as well randomize over the entire range... except
not too far down (on either 32 or 64 bit mode)... in particular,
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 02:41 PM, Kees Cook wrote:
You seem to be missing something here...
There are *two* mappings in 64-bit mode. Physically, if you're going to
randomize you might as well randomize over the entire range...
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 02:41 PM, Kees Cook wrote:
Please read what I wrote.
The 2 GB limit is for the *virtual* mapping.
The *physical* mapping, where it lands in RAM, is completely
independent, and if you're going to randomize
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 02:41 PM, Kees Cook wrote:
Please read what I wrote.
The 2 GB limit is for the *virtual* mapping.
The *physical* mapping, where it lands
On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu ying...@kernel.org wrote:
also do not overlap with boot_param, command_line, and initrd.
and need to double check setup_header.init_size to make sure bss and
etc will not
fall
On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu ying...@kernel.org wrote:
also do not overlap with boot_param, command_line, and initrd.
and need to double
On Mon, Apr 15, 2013 at 3:42 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu ying...@kernel.org wrote:
so the decompressed image is not moved high?
No, I mean the size of the relocated image is using z_extract_offset
as the end size of the relocated
On 04/15/2013 02:59 PM, Kees Cook wrote:
The *physical* mapping, where it lands in RAM, is completely
independent, and if you're going to randomize the latter, there is no
reason it has to match the former. Instead, randomize it freely.
Ah, gotcha. I don't see much benefit in doing this as
On 04/15/2013 03:38 PM, Yinghai Lu wrote:
On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu ying...@kernel.org wrote:
also do not overlap with boot_param, command_line, and initrd.
and need to double check
On 04/15/2013 03:00 PM, Yinghai Lu wrote:
looks you are trying redo the work for bootloader to pick loaded phys addr.
Well, that is exactly what they are doing. On top of that they also
need to randomize the 64-bit virtual mapping.
I wonder if we need a bootloader bit to inhibit kaslr in
On 04/15/2013 07:31 PM, H. Peter Anvin wrote:
I also am starting to think that this really would be done better being
integrated with the decompressor code, since that code already ends up
moving the code around... no reason to do this again.
Another good reason to do this in the
On Mon, Apr 15, 2013 at 7:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/15/2013 03:00 PM, Yinghai Lu wrote:
looks you are trying redo the work for bootloader to pick loaded phys addr.
Well, that is exactly what they are doing. On top of that they also
need to randomize the 64-bit
On 04/13/2013 05:37 PM, Yinghai Lu wrote:
>
> so decompress code position is changed?
>
> You may push out bss and other data area of run-time kernel of limit
> that boot loader
> chose according to setup_header.init_size.
> aka that make those area overlap with ram hole or other area like
>
On Fri, Apr 12, 2013 at 1:13 PM, Kees Cook wrote:
[...]
> diff --git a/arch/x86/boot/compressed/head_64.S
> b/arch/x86/boot/compressed/head_64.S
> index c1d383d..fc37910 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -59,7 +59,7 @@
On Fri, Apr 12, 2013 at 1:13 PM, Kees Cook keesc...@chromium.org wrote:
[...]
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index c1d383d..fc37910 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -59,7 +59,7
On 04/13/2013 05:37 PM, Yinghai Lu wrote:
so decompress code position is changed?
You may push out bss and other data area of run-time kernel of limit
that boot loader
chose according to setup_header.init_size.
aka that make those area overlap with ram hole or other area like
boot
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
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
46 matches
Mail list logo
