Hello!

It seems that one of the security patches has caused a regression on ia64 as GRUB is no longer able to load any basic commands:

Loading.: grub
Starting: grub
Welcome to GRUB!
error: unknown filesystem.
Entering rescue mode...
grub rescue> insmod ext2
error: unknown filesystem.
grub rescue> help
Unknown command `help'.
grub rescue> ?
Unknown command `?'.
grub rescue> linux
Unknown command `linux'.
grub rescue>

I have not bisected the issue yet, but maybe anyone has got any idea?

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey Adrian,

On Wed, Mar 17, 2021 at 07:22:02PM +0100, John Paul Adrian Glaubitz wrote:

Hello!

It seems that one of the security patches has caused a regression on ia64 as GRUB is no longer able to load any basic commands:

Loading.: grub
Starting: grub
Welcome to GRUB!
error: unknown filesystem.
Entering rescue mode...
grub rescue> insmod ext2
error: unknown filesystem.
grub rescue> help
Unknown command `help'.
grub rescue> ?
Unknown command `?'.
grub rescue> linux
Unknown command `linux'.
grub rescue>

I have not bisected the issue yet, but maybe anyone has got any idea?

May I ask you to do a bisect for us?

Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Daniel!

On 3/26/21 7:01 PM, Daniel Kiper wrote:

I have not bisected the issue yet, but maybe anyone has got any idea?

May I ask you to do a bisect for us?

The issue was introduced by this patch as discussed here [1]:

From: Peter Jones <pjones@redhat.com>

Add a init_pe_section() helper function to setup PE sections. This makes
the code simpler and easier to read.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

The address pointing to the modules within the GRUB core.img no longer matches the actual position of the modules. Hence, GRUB can't load the built-in modules anymore.

Adrian

[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00244.html

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Daniel!

On 3/26/21 7:43 PM, Daniel Kiper wrote:

The address pointing to the modules within the GRUB core.img no longer matches
the actual position of the modules. Hence, GRUB can't load the built-in modules
anymore.

Ahhh... OK, great. So, only one bug to fix... :-)

Any news on this? I assume this should be trivial to fix when considering just the
addresses where the modules get loaded to and the pointer is pointing to needs to
be fixed.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[ adding Peter Jones who authored the patch ]

On 4/8/21 6:45 PM, John Paul Adrian Glaubitz wrote:

Hi Daniel!

On 3/26/21 7:43 PM, Daniel Kiper wrote:

The address pointing to the modules within the GRUB core.img no longer matches
the actual position of the modules. Hence, GRUB can't load the built-in modules
anymore.

Ahhh... OK, great. So, only one bug to fix... :-)

Any news on this? I assume this should be trivial to fix when considering just the

Not yet, sorry. I discussed a little bit with Peter yesterday but it's strange that only affects ia64 and not x64. I'll try to take a look at this next week.

addresses where the modules get loaded to and the pointer is pointing to needs to
be fixed.

Adrian

Best regards,
Javier

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/8/21 7:10 PM, Javier Martinez Canillas wrote:

Any news on this? I assume this should be trivial to fix when considering just the

Not yet, sorry. I discussed a little bit with Peter yesterday but it's strange
that only affects ia64 and not x64. I'll try to take a look at this next week.

It's probably caused by different natural alignment which causes the code on x86_64
to land at the right position automatically.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/8/21 7:30 PM, John Paul Adrian Glaubitz wrote:

On 4/8/21 7:10 PM, Javier Martinez Canillas wrote:

Any news on this? I assume this should be trivial to fix when considering just the

Not yet, sorry. I discussed a little bit with Peter yesterday but it's strange
that only affects ia64 and not x64. I'll try to take a look at this next week.

It's probably caused by different natural alignment which causes the code on x86_64
to land at the right position automatically.

OK, so I had another discussion with Michael Karcher who analyzed the bug and the
problem is apparently that after the change, mkimage adds an alignment to the module
address which it did not before the change.

And the suspicion why this affects ia64 and not x86_64 could be that the module data
is properly aligned as mkimage expects while it's not on ia64.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)