=== henrix_ is now known as henrix
=== chesty_ is now known as chesty
=== jhg__ is now known as jhg_
=== ghostcube_ is now known as ghostcube
[16:08] <hggdh> hello, regarding bug 1844245 
[16:08] <ubot5> bug 1844245 in linux-azure (Ubuntu) " Integrate Intel SGX driver into linux-azure" [Undecided,In progress] https://launchpad.net/bugs/1844245
[16:10] <hggdh> We found that doing dist-upgrade on servers that depend (for work) on the SGX module on 18.04 resulted in non-functional server (because the module is blacklisted by 1844245)
[16:11] <hggdh> (this is on Azure). Why is the module blacklisted for Azure? We are expecting many bugs opened as a result of this (as customers upgrade and fail)
[16:16] <apw> hggdh, i didn't think that module didn't exist prior to the upgrade, and there is an opt in loader systemd job for it
[16:19] <hggdh> apw: it did not. The project had instructions and used to download the source/build/install. But with the automatic blacklist... they went south
[16:21] <mhcerri> hggdh, does the server still boot?
[16:21] <hggdh> the questions are (1) why is it blacklisted on Azure (2) is it possible to remove the blacklist
[16:21] <mhcerri> hggdh, there's a systemd service shipped with this version that should load the sgx module
[16:21] <hggdh> right now they are scrambling to let actual users of the service know they will all go down if they install the new kernel
[16:22] <apw> which is disabled by default
[16:23] <hggdh> yes. and They *depend* on SGX
[16:24] <mhcerri> hggdh, sgx is can potentially cause security issues, we started to ship it but we decided to ship it disabled by default
[16:24] <hggdh> mhcerri: I am finding out right now. We just got the Sev A bug
[16:25] <apw> mhcerri, do you have an incantation to tell the systemd to enable the job to load it
[16:26] <mhcerri> hggdh, enabling intel-sgx-load-module.service should load the module
[16:31] <hggdh> mhcerri: thank you. But, meanwhile, any of the service customers will first have to boot, fail to join the enclave, then systemctl enable/start the module
[16:31] <hggdh> correct?
[16:33] <apw> hggdh, they could enable it beforehand i assume
[16:34] <apw> hggdh, as for removing the blacklist; even if we did that and redid the kernle, the one they have installed now would still blacklist it
[16:34] <mhcerri> hggdh, yes. but that could potentially happen in any kernel update if you are building the module by yourown. any abi change can break the module
[16:36] <hggdh> apw: indeed, sorry. Install the update, systemctl enable the service, remove the blacklist, reboot
[16:36] <hggdh> mhcerri: I believe they are using dkms
[16:36] <apw> you don't need to rmeove the blacklist, as the service handles your intent to laod
[16:36] <hggdh> *they *were* using dkms
[16:36] <hggdh> apw: perfect
[16:36] <apw> hggdh, though you should test that if you have a test-bed
[16:38] <mhcerri> hggdh, dkms packages will usually have a bunch of ifdef's to cover most of the scenarios, but still they are not flawless.. for the dkms we support in the archive we have to test them against any new kernel release to ensure they are still working
[16:39] <hggdh> mhcerri: yes, I understand. I believe the developers were doing so (and in fact, they were the ones that opened the bug)
[17:08] <hggdh> mhcerri: could you please expand on "security issues" on SGX? The developer is asking
[17:11] <mhcerri> hggdh, nothing specific, but it's new techlogy that isn't fully tested and wasn't accepted upstream yet
[17:14] <mhcerri> hggdh, please let us know if enabling the service actually works around the issue. that might be useful information for us
[17:15] <hggdh> mhcerri: I will. I am asking the devs to try it (add in the blacklist, unload the mod, enable the service, reboot)
[17:32] <hggdh> Perhaps the major point here is adding the SGX mod was nice, but unilaterally disabling it... directly hits whoever actually (and currently) uses the kernel. I mean, changes should minimise impact, but this one (in this aspect) ONLY impacts those that already use the module
[17:39] <apw> the problem is we cannot know or test the impacts of changes on completely out of archive objects like this
[17:39] <apw> which is why people are encouraged to get things into the archive so they can be tested and regressions like this detected
[18:02] <hggdh> apw: I understand. But, at the moment, this looks really like a regression. I will check if they have already opened a bug on LP for it
[18:37] <hggdh> mhcerri: you need to enable and *start* the service. Just enabling will load the module on next reboot. But it works, and keeps working after reboot
[18:37] <mhcerri> hggdh, ah perfect. sorry, yes that what I meant
[18:38] <mhcerri> hggdh, so it doesn't seem the sgx module is needed during the initramfs step, right?
[18:43] <hggdh> mhcerri: I don't know *yet*. I tested on a common instance of 18.04, not under the ansible environment the application needs. I am asking them to check on it now. The WantedBy=multi-user.target also worries me...
=== hggdh is now known as hggdh-msft