Openembedded Core Discussions
 help / color / mirror / Atom feed
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
>
>



  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