Page MenuHomeFreeBSD

Check if the gettime runtime service is valid
ClosedPublic

Authored by andrew on Mar 19 2018, 6:15 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 4 2024, 5:15 AM
Unknown Object (File)
Dec 20 2023, 4:55 AM
Unknown Object (File)
Nov 28 2023, 5:07 AM
Unknown Object (File)
Nov 23 2023, 6:50 PM
Unknown Object (File)
Nov 12 2023, 11:34 PM
Unknown Object (File)
Oct 19 2023, 11:52 PM
Unknown Object (File)
Sep 11 2023, 4:50 AM
Unknown Object (File)
Aug 27 2023, 6:51 AM
Subscribers
None

Details

Summary

The U-Boot efi runtime service expects us to set the address map before calling any runtime services. It will then remap a few functions to their runtime version. One of these is the gettime function. If we call into this without having set a runtime map we get a page fault.

Add a check to see if this is valid in efi_init() so we don't try to use the possibly invalid pointer.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

With this I can boot a new kernel with an old loader.efi on a sopine with U-Boot. It should also allow us to boot with efi_disable_vmap set.

This is reasonable to me... had a question about this code relative to what was on IRC...

sys/dev/efidev/efirt.c
191 โ†—(On Diff #40468)

On IRC you were talking about checking the rtc pointer stuff. but this checks the header stuff. Is that just a misunderstanding on my part or ???

This revision is now accepted and ready to land.Mar 19 2018, 6:31 PM

Or are you using the rt_gettime() pointer to validate the whole runtime and killing it all if that pointer is bad.

Can you also stick an "X-MFC-With: r330868" on it, please, to reduce the hunting that I'll inevitably do later? I'll rip out the UPDATING notice after this lands unless you get to it first

Some other thoughts:

This does break newer kernel working with old loader in amd64, where runtime services would have still functioned but now won't because the virtual mappings aren't setup. I think that's not a bad thing by default because of the Lenovo situation before that inspired the change, but maybe something we want to consider.

sys/dev/efidev/efirt.c
191 โ†—(On Diff #40468)

It should be checking the function pointer is within the map. If it's not valid we need to clear the efi_runtime pointer so we don't try to use it.

This revision was automatically updated to reflect the committed changes.