Bug 90168 - rpm command segfault on i386 cpu due to mischosen arch when rpm (included beecrypt lib) was build
Summary: rpm command segfault on i386 cpu due to mischosen arch when rpm (included bee...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-04 13:15 UTC by Eric Thomas
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-05 14:17:55 UTC
Embargoed:


Attachments (Terms of Use)

Description Eric Thomas 2003-05-04 13:15:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:

rpm command exits with segfault (badly handled SIGILL in fact, see additonnal
informations below) when processing sha1 signature.

rpm -q 'installed_pkg'      ->  buggy
rpm -q 'not_installed_pkg'  ->  not buggy (no sha1 processing)

In fact, with such a bug, I suppose that installing RH 8.0 on i386 cpu computer
is propably impossible. I did the install on a i686 computer, avoiding all
*.i686.rpm packages (install from harddrive) and put back the harddrive on the
i386 pc. So I face the bug only now.

Please read the following explanations:

sha1Process() from beecrypt library in the rpm source package (not the beecrypt
package !) assumes arch=i686

This is done at build time, not at runtime.
The default sha1Process(), written in C, is all-x86-cpu compliant whereas the
asm version contains 'bswap' instructions that are i486+ cpu compatible only.

If you rebuild the package from srpms on a i686 host with '--target
i386-foo-linux' , this won't fix the problem because this option is not used by
'configure' at %build stage, and beecrypt will be build for i686 anyway.

To realy fix this, you need to change the rpm.spec file, adding the argument
'--host=%{_target_platform}' to the 'configure' call in the %build section and
rebuild the package.

There is perhaps a better way to make it works... but that's the one I found.

Version-Release number of selected component (if applicable):
rpm-4.1-1.06

How reproducible:
Always

Steps to Reproduce:
1.any 'rpm -q already_installed_package'
2.or any 'rpm -qa'
3.
    

Actual Results:  segfault and doesn't do what's expected of course


Expected Results:  a working command !

Additional info:

Well, all above are informations from what is making rpm command crash.
But there is an underlying bug, possibly more severe, and not easy to track (at
least for me :-) )

All this is ix86 related only.

In librpmio, RPMClass() tries to determine the kind of cpu.
First thing is to identify i386 cpus. This is (very poorly) done this way:
signal(SIGILL,model3)
followed by a 'cpuid' instruction, which is only 486+

Of course this raise a SIGILL on i386 cpus, indicating that it is an i386.
It is not very clean, but it works.
Hunting for this bug, I've found many documentation on the web explaining how to
do it *cleanly*. Surprising...

The problem is that if any other SIGILL is raised during the execution, model3()
is called, and registers are restored with the value they had during RPMClass()
call where model3() where supposed to branch.

Of course this is nonsense if SIGILL is not raised during RPMClass

So this is the bad ugly SIGILL handling, leading to SIGSEGV.

I think that I shall also open a bug report for this...

Comment 1 Eric Thomas 2003-05-04 13:28:44 UTC
A few things I forgot.

The same bug exists in RH 7.3 / rpm 4.0.4 but never revealed (for me) because
the sha1Process was never called (no sha1 signed packages installed).

If you build a simple programm calling only sha1Process() and linked to
librpmio, you get a real SIGILL because SIGILL is not handled with model3().

True for RH7.3 and RH8.


Comment 2 Jeff Johnson 2003-05-05 14:17:55 UTC
Yes, i486 is the earliest x86 model supported by rpm.

You can fix the bswap problem by editing beecrypt/sha1opt.h
to disable assembly speedups.

You can avoid the cpuid by using rpm-4.0.5 (iirc, otherwise
backport) to use a config.guess output-like string in
/etc/rpm/platform. Packages at ftp://ftp.rpm.org/pub/rpm/test-4.0.5.

Comment 3 Eric Thomas 2003-05-05 21:18:25 UTC
Well, that is exactly the "too easy" answer I was afraid to get.

Where does the information saying that 486+ cpu are requiered come from ?
The only information from rpm.org is

* Linux - Sparc/Intel/PowerPC/Alpha/m68k/SGI

Nothing more precise.
But this might be not up to date ? as 99% of the website.
I know how much writing documentation is boring, but there is not any
information about this cpu type restriction ANYWHERE.

But if it's true, what is {arch} done for ?
rpm-xx-yy.i386.rpm should not exist !

Why not considering building 2 rpm: one for i386 and one for i486+ , or more
likely: one for i3/4/586 and one for i686 ?

There is even more simple. Couldn't we treat this '2 versions' issue directly in
the beecrypt library ?
specialy seeing this (first lines of rpm's CHANGES file)

4.0.4 -> 4.1:
- loosely wire beecrypt library into rpm.

This would solve the problem about sha1() dynamic calls but (I suppose) not the
/bib/rpm case, staticaly linked.

Then again, "at least", a simple rebuild of the rpm-4.1 package, using the
already installed, right architecture, beecrypt(-devel) version wouldn't require
any change in the way to build the package for different architectures.

Comment 4 Jeff Johnson 2003-05-05 21:27:53 UTC
Not it isn't an "easy" answer. I support platforms that I have
access to, and i386 is not one of those platforms.

I cannot justify the time supporting i386, there's almost noone
who is using anymore. I can (and have) told you how to "fix" the
problems.

Building per-arch packages adds yet another dimension to an
already complicated build matrix, now upwards of 20 different
platform/versions, and increasingly rapidly. i386 is insufficiently
high priority.

FWIW, Red Hat stopped supporting i386 several years ago. Just because
packages have an "i386" string does not mean that the hardware arch
is supported.




Note You need to log in before you can comment on or make changes to this bug.