From: Ming Liu <ming.liu@windriver.com>
To: Mark Hatle <mark.hatle@windriver.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] rpm: fix a endian incompatible error in generating tag
Date: Wed, 29 Jan 2014 16:15:50 +0800 [thread overview]
Message-ID: <52E8B8B6.3070408@windriver.com> (raw)
In-Reply-To: <52E8751D.50101@windriver.com>
On 01/29/2014 11:27 AM, Ming Liu wrote:
> On 01/10/2014 02:05 AM, Mark Hatle wrote:
>> On 1/9/14, 2:49 AM, Ming Liu wrote:
>>> A flaw was found in the way rpm generating arbitrary tags, which
>>> leads to a
>>> incorrect query result, this issue is introduced by a incompatible
>>> endianess
>>> when the generating process is executed on different architectures.
>>>
>>> This patch resolves it by taking a uniform byte order.
>>>
>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
>>> ---
>>> .../rpm-tag-generate-endian-conversion-fix.patch | 29
>>> ++++++++++++++++++++
>>> meta/recipes-devtools/rpm/rpm_5.4.9.bb | 1 +
>>> 2 files changed, 30 insertions(+), 0 deletions(-)
>>> create mode 100644
>>> meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
>>>
>>> diff --git
>>> a/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
>>> b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
>>>
>>> new file mode 100644
>>> index 0000000..4379515
>>> --- /dev/null
>>> +++
>>> b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
>>> @@ -0,0 +1,29 @@
>>> +fix a endian incompatible error in generating rpm tag
>>> +
>>> +A flaw was found in the way rpm generating arbitrary tags, which
>>> leads to a
>>> +incorrect query result, this issue is introduced by a incompatible
>>> endianess
>>> +when the generating process is executed on different architectures.
>>> +
>>> +This patch resolves it by taking a uniform byte order.
>>> +
>>> +Upstream-Status: Pending
>>> +
>>> +Signed-off-by: Ming Liu <ming.liu@windriver.com>
>>> +---
>>> + tagname.c | 3 +++
>>> + 1 file changed, 3 insertions(+)
>>> +
>>> +diff -urpN a/rpmdb/tagname.c b/rpmdb/tagname.c
>>> +--- a/rpmdb/tagname.c
>>> ++++ b/rpmdb/tagname.c
>>> +@@ -152,7 +152,10 @@ static rpmTag _tagGenerate(const char *s
>>> + xx = rpmDigestUpdate(ctx, s, nb);
>>> + xx = rpmDigestFinal(ctx, &digest, &digestlen, 0);
>>> + if (digest && digestlen > 4) {
>>> ++ /* The tag is stored in a uniform byte order for cross-endian
>>> compatibility.
>>> ++ Swap to little-endian if appropriate. */
>>> + memcpy(&tag, digest + (digestlen - 4), 4);
>>> ++ tag = htole32(tag);
>>> + tag = (rpmTag) (tag & 0x3fffffff);
>>> + tag = (rpmTag) (tag | 0x40000000);
>>
>> The above code doesn't look right to me.
>>
>> If this is reading in from the RPM package, it should be an le32toh..
>>
>> Otherwise if it's generating the digest info.. then the htole32
>> should be -after- the & and | operations, otherwise the wrong part of
>> the value will be modified.
>
> Hi, Mark:
>
> I just saw your comments, sorry for the late feedback.
> I'd like to explain it more that _tagGenerate is called at both
> reading and generating sides, so either of your recommended resolves
> only one side of it based on my test, the tag is being counted as a
> number with later & or | operator, but before that, we should transfer
> it to a number with uniform byte order(big or little endian) after we
> get it from a piece of memory, which in this case is the last 4 bytes
> of digest, please think about the following scenario:
>
> x86 host (generating and querying) --> powerpc/mips (querying)
>
> Using le32toh or putting htole32 after the & and | operations both
> will not satisfy it - to get a same result.
Despite the discussion above, I found another concern with my patch
that 'htole32' is not supported by libc of some system, like CentOS,
which leads rpm-native fail to compile with my patch, so please ignore
this so far, I will make a new patch soon.
//Ming Liu
>
> //Ming Liu
>
>>
>> --Mark
>>
>>> + }
>>> diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
>>> b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
>>> index 9d376a5..7921f40 100644
>>> --- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
>>> +++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
>>> @@ -89,6 +89,7 @@ SRC_URI =
>>> "http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.9-0.20120508.src.rpm;ex
>>> file://debugedit-valid-file-to-fix-segment-fault.patch \
>>> file://rpm-platform-file-fix.patch \
>>> file://rpm-lsb-compatibility.patch \
>>> + file://rpm-tag-generate-endian-conversion-fix.patch \
>>> "
>>>
>>> # Uncomment the following line to enable platform score debugging
>>>
>>
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
next prev parent reply other threads:[~2014-01-29 8:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 8:49 [PATCH] rpm: fix a endian incompatible error in generating tag Ming Liu
2014-01-09 18:05 ` Mark Hatle
2014-01-29 3:27 ` Ming Liu
2014-01-29 8:15 ` Ming Liu [this message]
2014-01-29 14:51 ` Mark Hatle
2014-02-07 5:07 ` Ming Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E8B8B6.3070408@windriver.com \
--to=ming.liu@windriver.com \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox