[PATCH] 2013/10/15 Security Errata: HotSpot Changes

[Andrew]

----- Original Message -----
> On 11/23/2013 08:35 PM, Alex Kasko wrote:
> > On 11/23/2013 05:36 PM, Alex Kasko wrote:
> >> On 11/23/2013 10:40 AM, Andrew wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> * Andrew <gnu.andrew at redhat.com> [2013-11-20 12:13]:
> >>>>> Webrev: http://cr.openjdk.java.net/~andrew/openjdk6/20131015/hotspot
> >>>>
> >>>> Looks identical to patches in icedtea6. No objections from me.
> >>>>
> >>>> Thanks,
> >>>> Omair
> >>>>
> >>>> --
> >>>> PGP Key: 66484681 (http://pgp.mit.edu/)
> >>>> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> >>>>
> >>>
> >>> Now they're all pushed, we should consider a b29 release, though let's
> >>> first hear back on Alex's Windows issues.
> >>>
> >>
> >> It was a makefile typo -
> >> http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_makefile_typo.00/
> >>
> >> Windows builds are in progress now, they should finish in 3 hours - I'll
> >> report later.
> >
> > Typo was only the part of the issue. The main issue was the /SAFESEH
> > linking flag on sawindbg.dll causing link error [1]. I was unable to
> > make it work with VS2003 (my knowledge of win32 debug tools seems too
> > low), so I am proposing to remove this flag from i586 windows build (it
> > is not used in amd64 one). Some links with the context of the problem:
> > [2] - [8].
> >
> > Updated (more clean) typo webrev based on changeset [9] -
> > http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_makefile_typo.01/
> >

I think the original patch was preferable; this revised version would add the flag
on archs other than x86 AFAICS.

> > Separate webrev for safeseh flag remove -
> > http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_sa_safeseh_disabled.00/
> >
> > It is actually the rollback of this change [10] from initial patch.
> >

This essentially removes the security fix for the serviceability agent.
I'm not sure whether that's wise.  On the other hand, this issue (8015614)
doesn't have a CVE number, so it's just a defense-in-depth fix, ensuring all
libraries have safe exception handler tables AFAICS.

http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.110).aspx

As far as I can tell, the build issue arises because something is being linked
against that doesn't have SEH tables.  From what I've read, without the flag,
the files being built will still have SEH tables if possible, but it can't
guarantee it.

Omair, what are your thoughts?

> > Another round of windows builds is in progress (problematic i586 hotspot
> > is already passed).
> 
> Both windows builds finished successfully with these patches.
> 
> >
> > PS: maybe it's better to combine both oneliner changes into single patch.
> >
> >
> > [1]
> > http://cr.openjdk.java.net/~akasko/jdk6/hotspot_sawindbg_safeseh_error.txt
> > [2] https://bugs.openjdk.java.net/browse/JDK-7017110
> > [3] https://bugs.openjdk.java.net/browse/JDK-7160624
> > [4] http://msdn.microsoft.com/en-us/library/9a89h429%28v=vs.71%29.aspx
> > [5]
> > http://stackoverflow.com/questions/14710577/error-lnk2026-module-unsafe-for-safeseh-image
> >
> > [6]
> > http://stackoverflow.com/questions/10599940/module-unsafe-for-safeseh-image-c
> >
> > [7]
> > http://stackoverflow.com/questions/1610786/find-windows-dlls-not-compiled-with-safeseh
> >
> > [8]
> > http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005743.html
> >
> > [9]
> > http://hg.openjdk.java.net/hsx/jdk7u/hotspot/diff/75c36a461ecd/make/windows/makefiles/compile.make
> >
> > [10]
> > http://cr.openjdk.java.net/~andrew/openjdk6/20131015/hotspot/make/windows/makefiles/sa.make.udiff.html
> >
> >
> >
> 
> 
> --
> Regards,
> Alex Kasko
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07