(Created page with "What is the impact on third-party kernel modules? (I don't think we need to support them, but it will be necessary to highlight in release notes.) --~~~~") |
No edit summary |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
What is the impact on third-party kernel modules? (I don't think we need to support them, but it will be necessary to highlight in release notes.) --[[User:Mitr|Mitr]] 15:24, 20 July 2012 (UTC) | What is the impact on third-party kernel modules? (I don't think we need to support them, but it will be necessary to highlight in release notes.) --[[User:Mitr|Mitr]] 15:24, 20 July 2012 (UTC) | ||
I'll take a crack at answering this. Peter and Matthew can yell at me if I screw up. Firstly, if a user wants to use | |||
3rd party modules they can disable secure boot and they will work as well as they did before. That is the easiest | |||
option relatively speaking. Assuming a user wishes to use secure boot with a 3rd party module, then they can use the | |||
tools that will be provided as part of the feature to create their own signing key. They would enroll the public | |||
portion of this key in the firmware on their machine and sign any additional modules they wish to use. This would need | |||
to be done whenever a new build of a module is required (kernel update, module update, etc). NOTE: the kernel code to | |||
support this still needs to be written and tested. | |||
If the question was geared towards repositories that provide 3rd party modules, then the above still applies to a | |||
degree. The repository would need to generate their own signing key, and users would need to enroll the public portion | |||
of that key on their systems in order to use modules provided by the repo. --Josh Boyer 19:21 20 July 2012 | |||
These answers (and any other known-regressed functionality) should be abstracted into the 'user experience' / release-notes section on the main page. [[User:Fche|Fche]] 04:10, 29 July 2012 (UTC) | |||
Latest revision as of 04:10, 29 July 2012
What is the impact on third-party kernel modules? (I don't think we need to support them, but it will be necessary to highlight in release notes.) --Mitr 15:24, 20 July 2012 (UTC)
I'll take a crack at answering this. Peter and Matthew can yell at me if I screw up. Firstly, if a user wants to use 3rd party modules they can disable secure boot and they will work as well as they did before. That is the easiest option relatively speaking. Assuming a user wishes to use secure boot with a 3rd party module, then they can use the tools that will be provided as part of the feature to create their own signing key. They would enroll the public portion of this key in the firmware on their machine and sign any additional modules they wish to use. This would need to be done whenever a new build of a module is required (kernel update, module update, etc). NOTE: the kernel code to support this still needs to be written and tested.
If the question was geared towards repositories that provide 3rd party modules, then the above still applies to a degree. The repository would need to generate their own signing key, and users would need to enroll the public portion of that key on their systems in order to use modules provided by the repo. --Josh Boyer 19:21 20 July 2012
These answers (and any other known-regressed functionality) should be abstracted into the 'user experience' / release-notes section on the main page. Fche 04:10, 29 July 2012 (UTC)