Comment 162 for bug 1040557

Hi Steve,

NOTE: After some initial glance across the different things involved here.

If I am not wrong after reading the noefi related bugfix changelog as well as looking at

a) samsung-laptop.c (The original patch for efi bug - return failure on EFI_BOOT being set)
b) efi.c (The changes done on Feb14 - clear EFI_RUNTIME_SERVICES instead of EFI_BOOT if noefi param is passed)

What I understand is that the noefi bugfix of Feb14 was to ensure that samsung-laptop module behaves properly even if noefi parameter was passed. Rather there was a bug in the way noefi parameter was being handled as it was wrongly clearing EFI_BOOT instead of EFI_RUNTIME_SERVICES, and this inturn would have messed with the samsung-laptop module workaround. So by fixing this bug on Feb14, noefi boot parameter no longer conflicts with samsung-laptop module.

So with the latest kernels after Feb14 which include this noefi bugfix, passing noefi boot param should ensure that

a) the samsung-laptop module doesn't poke into legacy smc memory space and create unwanted problems, as well as
b) the kernel doesn't use the efi runtime service and the buggy setvariable call in turn in samsung firmware, what ever the case (including kernel crash).

However if I get the uefi spec on initial glance, the runtime service persists even after calling exitbootservice function (rather more a wrong assumption on my side earlier, as I hadn't looked at uefi spec before - also the setup.c in kernel tells that even bootservices are potentially called even after calling exitbootservices, which technically shouldn't be the case from the uefi spec - no idea why they have put that comment in there, however I do see the need potentially with setvirtualaddress map etc wrt efi and so ... unless I am missing something here).

So as you right fully doubted, if I read the efi related code correctly then calling noefi WILL NOT ensure that a root user cann't get access to runtime service in future, because it doesn't actively try to disable efi tables etc, rather it just doesn't set them up in the new/current linux environment. So a root user could load a kernel module to replicate the functionality of efi.c virtual mapping so that he can set things up as required. Unless something else goes and overwrites the original efi systab/??? (Rather if it is possible to do that - I don't see why not unless uefi runs in a special previlaged mode or so (which I don't think it does, but haven't gone deep sufficiently yet to say one way or the other), then may be we should write a logic to go and overwrite it with nulls or some such thing so that even a root user cann't go and recover the efi runtime in future in the current boot of the system, through a special special boot parameter let us say fullsystem_noefi).

NOTE: And parallely samsung should look at fixing the multiple bugs in their firmware. Do you have any input on when they may fix this issue.