-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We need to check if "loader_str" is an actual path or not. #620
base: main
Are you sure you want to change the base?
Conversation
The string "loader_str" we got from split_load_options() is considered as a path but it could be other things, for example: "S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}" This is a Microsoft BCD object which represents the MS Boot loader: BCDEDIT Friendly Name: {bootmgr} Symbolic Name: G:UID_WINDOWS_BOOTMGR GUID: {9dea862c-5cdd-4e70-acc1-f32b344d4795} This value is what normally the bootmgfw.efi file is expecting. The shim in some situations could replace bootmgfw.efi for various reasons. We need to ignore such arguments and use the DEFAULT_LOADER. Signed-off-by: Bogdan Ariton <bogdan.mihail.ariton@gmail.com>
Signed-off-by: Bogdan Ariton <bogdan.mihail.ariton@gmail.com>
Thanks for reviewing the code. I've updated the white space issues. |
You seem to assume that if the file does not exist, the path is incorrect. However, even if the path is just "loader.efi", your code says it's ”not a valid path” if it doesn't exist. In my opinion, this is not the way to go. While this approach luckily works for weird paths, it's incorrect and could cause confusion when a file is simply missing. Also, you need to know what you are fixing and why your fix works. If you look at the boot entry which |
Thank you so much for the response!
If the path is "loader.efi" it will be concatenated with the folder location where the shim resides. (done here: generate_path_from_image_path). - so we eventually check if /path/to/shim/loader.efi exists.
Originally, in the message that the shim prints out, I was only able to see the S at the start which was concatenated with the rest of the path where the shim would reside (which is consistent with what you said about which characters can be seen on the screen based on the system). I printed out as you said the entire buffer and this is what I got. ("S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}" ) - but I'm confused about when you say that is seems to be a valid path? This is just a GUID that the windows boot loader recognizes, for the shim this doesn't mean anything since the shim is trying to load another file (a second stage loader or just keep the default loader). This is why I thought to code would be useful just checking for the files existence, because we can't make much sense of other options in the first place. |
Currently shim reports ”Failed to open ...” and it's a perfectly good error message when the path is valid but the file is missing. This is exactly why I think your idea needs a more complicated implementation than just checking if the file exists. If that was a proper solution, then you could simply rely on the check which shim already does and just hide the unwanted error message in
That's not the entire buffer. The entire buffer is more like:
Even if it makes no sense, it's a valid path. You can make a file named "S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}", and you can tell shim to boot that file. But it doesn't really matter, I was really just pointing out that |
Hmm, I understand what you're saying, but think about it this way: I my mind it doesn't make sense to get some value from the load options which can be something wrong only to then use the fallback. The path check is just something that I believe it will be useful overall and it's agnostic of whether it's a windows specific load option or something else. Maybe it can be implemented in a different way and we can give back some more meaningful messages, but in my head it make sense since we're trying to load up a file and if not found just go for the DEFAULT value or use the fallback if that doesn't exists. |
That already happens. The necessary checks are already in place (when shim tries to load the file), and now you are just duplicating them in another place. The functional difference is in output. I think you should just quiet the offending error message instead of duplicating all the checks. That's a smaller change and makes the intention clear. However, I see the goal differently: if the user creates a boot entry with a new path, that's what they want to use, and they want to know if it's not working. The user should have control over their boot options, and only special cases (such as Let a mainainer say which option is preferable. |
OK, I'm fine with closing this PR out and just check for WINDOWS\0 case added by bcedit. This is probably the only case, thus far that causes issues which most people don't understand. (like the ones described in the ticket) |
The string "loader_str" we got from split_load_options() is considered as a path but it could be other things, for example:
"S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}"
This is a Microsoft BCD object which represents the MS Boot loader:
BCDEDIT Friendly Name: {bootmgr}
Symbolic Name: GUID_WINDOWS_BOOTMGR
GUID: {9dea862c-5cdd-4e70-acc1-f32b344d4795}
This value is what normally the bootmgfw.efi file is expecting. The shim in some situations could replace bootmgfw.efi for various reasons.
We need to ignore such arguments and use the DEFAULT_LOADER.
Link to opened issue: #370