freebsd-hackers Digest, Vol 367, Issue 5
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Modifying ELF files (Patrick Mahan)
2. Re: Modifying ELF files (Nate Eldredge)
3. Re: Modifying ELF files (Peter Pentchev)
4. Re: random FreeBSD panics (Anoop Kumar Narayanan)
5. Re: Modifying ELF files (Patrick Mahan)
6. Re: random FreeBSD panics (Masoom Shaikh)
7. Re: kern/104406 on 8.0-RELEASE-p2 ? (Victor Sudakov)
----------------------------------------------------------------------
Message: 1
Date: Thu, 08 Apr 2010 07:17:46 -0700
From: Patrick Mahan <ma...@mahan.org>
Subject: Modifying ELF files
To: freebsd...@freebsd.org
Message-ID: <4BBDE58A...@mahan.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In my job, we are producing applications and KLM's for our product
that require them to be signed so that our installer will recognize
and validate our images.
The signature is stored in each app as
unsigned char signature[40] __attribute__((section(".compsign")));
What I need to do is open the file for writing, locate the ".compsign"
section and stuff in the signature, write it out and close the file.
(simple ELF manipulation)
An 'ls -l' shows the following:
% ls compklm.ko
-rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50 /home/pmahan/temp/compklm.ko
When I try to run my program
./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko
open: Text file busy
Googling and looking at the kernel sources, it seems that it detects
this file contains 'shared text', that is, it is an executable file
and does not allow me to open it for writing.
I understand (from my google search) this is a means to keep you from
shooting yourself in the foot. But there has got to be a way and I
really don't want to grovel through the compiler code to find it. I
looked at using libelf.so but it also requires that the file be open
for writing. So I am kinda of stuck. If I cannot find a quick solution
we might need to do all of our signing on our FC11 box which does not
have this issue.
Thanks for the education I always get from this list,
Patrick
------------------------------
Message: 2
Date: Thu, 8 Apr 2010 08:14:00 -0700 (PDT)
From: Nate Eldredge <na...@thatsmathematics.com>
Subject: Re: Modifying ELF files
To: Patrick Mahan <ma...@mahan.org>
Cc: freebsd...@freebsd.org
Message-ID: <Pine.GSO.4.64.10...@zeno.ucsd.edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Thu, 8 Apr 2010, Patrick Mahan wrote:
>
> In my job, we are producing applications and KLM's for our product
> that require them to be signed so that our installer will recognize
> and validate our images.
>
> The signature is stored in each app as
>
> unsigned char signature[40] __attribute__((section(".compsign")));
>
> What I need to do is open the file for writing, locate the ".compsign"
> section and stuff in the signature, write it out and close the file.
> (simple ELF manipulation)
>
> An 'ls -l' shows the following:
>
> % ls compklm.ko
> -rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50
> /home/pmahan/temp/compklm.ko
>
> When I try to run my program
> ./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko
> open: Text file busy
>
> Googling and looking at the kernel sources, it seems that it detects
> this file contains 'shared text', that is, it is an executable file
> and does not allow me to open it for writing.
My understanding was that ETXTBSY occurs when you attempt to open for
writing a file which is actually being executed, i.e. is mapped into some
process. I'm not aware that open(2) actually looks at the file itself to
see if it is an executable; that would be very surprising to me.
What does "fstat -m compklm.ko" say?
What happens if you "cp compklm.ko foo.ko" and try to sign foo.ko? You
should then be able to do "mv foo.ko compklm.ko"; if compklm.ko is
in fact mapped into some process, it will continue to use the original
version, which will be kept around (invisibly) until all mappings go away.
This is what compilers, install(8), etc, normally do.
Does your signfile program do anything with the target file before
open(..., O_RDWR)?
--
Nate Eldredge
na...@thatsmathematics.com
------------------------------
Message: 3
Date: Thu, 8 Apr 2010 18:03:49 +0300
From: Peter Pentchev <ro...@ringlet.net>
Subject: Re: Modifying ELF files
To: Patrick Mahan <ma...@mahan.org>
Cc: freebsd...@freebsd.org
Message-ID: <2010040815...@straylight.ringlet.net>
Content-Type: text/plain; charset="us-ascii"
On Thu, Apr 08, 2010 at 07:17:46AM -0700, Patrick Mahan wrote:
>
> In my job, we are producing applications and KLM's for our product
> that require them to be signed so that our installer will recognize
> and validate our images.
>
> The signature is stored in each app as
>
> unsigned char signature[40] __attribute__((section(".compsign")));
>
> What I need to do is open the file for writing, locate the ".compsign"
> section and stuff in the signature, write it out and close the file.
> (simple ELF manipulation)
>
> An 'ls -l' shows the following:
>
> % ls compklm.ko
> -rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50 /home/pmahan/temp/compklm.ko
>
> When I try to run my program
> ./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko
> open: Text file busy
>
> Googling and looking at the kernel sources, it seems that it detects
> this file contains 'shared text', that is, it is an executable file
> and does not allow me to open it for writing.
>
> I understand (from my google search) this is a means to keep you from
> shooting yourself in the foot. But there has got to be a way and I
> really don't want to grovel through the compiler code to find it. I
> looked at using libelf.so but it also requires that the file be open
> for writing. So I am kinda of stuck. If I cannot find a quick solution
> we might need to do all of our signing on our FC11 box which does not
> have this issue.
It's not the compiler code you want to find it, but the install(1)
program that is used to, well, install files into e.g. /bin, /usr/bin,
etc. What it does is create a temporary file in the directory where
it wants to place the final file, write into the temporary file, and
then, when the file is complete and only when it is complete, it
does a rename(2) syscall, moving the temporary file "over" the real
one. If a program (or the kernel) is using the old version of
the real file, its inode and its data blocks are still present on
the disk and they are only deleted when the last consumer closes
the file (or rather, the file descriptor it's holding on that inode).
This also guarantees that anyone who tries to open the file will
only open it "when it's ready", and will not try to execute
a partially-written-out executable or something.
So, what you need to do if you want to modify a file is create
a new one in the same directory (well, it's really "on the same
filesystem", but the most portable way to ensure that is to
use the same directory - unless you require from the user to
specify a temporary directory you can use on the same filesystem).
Then, read the original file, write into the new one, and when
you're ready, do a rename(tempfile, realfile).
Hope that helps.
G'luck,
Peter
--
Peter Pentchev ro...@space.bg ro...@ringlet.net ro...@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100408/97dcc91a/attachment-0001.pgp
------------------------------
Message: 4
Date: Thu, 8 Apr 2010 22:15:00 +0530
From: Anoop Kumar Narayanan <anoo...@gmail.com>
Subject: Re: random FreeBSD panics
To: Masoom Shaikh <masoom...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org, Ivan
Voras <ivo...@freebsd.org>, freebsd-...@freebsd.org
Message-ID:
<w2h7ff5545f1004080945pf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh <masoom...@gmail.com> wrote:
> On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
>> On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
>>
>>> lets assume if this is h/w problem, then how can other OSes overcome
>>> this ? is there a way to make FreeBSD ignore this as well, let it
>>> result in reasonable performance penalty.
>>
>> Very probably, if only we could detect where the problem is.
>> Try adding "options PRINTF_BUFR_SIZE=128" to the kernel
>> configuration file if you can, to see if you can get a less mangled
>> log outout.
>>
>
> ok, after few days of silence I am back with more questions
> this time system feels little better, it is able to sustain for more
> time that what 7.3-RELEASE could
>
> FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
> 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64
>
> I am using KDE4, and when OS freezes, well it freezes, means I cannot
> change to tty0 and see the panic text, if any it might possibly have
> spit. the stuck frozen GUI keeps staring there. So the question is how
> to I capture that panic text ? unfortunately I am not getting core
> files too, so there is nothing I can pick up hints
>
> is there some option (KDB, DDB), so that on panic system drop to debugger ?
>
> Masoom Shaikh
I am having the very same problem, with my AMD64 running i386 (both
7.3-REL and 8.0-REL) keeps crashing, The best part is, if I disable
ACPI it crashes before it even boots up so is the case with safe-mode
and single-user-mode. With ACPI it boots up but crashes after a while.
I have the vmcore files on the system. Who do I contact on this regard
?
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
------------------------------
Message: 5
Date: Thu, 08 Apr 2010 10:22:26 -0700
From: Patrick Mahan <ma...@mahan.org>
Subject: Re: Modifying ELF files
To: Nate Eldredge <na...@thatsmathematics.com>
Cc: freebsd...@freebsd.org
Message-ID: <201004081726....@ns.mahan.org>
> On Thu, 8 Apr 2010, Patrick Mahan wrote:
>
> >
> > In my job, we are producing applications and KLM's for our product
> > that require them to be signed so that our installer will recognize
> > and validate our images.
> >
> > The signature is stored in each app as
> >
> > unsigned char signature[40] __attribute__((section(".compsign")));
> >
> > What I need to do is open the file for writing, locate the ".compsign"
> > section and stuff in the signature, write it out and close the file.
> > (simple ELF manipulation)
> >
> > An 'ls -l' shows the following:
> >
> > % ls compklm.ko
> > -rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50
> > /home/pmahan/temp/compklm.ko
> >
> > When I try to run my program
> > ./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko
> > open: Text file busy
> >
> > Googling and looking at the kernel sources, it seems that it detects
> > this file contains 'shared text', that is, it is an executable file
> > and does not allow me to open it for writing.
>
> My understanding was that ETXTBSY occurs when you attempt to open for
> writing a file which is actually being executed, i.e. is mapped into some
> process. I'm not aware that open(2) actually looks at the file itself to
> see if it is an executable; that would be very surprising to me.
>
> What does "fstat -m compklm.ko" say?
>
% fstat -m compklm.ko
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
%
> What happens if you "cp compklm.ko foo.ko" and try to sign foo.ko? You
> should then be able to do "mv foo.ko compklm.ko"; if compklm.ko is
> in fact mapped into some process, it will continue to use the original
> version, which will be kept around (invisibly) until all mappings go away.
> This is what compilers, install(8), etc, normally do.
>
> Does your signfile program do anything with the target file before
> open(..., O_RDWR)?
>
I've just found my problem. We have a wrapper program that basically handles
parsing command line options and is suppose to adjust the argv[] array so
that it only contains the remaining non-option targets starting at index zero.
So I am doing 'open(argv[0], O_RDWR, 0)' expecting it to be the .ko file.
Turns out it was not operating as described (whipping post to be erected later);
so argv[0] actually pointed at the operating program, not the first target past
the cmd line options. *-)
Mystery solved.
Thanks,
Patrick
------------------------------
Message: 6
Date: Thu, 8 Apr 2010 17:46:55 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: Re: random FreeBSD panics
To: Anoop Kumar Narayanan <anoo...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org, Ivan
Voras <ivo...@freebsd.org>, freebsd-...@freebsd.org
Message-ID:
<m2kb10011eb1004081046oe...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 8, 2010 at 4:45 PM, Anoop Kumar Narayanan
<anoo...@gmail.com> wrote:
> On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh <masoom...@gmail.com> wrote:
>> On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
>>> On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
>>>
>>>> lets assume if this is h/w problem, then how can other OSes overcome
>>>> this ? is there a way to make FreeBSD ignore this as well, let it
>>>> result in reasonable performance penalty.
>>>
>>> Very probably, if only we could detect where the problem is.
>>> Try adding "options PRINTF_BUFR_SIZE=128" to the kernel
>>> configuration file if you can, to see if you can get a less mangled
>>> log outout.
>>>
>>
>> ok, after few days of silence I am back with more questions
>> this time system feels little better, it is able to sustain for more
>> time that what 7.3-RELEASE could
>>
>> FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
>> 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64
>>
>> I am using KDE4, and when OS freezes, well it freezes, means I cannot
>> change to tty0 and see the panic text, if any it might possibly have
>> spit. the stuck frozen GUI keeps staring there. So the question is how
>> to I capture that panic text ? unfortunately I am not getting core
>> files too, so there is nothing I can pick up hints
>>
>> is there some option (KDB, DDB), so that on panic system drop to debugger ?
>>
>> Masoom Shaikh
>
> I am having the very same problem, with my AMD64 running i386 (both
> 7.3-REL and 8.0-REL) keeps crashing, The best part is, if I disable
> ACPI it crashes before it even boots up so is the case with safe-mode
> and single-user-mode. With ACPI it boots up but crashes after a while.
> I have the vmcore files on the system. Who do I contact on this regard
> ?
>
>> _______________________________________________
>> freebsd-...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>>
>
can u load that file in kgdb in get backtrace ?
------------------------------
Message: 7
Date: Fri, 9 Apr 2010 17:28:49 +0700
From: Victor Sudakov <sudakov...@sibptus.tomsk.ru>
Subject: Re: kern/104406 on 8.0-RELEASE-p2 ?
To: freebsd-hackers <freebsd...@freebsd.org>
Message-ID: <20100409102...@admin.sibptus.tomsk.ru>
Content-Type: text/plain; charset=us-ascii
Victor Sudakov wrote:
> > > I seem to have symptoms of kern/104406 on a 8.0-RELEASE-p2 system.
> > > After an uptime of several days, many processes get stuck in the "ufs"
> > > state. The processes which had already opened some files before the
> > > deadlock continue working all right, e.g. my old login sessions are
> > > functional but I cannot start a new ssh session to the box.
> > >
> > > Can you advise me a workaround?
> > >
> > > The box is being used as a BGP (quagga) router with two full views.
> > > Hardware configuration is below:
> > >
>
> [dd]
>
> >
> > Do you have disable the flowtable options?
> >
> > # sysctl net.inet.flowtable.enable=0
> > net.inet.flowtable.enable: 1 -> 0
> >
> > This feature is default since 8 release, but is not good for bgp full
> > routing.
>
> It seems to be a different issue, kern/144917 related, but a good idea
> anyway to set net.inet.flowtable.enable=0. Thank you for the reminder.
>
> However, my box does not crash or lock up hard, just some processes
> lock up in the "ufs" state and other processes cannot access files.
With net.inet.flowtable.enable=0 the box has been working for a week
already without lockups. Is this flowtable really the cause of the
problem, or is it a coincidence?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sud...@sibptus.tomsk.ru
------------------------------
End of freebsd-hackers Digest, Vol 367, Issue 5
***********************************************