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. , 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. :)
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
