Re: help for OpenSSL update needed
On 2016/10/14 16:24, Martin Husemann wrote: I'm a bit confused what you are trying to do. We support v9 (or v8plus) machines only with sparc64 kernels (and the sparc SUN4U kernel is just a 32bit sparc64 kernel actually). You can then run (as you did) either sparc64 (v9, 64bit) userland or plain sparc (v8, 32bit) userland. We have no special support to compile sparc userland for v8plus (maybe by forcing COPTS?). Thank you for your kind explanation. I was confused, but I've got to understand (I think). Rin
Re: help for OpenSSL update needed
On Fri, Oct 14, 2016 at 03:45:02AM +0900, Rin Okuyama wrote:
> Oops, the combination of MACHINE_ARCH == sparc && MACHINE == sparc64 is
> rejected by build.sh. When do it forcibly, compile errors occur here and
> there. ".if ${MACHINE} == sparc64" in somewhere/arch/sparc is paraphrase
> of ".ifdef notdef"?
I'm a bit confused what you are trying to do. We support v9 (or v8plus)
machines only with sparc64 kernels (and the sparc SUN4U kernel is just
a 32bit sparc64 kernel actually).
You can then run (as you did) either sparc64 (v9, 64bit) userland or
plain sparc (v8, 32bit) userland. We have no special support to compile
sparc userland for v8plus (maybe by forcing COPTS?).
Martin
Re: help for OpenSSL update needed
On 2016/10/13 4:02, Rin Okuyama wrote:
On 2016/10/13 3:16, S.P.Zeidler wrote:
If you don't use an ASM method it should fall back to C and that should
always work, just be a bit slower, and most of the ASM in sparc only kicks
in if MACHINE is sparc64.
Ah, I've realized the situation at last (I'm newbie to sparc). I checked two
cases of MACHINE == MACHINE_ARCH == sparc{,64}, but we also have to test yet
another case of MACHINE_ARCH == sparc && MACHINE == sparc64. Yes, I will do
it later (-current is broken at the moment, due to import errors of gdb.old).
Oops, the combination of MACHINE_ARCH == sparc && MACHINE == sparc64 is
rejected by build.sh. When do it forcibly, compile errors occur here and
there. ".if ${MACHINE} == sparc64" in somewhere/arch/sparc is paraphrase
of ".ifdef notdef"?
Sorry for getting off the subject,
Rin
Re: help for OpenSSL update needed
On Wed, Oct 12, 2016 at 08:16:37PM +0200, S.P.Zeidler wrote: > Thus wrote Martin Husemann (mar...@duskware.de): > > > On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote: > > > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP > > > kernel from sparc64 and userland from sparc) version passed the 29 tests > > > in /usr/tests/crypto/libcrypto. > > > > The sparc64 tests work for me too, but sparc on 32bit hardware > > fails a few tests by timing out: Luckily it all works and the timeouts just were a bit short. All fine now! Martin
Re: help for OpenSSL update needed
On 2016/10/13 3:16, S.P.Zeidler wrote:
# Some .S files in arch/sparc* are generated but not used. Is this OK?
That's mostly me being a completionist. Makes working on checking if they
have an advantage and activating them if yes at a later date easier.
OK, I understand. I agree with your strategy.
If you don't use an ASM method it should fall back to C and that should
always work, just be a bit slower, and most of the ASM in sparc only kicks
in if MACHINE is sparc64.
Ah, I've realized the situation at last (I'm newbie to sparc). I checked two
cases of MACHINE == MACHINE_ARCH == sparc{,64}, but we also have to test yet
another case of MACHINE_ARCH == sparc && MACHINE == sparc64. Yes, I will do
it later (-current is broken at the moment, due to import errors of gdb.old).
Thanks,
Rin
Re: help for OpenSSL update needed
Thus wrote Martin Husemann (mar...@duskware.de): > On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote: > > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP > > kernel from sparc64 and userland from sparc) version passed the 29 tests > > in /usr/tests/crypto/libcrypto. > > The sparc64 tests work for me too, but sparc on 32bit hardware > fails a few tests by timing out: > > t_libcrypto (4/5): 6 test cases > bn: [300.074482s] Failed: Test case timed out after 300 seconds > t_pubkey (5/5): 7 test cases > dh: [22.872256s] Passed. > dsa: [23.997709s] Passed. > ec: [301.048359s] Failed: Test case timed out after 300 seconds > ecdh: [66.262402s] Passed. > ecdsa: [301.034882s] Failed: Test case timed out after 300 seconds > rsa: [299.283552s] Failed: Test case timed out after 300 seconds if you run: /usr/tests/crypto/libcrypto/h_bntest /usr/tests/crypto/libcrypto/h_ectest /usr/tests/crypto/libcrypto/h_ecdsatest /usr/tests/crypto/libcrypto/h_rsatest directly, they ought to be very talkative and tell you at which test of the respective functions they get stuck. I hope all four have a common cause. > > # Some .S files in arch/sparc* are generated but not used. Is this OK? That's mostly me being a completionist. Makes working on checking if they have an advantage and activating them if yes at a later date easier. > Maybe that is related? If you don't use an ASM method it should fall back to C and that should always work, just be a bit slower, and most of the ASM in sparc only kicks in if MACHINE is sparc64. regards, spz
Re: help for OpenSSL update needed
On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote: > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP > kernel from sparc64 and userland from sparc) version passed the 29 tests > in /usr/tests/crypto/libcrypto. The sparc64 tests work for me too, but sparc on 32bit hardware fails a few tests by timing out: t_libcrypto (4/5): 6 test cases bn: [300.074482s] Failed: Test case timed out after 300 seconds t_pubkey (5/5): 7 test cases dh: [22.872256s] Passed. dsa: [23.997709s] Passed. ec: [301.048359s] Failed: Test case timed out after 300 seconds ecdh: [66.262402s] Passed. ecdsa: [301.034882s] Failed: Test case timed out after 300 seconds rsa: [299.283552s] Failed: Test case timed out after 300 seconds > # Some .S files in arch/sparc* are generated but not used. Is this OK? Maybe that is related? Martin
Re: help for OpenSSL update needed
On 2016/10/12 7:37, S.P.Zeidler wrote: I added your patch (with two modifications, see below) plus fixes that make i386 and sparc* compile (and fix i386, which is tested) into my changes and created a new diff from it: http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP kernel from sparc64 and userland from sparc) version passed the 29 tests in /usr/tests/crypto/libcrypto. # Some .S files in arch/sparc* are generated but not used. Is this OK? Thanks, Rin
Re: help for OpenSSL update needed
On 2016/10/12 7:37, S.P.Zeidler wrote: I added your patch (with two modifications, see below) plus fixes that make i386 and sparc* compile (and fix i386, which is tested) into my changes and created a new diff from it: http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz Thank you for review and improvement of my patch. I tested your revised patch, and all 29 tests in /usr/tests/crypto/libcrypto passed on powerpc boxes. Instead I enabled sha1 asm, which has been tested by Robert Swindells (also thanks) in the meantime. I wrote, in the previous mail, that sha1-ppc.S is not used anywhere, but it is not correct. sha1_block_data_order, only one global symbol in sha1-ppc.S, is called from sha1dgst.c via some preprocessor magic. Thank you for fixing it. Rin
Re: help for OpenSSL update needed
Thus wrote Rin Okuyama (rokuy...@rk.phys.keio.ac.jp): > On 2016/10/09 6:29, S.P.Zeidler wrote: > >I still need verifications from non-x86 :) > > I tried it on powerpc boxes. Since build fails with your original patch, > I added some corrections. Please find the attached notes and patch. With > my patch, all 29 tests (MKCRYPTO_RC5=yes) in /usr/tests/crypto/libcrypto > passed both on Freescale MPC8544E and IBM 405GPr. Thank you, much appreciated, especially the AES asm fixes. :) I added your patch (with two modifications, see below) plus fixes that make i386 and sparc* compile (and fix i386, which is tested) into my changes and created a new diff from it: http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz Modifications: > (1) Makefile (regen.sh) transferred into the Makefile; less pretty, but keeping style with the other archs. > - Both sha512-ppc.S and sha256-ppc.S (sha512p8-ppc.S and sha256p8-ppc.S) > are generated from sha512-ppc.pl (sha512p8-ppc.pl). The kind of output > file is determined by its name (including 512 or not). I created and added them, but modified sha.inc not to use them since we have sha??? in libc and we're supposed to use these. Instead I enabled sha1 asm, which has been tested by Robert Swindells (also thanks) in the meantime. regards, spz
Re: help for OpenSSL update needed
On 2016/10/09 6:29, S.P.Zeidler wrote:
I still need verifications from non-x86 :)
I tried it on powerpc boxes. Since build fails with your original patch,
I added some corrections. Please find the attached notes and patch. With
my patch, all 29 tests (MKCRYPTO_RC5=yes) in /usr/tests/crypto/libcrypto
passed both on Freescale MPC8544E and IBM 405GPr.
Thanks,
Rin
PATCH FOR crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc
This patch adds the glue for newly added assembler codes, and also codes
that are present in 1.0.1 but their glue is missing. In addition, it
appeases assembler errors, and so on.
(1) Makefile (regen.sh)
- ppc64-mont.S is necessary even for 32-bit environments.
- Both sha512-ppc.S and sha256-ppc.S (sha512p8-ppc.S and sha256p8-ppc.S)
are generated from sha512-ppc.pl (sha512p8-ppc.pl). The kind of output
file is determined by its name (including 512 or not).
- Replace some instructions to avoid "invalid conditional option" errors
from as(1). Rules for the replacement are derived from here:
https://nxr.netbsd.org/xref/src/crypto/external/bsd/openssl/dist/crypto/perlasm/ppc-xlate.pl#81
- Separate shell script from Makefile as regen.sh.
(2) aes.inc (aesp8-ppc.S, vpaes-ppc.S)
- Add aes-ppc.S, aesp8-ppc.S, and vpaes-ppc.S to AES_SRCS, together with
-DAES_ASM and -DVPAES_ASM flags to AESCPPFLAGS.
- Regen aesp8-ppc.S and vpaes-ppc.S.
(3) bn.inc (ppc-mont.S, ppc64-mont.S)
- Add ppc-mont.S and ppc64-mont.S to BN_SRCS, -DOPENSSL_BN_ASM_MONT to
CPPFLAGS.
- Regen ppc-mont.S and generate ppc64-mont.S.
(4) modes.inc
- Add ghashp8-ppc.S to MODES_SRCS.
(5) sha.inc (sha512-ppc.S, sha512p8-ppc.S, sha256-ppc.S, sha256p8-ppc.S)
- Add sha{512,256}{,p8}-ppc.S to SHA_SRCS.
- Note on sha1-ppc.S, which is not currently used anywhere.
- Regen sha512{,p8}-ppc.S and generate sha256{,p8}-ppc.S.
openssl-1.0.2j-ppc.patch.xz
Description: application/xz
Re: help for OpenSSL update needed
Thus wrote S.P.Zeidler (s...@netbsd.org): > - the new sha1 asm for x86_64 doesn't work, [...] Thanks to Christos this part is fixed. I still need verifications from non-x86 :) regards, spz
Re: help for OpenSSL update needed
Just to clarify: > http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD.diff.xz does not try to use src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha1-x86_64.S for amd64. To enable using it, edit src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha.inc by moving the #if 0 down. We're using sha256 and sha512 from libc, so the asm code for these should not be enabled. regards, spz
