Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 300342 - dev-libs/openssl engine padlock is not working
Summary: dev-libs/openssl engine padlock is not working
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High minor with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-09 23:12 UTC by Farid
Modified: 2011-04-30 05:11 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Farid 2010-01-09 23:12:56 UTC
dev-libs/openssl-0.9.8l-r2

I have the same issue as the old bug http://bugs.gentoo.org/145537

I think that the "VIA PadLock support for Linux" page http://www.logix.cz/michal/devel/padlock/index.xp?show_selected=1&msgid=39#feedback_form
Expalins the problem as:

"IMPORTANT: In certain setups most OpenSSL hardware accelerator drivers (so called engines) are compiled as shared modules. Although PadLock engine is always compiled statically OpenSSL core doesn't know that, tries to load it dynamically and fails. That renders PadLock support in OpenSSL 0.9.8 unusable. Please attach the following patch should you encounter any such problems and recompile your openssl library."

I do not really understand if this is a bug that gentoo should fix, or if this is one of those things that upstream should handle in some way.

But I really would like it to work.
Maybe a new use flag for applying the patch for padlock?

Reproducible: Always

Steps to Reproduce:
1. emerge openssl
2. compile padlock support in kernel
3. # openssl engine padlock

Actual Results:  
# openssl engine padlock
5475:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(/usr/lib/engines/libpadlock.so): /usr/lib/engines/libpadlock.so: cannot open shared object file: No such file or directory
5475:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
5475:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450:
5475:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:415:id=padlock

Expected Results:  
# openssl engine padlock
(padlock) VIA PadLock

Portage 2.1.6.13 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.32-gentoo-r1 x86_64)
=================================================================
System uname: Linux-2.6.32-gentoo-r1-x86_64-VIA_Nano_processor_L2200@1600MHz-with-gentoo-1.12.13
Timestamp of tree: Sat, 09 Jan 2010 11:45:03 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
app-shells/bash:     4.0_p35
dev-lang/python:     2.6.4
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.63-r1
sys-devel/automake:  1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-mtune=generic -mmmx -msse -msse2 -msse3 -mcx16 -msahf -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-mtune=generic -mmmx -msse -msse2 -msse3 -mcx16 -msahf -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="C"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection samba session spl sse sse2 ssl ssse3 sysfs tcpd threads tordns unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 1 SpanKY gentoo-dev 2010-01-10 01:06:26 UTC

*** This bug has been marked as a duplicate of bug 145537 ***
Comment 2 Farid 2010-01-10 08:49:55 UTC
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of bug 145537 ***
> 

According to comment 14 by Sebastian Schuberth 2009-09-13, it works. He gets the expected results.

I do not with my system.
I get the same result as comment 10.

I do not consider this to be resolved.

It would be nice to get an explanation why gentoo thinks this is resolved.

Could it have something to do with me running a 64-bit system, which was not possible a few months ago with padlock support? (Before VIA Nano CPU).
Comment 3 SpanKY gentoo-dev 2010-01-11 03:46:21 UTC
your summary is wrong.  this has nothing to do with Bug 145537.  that was about adding patches to support the padlock engine which we are not going to do -- that needs to go upstream.

the patch you reference also doesnt make any sense.  it's already in 0.9.8l.  so unless you have a patch that actually works, we're not going to do anything here.
Comment 4 klockren 2011-04-21 05:06:33 UTC
VIA PadLock is NOT working in 64 bit environment with the 0.9.8 and 1.0.0 branches of OpenSSL. When the PadLock patches were merged into the main OpenSSL tree, there were still no 64 bit VIA CPU, so it was only fixed for 32 bit arch.
I have heard that PadLock should work with OpenSSL 1.0.1, but it didn't for me.
I had to build OpenSSL from the HEAD (trunk) branch in CVS to get PadLock work.
This is what I did:
# cvs -d anonymous@cvs.openssl.org:/openssl-cvs co openssl
# cd openssl
# ./config --prefix=/usr --openssldir=/etc/ssl --libdir=/lib64
# make depend
# make
# emerge -C openssl
# make install
# echo "dev-libs/openssl-1.1.0" >> /etc/portage/profile/package.provided
# revdep-rebuild
# uname -a
Linux vpnserver 2.6.37-gentoo-r4 #1 SMP Wed Apr 20 11:50:15 CEST 2011 x86_64 VIA Nano U3300@1200MHz CentaurHauls GNU/Linux
# openssl version
OpenSSL 1.1.0-dev xx XXX xxxx
# openssl engine padlock
(padlock) VIA PadLock (no-RNG, ACE)

Revdep-rebuild successfully rebuilds openssh, wget and openvpn.

BUT it fails on rebuilding
dev-lang/python:2.7
dev-lang/python:3.1
dev-perl/Net-SSLeay:0
dev-vcs/git:0
mail-mta/ssmtp:0

Is there a chance the Gentoo OpenSSL package maintainer will merge the PadLock changes from HEAD into the Gentoo 1.0.0 or 0.9.8 ebuilds?
Comment 5 SpanKY gentoo-dev 2011-04-30 05:11:56 UTC
like i already said, you need to quote actual patches.  i have no via hardware, thus i have no way of checking things.  figure out the *exact* upstream cvs commits that can be applied on the current release.