Re: Better communication about spectre/meltdown
On Mon, 2018-02-26 at 14:40 -0500, Antoine Beaupré wrote: > On 2018-02-25 13:57:07, Roberto C. Sánchez wrote: > > On Sun, Feb 25, 2018 at 07:04:12PM +0100, Moritz Mühlenhoff wrote: > > > On Sun, Feb 25, 2018 at 08:54:06AM -0500, Roberto C. Sánchez wrote: > > > > Hi all, > > > > > > > > Please see my rather long-winded summary of the current state of the > > > > gcc-4.6/gcc-4.7 update. The bottom line is that I am looking for opions > > > > and/or guidance for how to proceed. > > > > > > Why 4.6 _and_ 4.7? Only the compiler used for building the amd64 3.2 > > > kernel > > > is relevant here? > > > > > > > Both are triaged in dla-needed.txt. In any event, I have done no work at > > all on 4.7 at this point, other than to observe that my investigation > > into the differences in the option parsing code (which was the only > > significant difficulty I encountered in backport the 4.9 patches) made > > me think that backporting the 4.9 patches to 4.7 would be *easier* than > > the backport to 4.6. > > > > As far as I know, it has not been decided that 4.7 will be patched. > > jessie also has two gcc compilers from what I can tell (4.8 and 4.9) > yet, the security team is concentrating only on one (4.9). It seems like > we should do the same (concentrate on a single compiler). > > is there anything blocking the use of the 4.9 compiler in wheezy, short > of, of course, the backport itself? It's true it's kind of nuts to > introduce a *third* toolchain in a LTS update, but I wonder how feasible > it is to maintain the two that are already there in the long term, if > we're already having trouble with 4.6... > > Can't the wheezy kernel build with 4.7 or 4.9 correctly? I guess that > involves the buildds as well...? It will almost certainly build correctly with 4.9 on x86. AIUI the Spectre mitigations in gcc are x86-specific, so there's no value in changing it for ARM and there would be a risk of exceeding code size limits on armel. The kernel package already has provision for using different compiler versions per-architecture. Ben. > Note that only the 4.9.x series has seen upstream releases in the last > ~3 years. The last 4.7 release is 4.7.4, from june 2014, and for 4.6.x, > 4.6.4 in April 2013. Have anyone tried to contact upstream to see if > they are backporting those changes in any official capacity? -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Re: current status of spectre/meltdown
On 2018-02-21 21:12:31, Fabian Grünbichler wrote: > On 02/21/2018 08:40 PM, Antoine Beaupré wrote: >> Hi, >> >> Trying to do a recap here to update the wiki page correctly: >> >> https://wiki.debian.org/DebianSecurity/SpectreMeltdown >> >> See if you can fill in the blanks I've found... > > (Disclaimer: not involved in all of in any capacity on the Debian side > besides testing the preview gcc packages for downstream usage, so please > take with a grain of salt ;) I don't know any details about non-x86, so > refraining from commenting too much on those parts) [...] > this got kinda long, sorry ;) Well, that's a great response! I've tried to summarize your responses and those of others in the thread in the wiki, which gives us the following diff: https://wiki.debian.org/DebianSecurity/SpectreMeltdown?action=diff=30=26 You'll also noticed I flipped the "yellow" color back to "green" for Spectre v1. I'm not sure why this was yellow: I chose that color before because I felt this was only partially mitigated, but I feel that we have "as good as we can get" mitigation. >From what I understand, we'd need a full audit of the complete source code of the Debian archive (!) and, once that's done), a full rebuild with retpoline. That is not a realistic expectation and so I simply noted that we do not plan to do a full rebuild at this stage. Hutchings also added per-architecture tables and more details, thanks for that! Hopefully we're a little better in terms of documentation. I'd still like to see a better userland section, but I'm not sure where to start... Thanks for your help! A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm
Re: Better communication about spectre/meltdown
On 2018-02-25 13:57:07, Roberto C. Sánchez wrote: > On Sun, Feb 25, 2018 at 07:04:12PM +0100, Moritz Mühlenhoff wrote: >> On Sun, Feb 25, 2018 at 08:54:06AM -0500, Roberto C. Sánchez wrote: >> > Hi all, >> > >> > Please see my rather long-winded summary of the current state of the >> > gcc-4.6/gcc-4.7 update. The bottom line is that I am looking for opions >> > and/or guidance for how to proceed. >> >> Why 4.6 _and_ 4.7? Only the compiler used for building the amd64 3.2 kernel >> is relevant here? >> > Both are triaged in dla-needed.txt. In any event, I have done no work at > all on 4.7 at this point, other than to observe that my investigation > into the differences in the option parsing code (which was the only > significant difficulty I encountered in backport the 4.9 patches) made > me think that backporting the 4.9 patches to 4.7 would be *easier* than > the backport to 4.6. > > As far as I know, it has not been decided that 4.7 will be patched. jessie also has two gcc compilers from what I can tell (4.8 and 4.9) yet, the security team is concentrating only on one (4.9). It seems like we should do the same (concentrate on a single compiler). is there anything blocking the use of the 4.9 compiler in wheezy, short of, of course, the backport itself? It's true it's kind of nuts to introduce a *third* toolchain in a LTS update, but I wonder how feasible it is to maintain the two that are already there in the long term, if we're already having trouble with 4.6... Can't the wheezy kernel build with 4.7 or 4.9 correctly? I guess that involves the buildds as well...? Note that only the 4.9.x series has seen upstream releases in the last ~3 years. The last 4.7 release is 4.7.4, from june 2014, and for 4.6.x, 4.6.4 in April 2013. Have anyone tried to contact upstream to see if they are backporting those changes in any official capacity? A. -- I'm no longer accepting the things I cannot change. I'm changing the things I cannot accept. - Angela Davis
Re: upload leptonlib
>Was upstream's position also to remove those binaries? Yes. >Upstream was unable to provide a patch? Yes. Upstream decided that it was not worth the time to make a patch. Leptonica is a large image processing library. It also contains source code for many (over 200) example programs that use the library. From these example programs, a small number (about 10) are built and ship as part of the leptonica-progs binary package. Bug #830660 noticed that some of these programs were insecure. The affected programs were not very important, and my best guess is nobody uses them. So after discussion with upstream, I removed them from the Debian package. Because the programs are probably not used, I don't have a strong opinion about what happens with Wheezy. Does this help?
