Re: grub_machine_fini on efi systems

[phcoder <phcoder@gmail.com>]

Remark 1: when loading OS grub has to call grub_efi_exit_boot_services 
which unloads efi nearly completely. On the other hand it shouldn't be 
called when returning with exit command. Perhaps we should split 
grub_machine_fini in two: one for preparing for OS and other for 
exiting. But then when one chainloads then grub_efi_exit_boot_services 
shouldn't be called. So I propose that loader function should cope with 
environment preparation. For cases when some preparation is needed 
independently of the type of loaded os (like setting 'map' hook) the 
best solution IMO would be preboot hooks.
Remark 2: it should be clearly stated somewhere what the boot function 
may and may not use (e.g. boot function isn't allowed to read from disk, 
boot function may use grub_printf but not and so on) so that boot 
function conflicts neither with grub_machine_fini nor with preboot hooks
Remark 3: in case of an error the non-returning boot function may 
return. I see 3 possible solution:
a) forbid such an action. Use grub_fatal if really necessary
b) loader should call a special function at point of noreturn
c) delete the separation between returnable and not returnable booters. 
  grub_machine_prepare_for_os and preboot_hooks in my proposition patch 
would then be extended with second function which is called upon the 
return to undo the action of the hook itself
Regards
Vladimir 'phcoder' Serbinenko
phcoder wrote:
> Hello. I found a serious problem which may be the cause of linux not 
> booting on some efi systems. grub_machine_fini is called before 
> grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 
> to efi. This includes all memory used to load modules. So actually efi 
> can rightfully destroy linux module before it has slightest chance to do 
> its job. I asked step21 to declare linux boot as returnable to stop 
> grub_machine_fini. However it's nothing more then a workaround. I hope 
> that someone will find a way to fix this nicely because for the moment I 
> see none. (perhaps tomorrow I'll find sth)
> Regards
> Vladimir 'phcoder' Serbinenko