Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1516599
Summary: | invalid handling of the "immutable flag" in efivarfs_set_variable() | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Subhendu Ghosh <sghosh> | ||||||||||||
Component: | efivar | Assignee: | Peter Jones <pjones> | ||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||
Priority: | unspecified | ||||||||||||||
Version: | 28 | CC: | alvin, amessina, andrej, awilliam, bhockney, bkelly, brendan.weir, bugzilla, dustymabe, elyscape, extras-qa, fedora, gleidson, gmarr, g.smyli, jovmilan, lersek, mattdm, maxx, mike, pbrobinson, pjones, pwhalen, qoheniac, rabin, rbarlow, redhat-bugzilla, rhbz, robatino, skumari, will | ||||||||||||
Target Milestone: | --- | Keywords: | Patch, Reopened | ||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | x86_64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | efivar-37-1.fc28 | Doc Type: | If docs needed, set a value | ||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | 1489942 | ||||||||||||||
: | 1658814 (view as bug list) | Environment: | |||||||||||||
Last Closed: | 2019-01-11 02:58:52 UTC | Type: | Bug | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Bug Depends On: | |||||||||||||||
Bug Blocks: | 1658814 | ||||||||||||||
Attachments: |
|
Description
Subhendu Ghosh
2017-11-23 04:07:25 UTC
Still seeing the file (no such file or directory ) error dbxtool-8-3.fc27.x86_64 strace attached Getting next EFI_SIGNATURE_DATA Getting next ESL buffer Getting next EFI_SIGNATURE_DATA Getting next EFI_SIGNATURE_LIST Attempting to identify filetype: va2 guid is {pkcs7_cert} guid table guid is {pkcs7_cert} ft_append_timestamp is 2010-03-06 19:17:21 Attempting to apply 1 updates Sorting updates list Checking if "DBXUpdate-2016-08-09-13-16-00.bin" has been applied. Getting next EFI_SIGNATURE_DATA Getting next ESL buffer Update entry is not applied. Update "DBXUpdate-2016-08-09-13-16-00.bin" is not applied Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted Cannot Continue.: Operation not permitted error trace: efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted Hello I'm also getting dbxtool errors on a Lenovo ideapad 510 # rpm -q dbxtool dbxtool-8-3.fc27.x86_64 # systemctl status dbxtool.service ● dbxtool.service - Secure Boot DBX (blacklist) updater Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2017-11-25 20:55:14 GMT; 23min ago Process: 789 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE) Main PID: 789 (code=exited, status=1/FAILURE) Nov 25 20:55:09 bwlaptop systemd[1]: Started Secure Boot DBX (blacklist) updater. Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying 1 updates Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Nov 25 20:55:11 bwlaptop dbxtool[789]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation Nov 25 20:55:11 bwlaptop dbxtool[789]: Cannot Continue.: Operation not permitted Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Unit entered failed state. Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Failed with result 'exit-code'. I see this same message on an Intel NUC with current firmware from Intel. [ 0.000000] DMI: /NUC5PPYB, BIOS PYBSWCEL.86A.0063.2017.0807.1503 08/07/2017 # rpm -q dbxtool dbxtool-8-3.fc27.x86_64 Created attachment 1359277 [details] tar of requested efivars tar cjf vars.tar.bz2 /sys/firmware/efi/efivars/{PK,KEK,db}* I have exactly the same issue as Subhendu Ghosh reported. ThinkPad T440, BIOS version 2.44 (latest). Created attachment 1361625 [details]
Archive with efivars
Attached archive w/ efivars
Same 'Operation not permitted' messages on Hewlett-Packard HP Pavilion 15 Notebook. bash-4.4$ sudo rpm -q dbxtool dbxtool-8-3.fc27.x86_64 strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted Cannot Continue.: Operation not permitted bash-4.4$ ls /sys/firmware/efi/efivars/ | grep dbx dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c I see this failure, too, on a Dell XPS 13 9343 with BIOS version A14. Secure Boot is disabled.
% rpm -q dbxtool
dbxtool-8-3.fc27.x86_64
% sudo /usr/bin/dbxtool -a /usr/share/dbxtool/ --verbose
[...]
Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted
Cannot Continue.: Operation not permitted
error trace:
efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted
efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted
lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted
I did notice a page in the firmware under Secure Boot named Expert Key Management. It contained a checkbox, disabled by default, "Enable Custom Mode", with UI elements to manipulate PK/KEK/db/dbx. The help text explained:
> Expert Key Management allows the PK, KEK, db and dbx security key databases
> to be manipulated. The keys can only be modified if the system is in Custom
> Mode. If Custom mode is disabled, any changes made while in Custom Mode will
> be erased and the keys will revert back to their default setting.
> [Documentation about the buttons in this UI to manipulate each database
> elided.]
Enabling this checkbox sounded promising but sadly had absolutely no effect on opening dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f for write.
Same problem on Dell Inspiron 7548/0AM6R0. Also on Fedora 28 with dbxtool-8-4.fc28.x86_64: systemd[1]: Started Secure Boot DBX (blacklist) updater. dbxtool[10106]: Applying 1 updates dbxtool[10106]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 dbxtool[10106]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted dbxtool[10106]: Cannot Continue.: Operation not permitted BTW, this bug looks just about the same as https://bugzilla.redhat.com/show_bug.cgi?id=1489942 Seeing the same issue on a Zotac Ci327 Nano; Fedora 27 installed, x86_64 Secure boot enable Same messages as comment 10. The "Operation not permitted" error occurs because efivarfs_set_variable() [src/efivarfs.c] calls open() in not-read-only-mode *before* it calls efivarfs_set_fd_immutable(..., 0). (Looking at upstream efivar @ 9896c26c7e68.) That won't work; the kernel sets the dbx-... pseudo-file to immutable by default, and that can only be cleared by opening the file for r/o first, and calling the ioctl(). The open for write can come only after. A similar issue was corrected earlier in upstream efivar commit 4c20a6de. This issue can be worked around by running "chattr -i" on the dbx-... file manually, before invoking dbxtool. I see another issue in efivarfs_set_variable(): if (attributes & EFI_VARIABLE_APPEND_WRITE) { flags = O_APPEND|O_CREAT; flagstr = "O_APPEND|O_CREAT"; } else { technically this might work on Linux, but really one of O_RDWR or O_WRONLY should be present too. Created attachment 1437631 [details] [PATCH] rewrite efivarfs_set_variable() [based on tag "32"] Attaching the patch that fixes efivarfs_set_variable(). The patch applies to the upstream efivar tag called "32", hence it is suitable for Fedora 27: - scratch build: efivar-32-2.bz1516599.fc27 https://koji.fedoraproject.org/koji/taskinfo?taskID=27001571 I tested this on OVMF, together with the dbxtool fix (from bug 1508808 comment 25). The dbxtool systemd service now works fine without errors or workarounds. I tested two scenarios: - when "dbx" didn't exist on boot (but SB was otherwise enabled), - when "dbx" existed with a single sha256 entry. NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned. Created attachment 1437643 [details] [PATCH] rewrite efivarfs_set_variable() [9896c26c7e68-based] Attaching the patch that fixes efivarfs_set_variable(). The patch applies to current upstream efivar (master @ commit 9896c26c7e68), hence it is suitable for Fedora 28: - scratch build: efivar-35-1.bz1516599.fc28 https://koji.fedoraproject.org/koji/taskinfo?taskID=27001318 NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned. Laszlo -- Thanks for the workaround + patch - will give it a try once it hits the testing repo. I still see this on an Intel NUC with current firmware and efivar-35-1.fc28.x86_64 dbxtool-8-5.fc28.x86_64 Removing the immutable flag worked for me (Thinkpad X230): # chattr -i /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f # /usr/bin/dbxtool -a /usr/share/dbxtool/ -q Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 After that, I get a possibly unrelated error: # /usr/bin/dbxtool -a /usr/share/dbxtool/ -q dbxtool: EFI Signature List is malformed dbxtool: list has 3800 bytes left, element is 76 bytes # echo $? 1 Upstream efivar now contains the patch from comment 14, as commit 9c51123abebd. This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Reopening for Fedora 28. - According to comment 18, the upstream fix is commit 9c51123abebd. The first upstream tag that said commit is part of is "36". - Checking the "efivar" package in Koji: <https://koji.fedoraproject.org/koji/packageinfo?packageID=17225>, the latest build for Fedora 28 is "efivar-35-1.fc28" <https://koji.fedoraproject.org/koji/buildinfo?buildID=1067810>. It is based on upstream tag "35", and the %changelog does not mention a backport of upstream commit 9c51123abebd. (In fact, the package is dated 2018-Apr-09, while the upstream fix was applied on 2018-May-17.) This should be fixed in the most recent build: efivar-37-1.fc28 https://koji.fedoraproject.org/koji/buildinfo?buildID=1169369 Any idea why efivar-37-1 isn't listed in Bodhi? It's not in updates-testing for either Fedora 28 or 29. https://bodhi.fedoraproject.org/updates/?packages=efivar Chris, thanks for raising this question. In fact when I made comment 22 yesterday, I intended to provide a direct Bodhi link as well. However... (1) Not sure when exactly it must have happened, but the Bodhi WebUI has semi(?)recently regressed to the point where it's now borderline unusable, in my opinion anyway. For about ten minutes I couldn't decide whether the reason for my not finding a Bodhi update for efivar was my lacking Bodhi-fu, or the actual absence of a Bodhi update. Consider, for example <https://bodhi.fedoraproject.org/updates/?releases=F28&status=testing>. It currently gives you a list of 325 package updates, broken down into 17 pages of 20 updates each. There is no way to search for a package by name, or to increase the update count per page (after which one could use the browser's in-page search function). Am I *really* supposed to click through 17 pages to find the update I'm looking for? (2) Ultimately, I somehow stumbled upon Peter's page at <https://bodhi.fedoraproject.org/users/pjones>. That's a lot more focused view, and I didn't see an update there. So I *guess* that the Bodhi update is not there because Peter has yet to submit it. If you're searching for an update by package name, just...search. There's a magnifying glass at top-right of the web UI. That's the search button. Click it, type the package name. Maybe it could be a bit more prominent, it is a bit small and grey and out of the way. Really it's probably the most common 'entry point' for doing stuff with Bodhi from the front page, I'd think (that and the 'profile' page, I guess). Hi Adam, thanks for the hint. In the upper right corner of <https://bodhi.fedoraproject.org/>, I don't see a magnifying glass. Instead, I see the number "14", in digital clock script: <https://imgur.com/a/SYe76GH>. That's...not normal. I see the search icon whether I'm logged in or out. Are you blocking scripts or CSS, perhaps? Or forcing fonts? Does it actually work for searching when you click on it, regardless of what it looks like? If I set "Allow pages to choose their own fonts, instead of my selections above" in Firefox, then the magnifying glass appears. However, I didn't randomly clear that checkbox. I need to enforce a minimum font size, and I depend on fonts to look mostly uniform. Bodhi's use of a custom font for the magnifying glass / search link is *wrong*. For starters, it is inconsistent with the rest of the landing page. The "Stats" and "Login" widgets are in normal Latin script, why can't "Search" be the same? Furthermore, the small icons all over the table (Security updates / Bugfix updates / Enhancement updates / New package updates) look like normal images to me. If "Search" has to be a magnifying glass and not Latin script, why can't it be a similar picture? Anyway, yes, if I click "14", the search function works fine. Thank you! There is a ticket about making the search more obvious in the UI: https://github.com/fedora-infra/bodhi/issues/1455 Thank you Randy, I've now pinged that ticket. Using some kind of image font is pretty standard practice on Teh Intarwebz these days. I gave up trying to force font selection because of this a couple of years back. I just use text zoom for pages that use stupidly tiny fonts now :/ efivar-37-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9963fc558e efivar-37-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9963fc558e efivar-37-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. |