On Mon, 2 Jan 2023 at 14:37, Borislav Petkov wrote:
>
> On Mon, Jan 02, 2023 at 10:32:03AM +0100, Ard Biesheuvel wrote:
> > So instead of appending data to the compressed image and assuming that
> > it will stay in place, create or extend a memory reservation
> > elsewhere, and refer to its absolu
On Mon, Jan 02, 2023 at 10:32:03AM +0100, Ard Biesheuvel wrote:
> So instead of appending data to the compressed image and assuming that
> it will stay in place, create or extend a memory reservation
> elsewhere, and refer to its absolute address in setup_data.
>From my limited experience with all
On Mon, 2 Jan 2023 at 07:17, Borislav Petkov wrote:
>
> On Mon, Jan 02, 2023 at 07:01:50AM +0100, Borislav Petkov wrote:
> > On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> > > It would probably be a good idea to add a "maximum physical address for
> > > initrd/setup_data/cmdline
On Mon, Jan 02, 2023 at 07:01:50AM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> > It would probably be a good idea to add a "maximum physical address for
> > initrd/setup_data/cmdline" field to struct kernel_info, though. It appears
> > right now
On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> It would probably be a good idea to add a "maximum physical address for
> initrd/setup_data/cmdline" field to struct kernel_info, though. It appears
> right now that those fields are being identity-mapped in the decompressor,
> and t
On Sat, Dec 31, 2022 at 07:21:06PM -0800, H. Peter Anvin wrote:
> As far as the decompression itself goes, it should only a problem if we are
> using physical KASLR since otherwise the kernel has a guaranteed safe zone
> already allocated by the boot loader. However, if physical KASLR is in use,
N
On 1.1.2023 6.33, H. Peter Anvin wrote:
On 12/31/22 10:22, Jason A. Donenfeld wrote:
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
That failure is unrelated to the ident mapping issue Peter and
I discus
On 12/31/22 20:55, Mika Penttilä wrote:
If decompression does clobber the data, then we *also* need to figure
out why that is. There are basically three possibilities:
1. If physical KASLR is NOT used:
a. The boot loader doesn't honor the kernel safe area properly;
b. Somewhere in
On 12/31/22 10:22, Jason A. Donenfeld wrote:
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
That failure is unrelated to the ident mapping issue Peter and
I discussed. The original failure is described in t
On 12/31/22 19:21, H. Peter Anvin wrote:
Alternatively, setup_data could be relocated, the boot param protocol
could be bumped, and then QEMU could conditionalized it's use of
setup_data based on that protocol version. That'd work, but seems a bit
more involved.
I think this is at least worth
On 12/31/22 11:00, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
So with that understanding confirmed, I'm confused at your surprise that
hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
> So with that understanding confirmed, I'm confused at your surprise that
> hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant without your patch to prevent the
setup_data
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> > That failure is unrelated to the ident mapping issue Peter and
> > I discussed. The original failure is described in the commit message:
> > decompression clobb
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> That failure is unrelated to the ident mapping issue Peter and
> I discussed. The original failure is described in the commit message:
> decompression clobbers the data, so sd->next points to garbage.
Right, and the fact that th
On Sat, Dec 31, 2022 at 02:48:12PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> > Are you using patch v1 minus the 62 MiB thing?
>
> No, I want to see the original failure - the one that prompted you to send
>
> https://lore.kernel.org/r/20
On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> Are you using patch v1 minus the 62 MiB thing?
No, I want to see the original failure - the one that prompted you to send
https://lore.kernel.org/r/20221228143831.396245-1-ja...@zx2c4.com
--
Regards/Gruss,
Boris.
https:/
On Sat, Dec 31, 2022 at 02:40:59PM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> > This needs to be something like:
> >
> > kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> > kernel_add_identity_map(sd_addr + sizeof(*sd),
> > sd_add
On Sat, Dec 31, 2022 at 02:35:45PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> > Nothing special... `-kernel bzImage` should be enough to do it. Eric
> > reported it, and then I was able to repro trivially. Sure you got the
> > right version
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> This needs to be something like:
>
> kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> kernel_add_identity_map(sd_addr + sizeof(*sd),
> sd_addr + sizeof(*sd) + sd->len);
It still #PFs with that:
(gdb) bt
#0 0xf
On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> Nothing special... `-kernel bzImage` should be enough to do it. Eric
> reported it, and then I was able to repro trivially. Sure you got the
> right version?
Yeah, qemu executables confusion here - had wrongly something older of
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
>
>
> On 12/30/22 14:10, Jason A. Donenfeld wrote:
> > On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> >> See the other thread fork. They have identified the problem already.
> >
> > Not sure I follow. Is there ano
On Sat, Dec 31, 2022 at 10:48:16AM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> > I'll attach a .config file. Apply the patch at the top of this thread to
> > qemu,
>
> Hmm, so the patch at the top of this thread is fixing the clobbering of
On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> I'll attach a .config file. Apply the patch at the top of this thread to
> qemu,
Hmm, so the patch at the top of this thread is fixing the clobbering of
setup_data.
But I tried latest qemu with your .config and it boots ok here
On 12/30/22 17:06, H. Peter Anvin wrote
TThe 62 MB limit mentioned in boot.rst is unrelated, and only applies to
very, very old kernels that used INT 15h, AH=88h to probe memory.
I am 88% sure this was fixed long before setup_data was created, as it
was created originally to carry e820 inf
On 12/30/22 14:10, Jason A. Donenfeld wrote:
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note th
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note that I sent v2/v3, to fix the original problem in a
On December 30, 2022 11:54:11 AM PST, Borislav Petkov wrote:
>On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
>> Look closer at the boot process. The compressed image is initially at
>> 0x10, but it gets relocated to a safer area at the end of
>> startup_64:
>
>That is the
On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
> Look closer at the boot process. The compressed image is initially at
> 0x10, but it gets relocated to a safer area at the end of
> startup_64:
That is the address we're executing here from, rip here looks like 0x100xxx.
>
On December 30, 2022 7:59:30 AM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
>> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
>> wrote:
>> >Hi,
>> >
>> >Read this message in a fixed width text editor with a lot of columns.
On Wed, Dec 28, 2022 at 03:38:30PM +0100, Jason A. Donenfeld wrote:
> The setup_data links are appended to the compressed kernel image. Since
> the kernel image is typically loaded at 0x10, setup_data lives at
> `0x10 + compressed_size`, which does not get relocated during the
> kernel's bo
On Fri, Dec 30, 2022 at 6:01 PM Borislav Petkov wrote:
>
> On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> > >
> > > early console in extract_kernel
> > > input_data: 0x0be073a8
> > > input_len: 0
On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> >
> > early console in extract_kernel
> > input_data: 0x0be073a8
> > input_len: 0x008cfc43
> > output: 0x0100
> > output_len: 0x00
Er, .config attached now.
.config
Description: Binary data
Hi,
On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
> wrote:
> >Hi,
> >
> >Read this message in a fixed width text editor with a lot of columns.
> >
> >On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
> >>
On Thu, Dec 29, 2022 at 01:47:49PM +0100, Borislav Petkov wrote:
> On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> > As far as a crash... that sounds like a big and a pretty serious one at
> > that.
> >
> > Could you let me know what kernel you are using and how *exactly* you ar
On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> As far as a crash... that sounds like a big and a pretty serious one at that.
>
> Could you let me know what kernel you are using and how *exactly* you are
> booting it?
Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it
On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>Read this message in a fixed width text editor with a lot of columns.
>
>On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
>> Glad you asked.
>>
>> So the kernel load addresses are parameterized in the kernel
On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>Read this message in a fixed width text editor with a lot of columns.
>
>On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
>> Glad you asked.
>>
>> So the kernel load addresses are parameterized in the kernel
On 29/12/22 03:31, Jason A. Donenfeld wrote:
Hi,
Read this message in a fixed width text editor with a lot of columns.
On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
Glad you asked.
So the kernel load addresses are parameterized in the kernel image
setup header. One of the th
Hi,
Read this message in a fixed width text editor with a lot of columns.
On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
> Glad you asked.
>
> So the kernel load addresses are parameterized in the kernel image
> setup header. One of the things that are so parameterized are the s
On 12/28/22 15:58, H. Peter Anvin wrote:
On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld"
wrote:
HELLO H. PETER ANVIN,
E
L
L
O
On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
Fix looks good, glad you figured out the problem.
I mean, kind of. The solution here s
On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld"
wrote:
>HELLO H. PETER ANVIN,
>E
>L
>L
>O
>
>On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
>> > Fix looks good, glad you figured out the problem.
>>
>> I mean, kind of. The solution here sucks, especially given that
HELLO H. PETER ANVIN,
E
L
L
O
On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
> > Fix looks good, glad you figured out the problem.
>
> I mean, kind of. The solution here sucks, especially given that in the
> worst case, setup_data just gets dropped. I'm half inclined to consi
On Wed, Dec 28, 2022 at 05:02:22PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Jason,
>
> On 28/12/22 15:38, Jason A. Donenfeld wrote:
> > The setup_data links are appended to the compressed kernel image. Since
> > the kernel image is typically loaded at 0x10, setup_data lives at
> > `0x10 +
Hi Jason,
On 28/12/22 15:38, Jason A. Donenfeld wrote:
The setup_data links are appended to the compressed kernel image. Since
the kernel image is typically loaded at 0x10, setup_data lives at
`0x10 + compressed_size`, which does not get relocated during the
kernel's boot process.
The k
The setup_data links are appended to the compressed kernel image. Since
the kernel image is typically loaded at 0x10, setup_data lives at
`0x10 + compressed_size`, which does not get relocated during the
kernel's boot process.
The kernel typically decompresses the image starting at address
46 matches
Mail list logo
