| juergh | dfgweb, mainline builds have issues at the moment, that's probably part of that. | 06:38 |
|---|---|---|
| juergh | mhcerri, fips is your thing, isn't it? see above ^^ | 06:40 |
| === cascardo_ is now known as cascardo | ||
| mhcerri | hi, xevious. I will take a look at it! thanks for the heads up | 12:41 |
| sw0922 | hi, in order to check if kinetic can boot by now ( #1994126 ) i would like to use some live image from the current kinetic-proposed kernel. Does https://cdimage.ubuntu.com/daily-live/current/ already contain linux 5.19.0-28.29 ? | 13:31 |
| === klebers_ is now known as klebers | ||
| nibbon_ | o/ | 17:02 |
| xevious | mhcerri: Thanks! I built Intel's out-of-tree e1000e driver (versions 3.8.4, which added support for the Alder Lake hardware I'm trying to get working, and the latest 3.8.7), which has been discontinued in favor of the in-tree version. With both versions of the out-of-tree driver, it gets a link but drops almost every packet. I tried disabling various forms of offload (sg, tso, gro) with `ethtool` but that didn't have any effect. I found that | 17:24 |
| xevious | disabling autonegotiation and forcing it to 100mbps makes a ping test start working, but I haven't verified if it fixes all dropped packet issues entirely. Regardless, limiting it to 100mbps is not a feasible way forward. Let me know if there's any additional information you need or if you want me to test any of your WIP changes. | 17:24 |
| JanC | there is no FIPS for the HWE kernels? | 19:01 |
| mhcerri | JanC, not currently | 19:02 |
| JanC | also, having to switch back to 100Mbit/s with the e1000e driver seems to be a recurring issue :) | 19:07 |
| JanC | I remember having to do that long ago (probably more than a decade?) | 19:07 |
| Guest92 | good morning cuties | 19:25 |
| xevious | mhcerri: Adding the module parameter IntMode=1 made the out-of-tree driver work, but we'd like to avoid that approach since it may negatively affect our other high-core-count systems and hope to retain a common system configuration. | 22:32 |
| xevious | Also, however, we had some meetings today and we _may_ push back the adoption of FIPS mode and just switch back to the HWE kernel to get this new hardware working. | 22:34 |
| xevious | One thing that would solidly steer us in that direction would be if my ticket that requests backporting support for the the new NIC models gets closed with a "won't do" (or equivalent) status, due to it effectively being a hardware enablement request for the non-hardware-enablement kernel. TBH, I opened it kind of expecting that, since I don't believe it's standard practice to backport new hardware support to the base kernel for a release. | 22:37 |
| JanC | xevious: do you really need FIPS mode (e.g. for legal reasons) or can you prove the same by providing configuration? | 23:18 |
| xevious | It's for government compliance related stuff. I really need FIPS mode. | 23:20 |
| JanC | from what I understand, FIPS mode basically disables some stuff which potentially makes it harder (but not impossible) to use weak encryption, but also might prevent some even better encryption to be used? :P | 23:20 |
| JanC | so, ugh | 23:20 |
| JanC | so maybe FIPS just makes things easier, but isn't 100% necessary? | 23:22 |
| JanC | as in, it's easier if Canonical certify at least part of it? | 23:22 |
| xevious | JanC: As I understand, FIPS certification is a prerequisite for other certifications we also plan on getting. | 23:34 |
| xevious | The main focus right now, though, is getting this newer hardware's NIC to work. That only relates to FIPS mode in that we're using 20.04's 5.4.0 kernel (rather than the HWE kernel which does support this NIC) in preparation for enabling FIPS mode. So, if backporting support for new hardware to the 5.4.0 kernel isn't possible due to Ubuntu's policy/process, then that may force us to hold off on any of the FIPS stuff until it's available with newer | 23:37 |
| xevious | kernels (I.E. probably once 22.04 is FIPS certified). | 23:37 |
| JanC | xevious: from what I understand FIPS is something you can certify entirely yourself or in part by using certifications by suppliers | 23:46 |
| JanC | it's never something you can entirely certify by using OS certifications (unless you only use very specific applications) | 23:47 |
| JanC | if you use any in-house applications, those would have to be certified outside the OS anyway... | 23:48 |
| JanC | so obviously it's easier & cheaper if the upstream OS has some certifications :) but it's not a requirement per se | 23:49 |
| JanC | in any case you would have to prove that you only use libraries/kernels certified by the supplier(s), etc. | 23:50 |
| JanC | (or if that's not the case, the whole FIPS certification thing would be useless security theatre) | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!