kern/23409, atapi_queue_cmd error codes?

[Eyal Soha]

I submitted and started debugging kern/23409: CD-RW driver fails
unless CD in drive at boot up.

I seem to be getting error code 0x5 and 0x10 from acd_mode_sense()
when I'm booting up.  What do those error codes mean?  Do they
correspond to the error register bits listed in atapi-all.h?

#define ATAPI_E_ILI 0x01/* illegal length indication */
#define ATAPI_E_ABRT0x04/* command aborted */
#define ATAPI_SK_RECOVERED_ERROR0x10/* command OK, data recovered */

I ask because in the failure case of kern/23409, I see error 0x10 many
times.  In the success case, error 0x5 appears twice and then goes
away before reaching a maximum retry count.  Much more detailed
information is available in the bug report.

I'm not on the mailing list so please include me on replies.  If I've
sent this to the wrong mailing list, please forward it appropriately.
Thanks for the help!

Eyal
 
-- 
Eyal Soha <[EMAIL PROTECTED]>Work: (408) 527-9276
Software Engineer  Page: (800) 365-4578
Cisco Systems    Epage: [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

[Wes Peters]

"Daniel C. Sobral" wrote:
> 
> Warner Losh wrote:
> >
> > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> > : ported to every hardware platform under sun, and we do not go out of our
> > : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on
> >
> > What?  I don't see how you can say that about security...
> 
> We don't go *out* of our way. And just because OpenBSD has an *edge*,
> that doesn't mean said edge is all that big.

FreeBSD balances security concerns with usability, whereas OpenBSD goes for
the "security" choice every time.  This makes one of the systems more secure
without user tuning, the other more functional without user tuning.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

[Wes Peters]

"Daniel C. Sobral" wrote:
> 
> David O'Brien wrote:
> >
> > On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote:
> > > I thought the space staked out by the *BSD gang was approximately
> > > this:
> > >   NetBSD - the least amount of platform-specific code possible; run
> > >   on most anything
> > >   OpenBSD - pro-active security, bullet-proof from attacks
> > >   FreeBSD - best performing on the Intel PC platform
> >
> > s/the Intel PC/server/  The Alpha has very good I/O bandwidth and 64-bit
> > address space.  Thus it fits our niche.  You also mentioned Sparc, but
> > really should have said sparc64(pci based).
> >
> > hopefully embeded soon too.
> 
> Yep, "server" is much more to the point. And not simply best performing,
> but we also strive to be user-friendly.
> 
> The bottomline is that we, of the BSDs, do *not* have a focus. We want
> to support good servers and good desktops and good notebooks, we want to
> provide performance and user friendlyness. We do not care about being
> ported to every hardware platform under sun, and we do not go out of our
> way to provide security. Thus, NetBSD and OpenBSD have the edge on us on
> these respects, but we gain by providing a better overall enviroment on
> the platforms we support. The problem is that you can't one-line that.

BSD for the masses.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Configuring Gateway/NAT on Freebsd

[Sean Peck]

I am trying to configure a FreeBSD 3.3 box to act as a gateway/NAT
translater for my network.

I have added the following to the my rc.conf

ifconfig_tun0="inet 172.168.0.1  netmask 255.255.255.0"
gateway_enabled="YES"
natd_enabled="YES"
natd_ingerface="tun0"
and tun0 to my network_interfaces list.

The box works fine on its own, but I am unable to get boxes in my
172.168.0.x space to work through it.  I am confused a bit on what I need
to set my other boxes too, and if I am missing something on this box I
must do as well.

Should I set my other boxes to gateway to this boxes 172 address, or to
the real IP of this box?  If it is in the 172 space, how is this box being
informed it shoul be listening for it, since the only the tun0 is told it
is attached to this IP, not the actual NIC... 

Any help would be most appreciated.

Sean



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

subscribe

[Sean Peck]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Patching live kernels

[Andrew R. Reiter]

afaik, Yes.  There are two articles that I know of that deal with the
specifics of modifying binaries to inject ones own code.  The first is one
that deals mostly with libbfd (binary file descriptor) and linux.  iirc,
libbfd worked a great deal better under linux than under FreeBSD.  I
recall that libbfd under FreeBSD only supported a.out format. (yikes!)
This article can be viewed at:

http://phrack.infonexus.com/search.phtml?view&article=p56-9

The second article that I know of deals with hijacking functions in the
kernel even if they do not have a function ptr to them.  Obviously
functions that have ptrs to them can easily be hijacked via a KLD (check
out the examples.tar.gz in the Daemonnews article on KLDs).  However, I am
not sure if the author has yet published this article and I don't feel it
my place to publish it for him.  Perhaps, silvio, the author, will want to
publish it here ;)

Anyway, hope this helps.

Andrew

On Sun, 10 Dec 2000, Alfred Perlstein wrote:

> Ok, sometimes we find a bug in a particular release where what's
> needed is a function replaced with fixed code.
> 
> I'm wondering if it's possible to:
> 
> 1) look at the kernel symbol table for a particular function in a
>particular object file (static functions would be even better?)
> 2) replace the first instruction in the function with a jmp to
>our newly loaded code
> 3) have our newly loaded code be "anonymous" meaning no symbols
>from it enter the kernel symbol namespace (i want to be able to
>re-patch a patched kernel)
> 
> Is it possible?
> 
> Are there any takers? :)
> 
> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

*-.
| Andrew R. Reiter 
| [EMAIL PROTECTED]
| "It requires a very unusual mind
|   to undertake the analysis of the obvious" -- A.N. Whitehead



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Patching live kernels

[Jake Burkholder]

> Ok, sometimes we find a bug in a particular release where what's
> needed is a function replaced with fixed code.
> 
> I'm wondering if it's possible to:
> 
> 1) look at the kernel symbol table for a particular function in a
>particular object file (static functions would be even better?)
> 2) replace the first instruction in the function with a jmp to
>our newly loaded code
> 3) have our newly loaded code be "anonymous" meaning no symbols
>from it enter the kernel symbol namespace (i want to be able to
>re-patch a patched kernel)
> 
> Is it possible?
> 
> Are there any takers? :)

io# kldload ./syscall.ko
Dec 10 10:09:14 io /boot/kernel/kernel: syscall loaded at 210
io# ./call
Dec 10 10:09:26 io /boot/kernel/kernel: bad code...

(kgdb) x/6i bad_code
0xc01235a0 :  push   %ebp
0xc01235a1 :mov%esp,%ebp
0xc01235a3 :push   $0xc02cc6d0
0xc01235a8 :call   0xc0198a30 
0xc01235ad :   leave  
0xc01235ae :   ret
(kgdb) x/s 0xc02cc6d0
0xc02cc6d0 <__umoddi3+672>:  "bad code...\n"

io# kldload ./kpatch.ko
io# ./kpatch -f bad_code -t good_code
Dec 10 10:11:24 io /boot/kernel/kernel: patching from: 0xc01235a0 to: 
0xc0fbd4c4

(kgdb) x/i bad_code
0xc01235a0 :  jmp0xc0fbd4c4
(kgdb) x/6i 0xc0fbd4c4
0xc0fbd4c4: push   %ebp
0xc0fbd4c5: mov%esp,%ebp
0xc0fbd4c7: push   $0xc0fbd528
0xc0fbd4cc: call   0xc0198a30 
0xc0fbd4d1: leave  
0xc0fbd4d2: ret
(kgdb) x/s 0xc0fbd528
0xc0fbd528:  "good code!!\n"

io# ./call
Dec 10 10:13:17 io /boot/kernel/kernel: good code!!

I'm not sure if static functions are in the kernel symbol table, but you
should be able to get the address with nm and pass it to kpatch instead of
the name, ./kpatch -f 0x... -t good_code; this is untested.  Whatever symbols
are in your module will still be in the kernel symbol table, removing them is
more involved but not impossible, all the magic is in kern/kern_linker.c.
Just rename whatever function you are loading, repatch, and then unload the
old module.  If you can ensure that nothing will call the loaded code while
you're repatching you should be able to unload first to avoid the renaming.
Use with extreme caution.

Release, pff, you don't fool me  :)

Jake


# Makefile for building the sample syscall module


SRCS= kpatch-sys.c
KMOD= kpatch
KO  = ${KMOD}.ko
KLDMOD  = t

kpatch:
cc -o kpatch kpatch.c

CLEANFILES+=kpatch

.include 

CFLAGS= -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-DKLD_MODULE -nostdinc -I-   -I. -I@ -I@/../include  -mpreferred-stack-boundary=2


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

extern char *optarg;
extern int optind;

static void usage(void);

int
main(int ac, char **av)
{
struct kld_sym_lookup from;
struct kld_sym_lookup to;
struct module_stat stat;
int kfid;
int mfid;
int c;

bzero(&from, sizeof from);
bzero(&stat, sizeof stat);
bzero(&to, sizeof to);

from.version = sizeof from;
stat.version = sizeof stat;
to.version = sizeof to;

while ((c = getopt(ac, av, "f:t:")) != -1)
switch (c) {
case 'f':
if (bcmp(optarg, "0x", 2) == 0)
from.symvalue = strtol(optarg, NULL, 16);
else
from.symname = optarg;
break;
case 't':
if (bcmp(optarg, "0x", 2) == 0)
to.symvalue = strtol(optarg, NULL, 16);
else
to.symname = optarg;
break;
case '?':
default:
usage();
}

if (from.symvalue == 0) {
kfid = kldfind("kernel");
kldsym(kfid, KLDSYM_LOOKUP, &from);
}

if (to.symvalue == 0) {
for (mfid = 0; (mfid = kldnext(mfid)) != 0;)
if (to.symvalue == 0 &&
kldsym(mfid, KLDSYM_LOOKUP, &to) == 0)
break;
}

printf("from: 0x%lx to: 0x%lx\n", from.symvalue, to.symvalue);
modstat(modfind("kpatch"), &stat);
return syscall(stat.data.intval, from.symvalue, to.symvalue);
}

static void
usage(void)
{
fprintf(stderr, "usage: kpatch -f  -t \n");
exit(EX_USAGE);
}


#include 
#include 
#include 
#include 
#include 
#include 
#include 

extern char do_jmp[];
extern char do_jmp_end[];

asm(
"   .globl  do_jmp ;"
"do_jmp:"
"   jmp . + 1 << 16 ;   "
"   .globl  do_jmp_end ; 

Patching live kernels

[Alfred Perlstein]

Ok, sometimes we find a bug in a particular release where what's
needed is a function replaced with fixed code.

I'm wondering if it's possible to:

1) look at the kernel symbol table for a particular function in a
   particular object file (static functions would be even better?)
2) replace the first instruction in the function with a jmp to
   our newly loaded code
3) have our newly loaded code be "anonymous" meaning no symbols
   from it enter the kernel symbol namespace (i want to be able to
   re-patch a patched kernel)

Is it possible?

Are there any takers? :)

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

[Daniel C. Sobral]

Warner Losh wrote:
> 
> In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> : ported to every hardware platform under sun, and we do not go out of our
> : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on
> 
> What?  I don't see how you can say that about security...

We don't go *out* of our way. And just because OpenBSD has an *edge*,
that doesn't mean said edge is all that big.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"The bronze landed last, which canceled that method of impartial
choice."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

[Warner Losh]

In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: ported to every hardware platform under sun, and we do not go out of our
: way to provide security. Thus, NetBSD and OpenBSD have the edge on us on

What?  I don't see how you can say that about security...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

[Daniel C. Sobral]

David O'Brien wrote:
> 
> On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote:
> > I thought the space staked out by the *BSD gang was approximately
> > this:
> >   NetBSD - the least amount of platform-specific code possible; run
> >   on most anything
> >   OpenBSD - pro-active security, bullet-proof from attacks
> >   FreeBSD - best performing on the Intel PC platform
> 
> s/the Intel PC/server/  The Alpha has very good I/O bandwidth and 64-bit
> address space.  Thus it fits our niche.  You also mentioned Sparc, but
> really should have said sparc64(pci based).
> 
> hopefully embeded soon too.

Yep, "server" is much more to the point. And not simply best performing,
but we also strive to be user-friendly.

The bottomline is that we, of the BSDs, do *not* have a focus. We want
to support good servers and good desktops and good notebooks, we want to
provide performance and user friendlyness. We do not care about being
ported to every hardware platform under sun, and we do not go out of our
way to provide security. Thus, NetBSD and OpenBSD have the edge on us on
these respects, but we gain by providing a better overall enviroment on
the platforms we support. The problem is that you can't one-line that.
:-)

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"The bronze landed last, which canceled that method of impartial
choice."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message