[Dev] Tizen 3.0 proposal for applications launch

Łukasz Stelmach l.stelmach at samsung.com
Wed Oct 16 10:56:19 GMT 2013


It was <2013-10-16 śro 11:24>, when Carsten Haitzler wrote:
> On 10/16/2013 06:11 PM, Łukasz Stelmach wrote:
>> It was <2013-10-16 śro 05:42>, when Carsten Haitzler wrote:
>>> On 10/16/2013 01:24 AM, Thiago Macieira wrote:
>>>> On terça-feira, 15 de outubro de 2013 17:35:13, ?ukasz Stelmach wrote:
>>>>>> This is not madness. Before we had dynamic shared libraries we had
>>>>>> static shared libraries. No runtime linking required, everything is
>>>>>> done via table lookups. You can't delete interfaces from a static
>>>>>> shared library, so they make development slightly more difficult. They
>>>>>> are lots faster.
>>>>> a.out? I may be too young to remember.
>>>> Yeah, that's pre-ELF. It's also before my day. My first Linux install still had
>>>> a.out support and libc.so.4, but that was only for compatibility.
>>>>
>>>> ELF is a big beast, however. To speed up, I recommend prelinking libraries,
>>>> executables, using techniques like ELF symbol visibility, protected
>>>> visibility, -Bsymbolic, etc.
>>> i'm not so sure on prelinking. it does have perf upsides, but comes
>>> with downsides. namely ANY change of a shared lib (eg upgrade,
>>> security fix etc.) requires re-running prelink on all binaries and
>>> other shred libs that depend on it. this is costly and requires a lot
>>> of tracking. it also negates the ability to keep md5/sha1 hashes of
>>> all files in a "secure place" and compare against it to detect
>>> intrusion and hacking... :(
>> Could you please, give some more details. What's wrong with keeping
>> hashes (sha-256 rather than sha-1 and for ...'s sake not md5) in extended
>> attributes. If this is what you mean than what's wrong with offline
>> (initramfs) updates running prelink after upgrading?
>
> normally the hashes are kept as part of the pkging system and are
> already computed in my experience. no need to re-read all data and
> re-compute. i didn't define where to keep the hashes (normally your
> rpm etc. tools keep it in the rpmdb - so u duplicate your rpm db after
> any system upgrade off onto read-only storage or offline storage away
> from the target system and you then can audit the system by comparing
> the computed hashes at that time with the separately stored ones that
> the hacker "can't get to and change to match").
>
> as we are unlikely to have anywhere to do this on a device that isn't
> vulnerable like the fs is, it invariably needs to be done
> off-device. so that means private storage "in the cloud" to hold those
> hashes or maybe a private server or sd-card etc.

You can keep them anywhere you like as long as you can keep the public
key used to sign the list of hashes in a secure place. Hashes without
signatures are not very secure.

> but much SIMPLER is to simply compare the hashes "now" (compute them)
> to the ORIGINAL package contents that was installed/downloaded at
> purchase or upgrade time (fetch the file + hash list), but since you
> re-write the local binaries, matching to the original hashes isn't
> sensible. :)

Well, you don't need to hash all sections of ELF (forgive me but
I couldn't find which section exactly prelink uses to store its
information).

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131016/8c5c4e87/attachment.sig>


More information about the Dev mailing list