Re: Better communication about spectre/meltdown
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. On Thu, Feb 15, 2018 at 08:56:42PM +0100, Moritz Muehlenhoff wrote: > On Thu, Feb 15, 2018 at 12:33:12PM +0100, Raphael Hertzog wrote: > > On IRC I learned that Moritz Muehlenhoff (jmm) started the work of > > bakcporting retpoline to gcc-4.9 for jessie. We need to do the same > > for gcc-4.6 (and maybe gcc-4.7) in wheezy. gcc-4.6 is used for the > > kernel build so that's the important target really. > > Or rather introduce gcc-4.9 as a new source package to wheezy LTS > which can then be used for the kernel build (once 3.2.x has > retpoline backported). > > For the architectures supported in LTS the compiler difference > between 4.6 and 4.9 should not matter. > So, here as update on the current state of gcc-4.6/gcc-4.7. Basically, jmm's patches to gcc-4.9 were not a perfect fit for gcc-4.6, but it was not terribly difficult to figure out how to get them to apply with some changes. Some components had been removed/refactored between 4.6 and 4.9 and it was somewhat time consuming. In a few cases I had to examine old upstream changes to a particular section of code in order to determine how best to backport a given hunk to fit the structure of gcc-4.6. What was more surprising than anything, and what now appears to be the biggest obstacle, is that the option parsing in gcc-4.9 has significant differences from the option parsing in gcc-4.6. In particular, the new -mindirect-branch= and -mfunction-return= options make use of a feature in gcc's option parser (by far the most sophisticated option parser I have seen) that allows it to automagically parse a string passed as a command-line option into some value of an enum. As best I can determine, that feature was introduced for gcc-4.7. As a result, the way I have the patches currently applied, the build fails early on in an area of the option parsing code. After examining other command-line options that map a string value to an enum constant and how they are implemented in gcc-4.6 I have determined that the way forward likely involves one of two things: - Backport the string-to-enum mapping feature for option parsing (the upstream change that introduced it appears to be ~200 lines of diff) - Implement option parsing code for the two new options that resembles the existing code for parsing other options in gcc-4.6 I am hesitant to backport upstream's string-to-enum mapping option parsing change as it may be that the change is not completely contained in the one interesting commit that I found. I would hate to start down that path only to end up needing to pull in more and more changes. Implementing 4.6-style option parsing for the new options would introduce risk in a different way. Instead of backporting upstream's proven code for option parsing, this would require developing new code that may or may not be completely correct. Of course, at this point gcc-4.9 has been patched, tested, and released, so I feel it is prudent to suggest that reconsideration of that as one of the options for how to proceed. Please note that I have not yet examined gcc-4.7, but I suspect that based on the option parsing being the biggest problem I have encoutnerd that backporting the patches to gcc-4.7 will be considerably easier than it has been for gcc-4.6. Of course, if anyone out there feels like they can take this over from me and have a clear path to the goal, I am more than happy to turn this over. I will provide a detailed summary of the changes I made to jmm's patches and any other relevant bits of information. Regards, -Roberto -- Roberto C. Sánchez
upload golang
Hi.
I prepared LTS security update for golang. Debdiff is attached along
with this mail.
Link:
https://mentors.debian.net/debian/pool/main/g/golang/golang_1.0.2-1.1+deb7u3.dsc
. I done following tests.
- installed in a wheezy machine.
- patch is on src/cmd/go/vcs.go . So run couple of go get commands
- Compiled couple of go programs.
I don't have any experience with go. So it would be great if you could
give it some more testing, review and then upload.
Thanks
-abhijith
diff -Nru golang-1.0.2/debian/changelog golang-1.0.2/debian/changelog
--- golang-1.0.2/debian/changelog 2018-02-25 13:31:35.0 +0530
+++ golang-1.0.2/debian/changelog 2017-10-27 20:17:15.0 +0530
@@ -1,14 +1,3 @@
-golang (2:1.0.2-1.1+deb7u3) wheezy-security; urgency=high
-
- * Non-maintainer upload by the Debian LTS team.
- * CVE-2018-7187: "go get" implementation, doesnot validate the
-import path (get/vcs.go only checks for "://" anywhere in
-the string), which allows remote attackers to execute arbitrary
-OS commands via a crafted web site. Backported from
-upstream development branch.
-
- -- Abhijith PA Sun, 25 Feb 2018 13:31:35 +0530
-
golang (2:1.0.2-1.1+deb7u2) wheezy-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru golang-1.0.2/debian/patches/CVE-2018-7187.patch
golang-1.0.2/debian/patches/CVE-2018-7187.patch
--- golang-1.0.2/debian/patches/CVE-2018-7187.patch 2018-02-25
13:31:35.0 +0530
+++ golang-1.0.2/debian/patches/CVE-2018-7187.patch 1970-01-01
05:30:00.0 +0530
@@ -1,60 +0,0 @@
-Description: Fix CVE-2018-7187
- The "go get" implementation, doesnot validate the import path (get/vcs.go
only
- checks for "://" anywhere in the string), which allows remote attackers to
- execute arbitrary OS commands via a crafted web site. Backported from
- upstream development branch.
-Author: Abhijith PA
-Origin:
https://github.com/golang/go/commit/c941e27e70c3e06e1011d2dd71d72a7a06a9bcbc
-Bug: https://github.com/golang/go/issues/23867
-Last-Update: 2018-02-22
-
golang-1.0.2.orig/src/cmd/go/vcs.go
-+++ golang-1.0.2/src/cmd/go/vcs.go
-@@ -524,8 +524,8 @@ func repoRootForImportDynamic(importPath
- }
- }
-
-- if !strings.Contains(metaImport.RepoRoot, "://") {
-- return nil, fmt.Errorf("%s: invalid repo root %q; no scheme",
urlStr, metaImport.RepoRoot)
-+ if err := validateRepoRootScheme(metaImport.RepoRoot); err != nil {
-+ return nil, fmt.Errorf("%s: invalid repo root %q: %v", urlStr,
metaImport.RepoRoot, err)
- }
- rr := &repoRoot{
- vcs: vcsByCmd(metaImport.VCS),
-@@ -538,6 +538,36 @@ func repoRootForImportDynamic(importPath
- return rr, nil
- }
-
-+// validateRepoRootScheme returns an error if repoRoot does not seem
-+// to have a valid URL scheme. At this point we permit things that
-+// aren't valid URLs, although later, if not using -insecure, we will
-+// restrict repoRoots to be valid URLs. This is only because we've
-+// historically permitted them, and people may depend on that.
-+func validateRepoRootScheme(repoRoot string) error {
-+ end := strings.Index(repoRoot, "://")
-+ if end <= 0 {
-+ return errors.New("no scheme")
-+ }
-+
-+ // RFC 3986 section 3.1.
-+ for i := 0; i < end; i++ {
-+ c := repoRoot[i]
-+ switch {
-+ case 'a' <= c && c <= 'z' || 'A' <= c && c <= 'Z':
-+ // OK.
-+ case '0' <= c && c <= '9' || c == '+' || c == '-' || c == '.':
-+ // OK except at start.
-+ if i == 0 {
-+ return errors.New("invalid scheme")
-+ }
-+ default:
-+ return errors.New("invalid scheme")
-+ }
-+ }
-+
-+ return nil
-+}
-+
- // metaImport represents the parsed tags from HTML files.
- type metaImport struct {
diff -Nru golang-1.0.2/debian/patches/series golang-1.0.2/debian/patches/series
--- golang-1.0.2/debian/patches/series 2018-02-25 13:31:35.0 +0530
+++ golang-1.0.2/debian/patches/series 2017-10-27 20:17:15.0 +0530
@@ -11,4 +11,3 @@
godoc-symlinks.diff
CVE-2017-198.patch
CVE-2017-15041.patch
-CVE-2018-7187.patch
Re: upload golang
Hi Abhijith, > I prepared LTS security update for golang. Debdiff is attached along > with this mail. Looked good to me — modulo the typos in the changelog! — so I went ahead and uploaded this, announcing it via DLA-1294-1: https://lists.debian.org/debian-lts-announce/2018/02/msg00029.html Thank you! Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Better communication about spectre/meltdown
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? Cheers, Moritz
Re: Better communication about spectre/meltdown
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. Regards, -Roberto -- Roberto C. Sánchez
