Re: calcru() warnings...

[Poul-Henning Kamp]

Is this SMP ?

In message <[EMAIL PROTECTED]>, N writes:
>Poul-Henning Kamp wrote:
>
>> I still hear reports of sporadic calcru() warnings.
>> 
>> If any of you see these, could you try to see if they correlate
>> to the uptime of the machine in question ?
>
>Should they start or stop when a machine has been running a while?  I see
>neither (negative calcru notices in dmesg start at boot time and didn't
>stop until the box had a kernel panic last Saturday evening, after about 
>two weeks uptime).
>
>FWIW, the messages started occurring when I switched from a pre-signal to
>post-signal change kernel and world.
>
>
>   -- Niels.
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: calcru() warnings...

[Vallo Kallaste]

On Thu, Nov 25, 1999 at 10:38:56AM +1030, Daniel O'Connor <[EMAIL PROTECTED]> 
wrote:

> 
> On 24-Nov-99 Poul-Henning Kamp wrote:
> >  I still hear reports of sporadic calcru() warnings.
> >  
> >  If any of you see these, could you try to see if they correlate
> >  to the uptime of the machine in question ?
> 
> I have had them for Seti@Home occasionally. The system hadn't been up for more
> than 24 hours.
> 
> Its a dual PII-350.

Same here, running setiathome means that I can find such processes
after a day or so:

4  ??  DL   -2341043:-35.26  (bufdaemon)

The ``calcru'' messages aren't strictly necessary, such things happen
without them also. Dual PIII-500, two seti processes.
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Re: Threads and my new job.

[MIHIRA Yoshiro]

[EMAIL PROTECTED] wrote:

>> *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in
>>PR bin/7587) need to be implemented.

  It's good news for me.

  I hope to port xmovie -- QuickTime movie Player for Linux to FreeBSD.
  But I can not compile it under FreeBSD, because it's need pthread_cancel. 

xmovie
http://heroine.linuxbox.com/xmovie.html

MIHIRA Yoshiro


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

Re: ps on 4.0-current

[Garance A Drosihn]

At 8:03 AM + 11/24/99, Brian Somers wrote:
> > This was discussed close to death before the changes were committed,
> > and the current behaviour (restricted access) has been agreed by
> > general consensus to be the most appropriate.
>
>My reading of the thread was ``I'm going to cache ps args to stop all
>the delving into user space to do a ps'', ``but what about the -e
>option'', ``ok, I'll make that inaccessible unless you have
>permission''.
>
>I stopped reading the -e thread because I believe it's a good thing to
>restrict this.  I completely missed that the conversation had moved
>on to ``hey, who needs ps args anyway'', and I'm sure that given the
>number of messages posted about the -e restriction, others did too.

For what it's worth, this is also what happened to me.  I tuned out
the '-e' thread once I had said my two-bits on the topic (and I was
pretty sure the end result would come out OK with me).  I did not
notice the topic of also removing argv from 'ps'.

Removing 'ps -e' ability is fine by me (though I'd prefer that I
could see the environment of "my own" processes).  I can see how
that would improve security, even if it occasionally means a very
slight loss in user convenience.

I am not at all happy with the idea of removing argv from 'ps'
listings.  I have scripts which use that information, and it
sounds like the only way to fix those scripts would make things
WORSE for security.  This does not benefit "user convenience"
and it does not benefit "security".

At the same time, I remember many years ago when another OS that
I worked on was trying for security classification.  I can see
that this behavior *could* be a good idea for situations which
want to be really paranoid about security.  I would not mind
this behavior as a system-wide option, but I'd certainly want
the default setting to match current behavior.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


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

RE: calcru() warnings...

[Daniel O'Connor]

On 24-Nov-99 Poul-Henning Kamp wrote:
>  I still hear reports of sporadic calcru() warnings.
>  
>  If any of you see these, could you try to see if they correlate
>  to the uptime of the machine in question ?

I have had them for Seti@Home occasionally. The system hadn't been up for more
than 24 hours.

Its a dual PII-350.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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

Re: Threads and my new job.

[Nik Clayton]

Jason,

On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote:
> Walnut Creek has hired me as a full time employee to work primarily on
> improving and expanding FreeBSD's threads support.  This is very exciting
> to me, and I hope my work will be of benefit the FreeBSD community.  

That's great. 

Is it part of your remit to maintain http://www.FreeBSD.org/threads/?

That URL doesn't exist at the moment, but if we're going to have an active
threads project, it probably should.  Are you (or anyone else reading this,
you don't have to be a committer at the moment) interested in keeping this
section up to date?

N
-- 
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell


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

Re: calcru() warnings...

[N]

Poul-Henning Kamp wrote:

> I still hear reports of sporadic calcru() warnings.
> 
> If any of you see these, could you try to see if they correlate
> to the uptime of the machine in question ?

Should they start or stop when a machine has been running a while?  I see
neither (negative calcru notices in dmesg start at boot time and didn't
stop until the box had a kernel panic last Saturday evening, after about 
two weeks uptime).

FWIW, the messages started occurring when I switched from a pre-signal to
post-signal change kernel and world.


-- Niels.



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

Re: ps on 4.0-current

[Wes Peters]

Warner Losh wrote:
> 
> In message <[EMAIL PROTECTED]> Peter Wemm writes:
> : 
> : In a dedicated server role, again it might be appropriate to default
> : it to "open" (dedicated server being something like a squid box),
> : again there will be a couple of sysadmin type users or people who
> : have to monitor things.  Hiding information gains nothing there
> : either.
> 
> I disagree with this, but that is because I've rarely seen a totally
> dedicated server.  A simple fileserver that does nothing else would
> want to be open in this respect since few people have accounts.
> 
> : In other roles, including something like a shell server box with presumably
> : hostile users (you reasonably have to assume this), you want everything you
> : possibly can to be locked down.
> 
> Firewall, dialup boxes, dns servers, etc are good candidates to be
> locked down.

Firewall, web, dns, news, etc. servers are good candidates to be open because 
there should not be any "normal" user accounts on them, only administration 
accounts.  And darned few of those.  I think this is what Peter was getting
at.

-- 
"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-current" in the body of the message

Re: ps on 4.0-current

[Brian Somers]

> > In the last episode (Nov 23), Lyndon Nerenberg said:
> > > After you verify that this change isn't going to break things that
> > > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > > style, but sometimes is the only workable solution.

Indeed.  There's always a better way, but I've seen countless 
production systems that do this all the time.  In fact, we've only 
recently done away with all the (sysv) ``ps -ef''s where I work.

> > That won't be affected, because anyone that has kill rights to the
> > process will also see the full processname.  Now that I think about it,
> > I can't come up with a case where this is really bad.  If you're doing
> > ps'es with intent to kill arbitrary processes (in the name of debugging
> > or whatever), you're probably already root.

Or maybe you're a sysadm that's smart enough to use sudo and not run 
around with root liability in normal life.

> This was discussed close to death before the changes were committed, 
> and the current behaviour (restricted access) has been agreed by 
> general consensus to be the most appropriate.

My reading of the thread was ``I'm going to cache ps args to stop all 
the delving into user space to do a ps'', ``but what about the -e 
option'', ``ok, I'll make that inaccessible unless you have 
permission''.

I stopped reading the -e thread because I believe it's a good thing to 
restrict this.  I completely missed that the conversation had moved 
on to ``hey, who needs ps args anyway'', and I'm sure that given the 
number of messages posted about the -e restriction, others did too.

> Making this behaviour tunable would be bad; it adds another option 
> increasing complexity, and with the proposed default in most cases an 
> admin tightening up a system would never know about it in the first 
> place, rendering it useless.
> 
> I'd strongly recommend leaving things they way they are.

This change in behaviour will break production systems, and I'm 
pretty sure that the breakage will be worked around with a quick 
``chmod 4555 /bin/ps''.  Is this what we want ?  Where I work, we've 
just done away with all the sysv ``ps -ef'' calls in the system.  It 
took several weeks and a lot of testing.  I'd be pretty miffed if the 
OS shoved this down my throat prematurely as a requirement just be
cause I upgraded without knowing of the change.

Further, I assert that this change is just wrong !

Why does setproctitle() now require root privileges if nobody can 
see the results ?  This is dumb, as the only uid that we're 
protecting against is the user that's running setproctitle() !

sendmail/nfs/ppp etc can no longer give normal users information on 
what's going on via the command args (ok, you can figure out the nfs 
args).

System monitoring scripts will now have to run as root.

In fact, why do the processes owned by other users show up at all ?  
The ``you don't need to see their args'' argument can equally apply 
to needing to see the entire process you can always kill -0 a 
process if you need to know if it's running or maybe on second 
thoughts, we should restrict kill -0 - why should people have this 
functionality anyway ?

I believe the knob is required and should default to the way things 
were.

Well, that's my opinion.  I'll calm down now.

> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




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

Re: Route table leaks

[John Polstra]

I've been working on the cvsup-master route table leaks.  I haven't
found the bug yet, but I've got some clues now.  If this info inspires
a Eureka! from any of you, please let me know.

I started by running this script to print out key information every
2 seconds while I ran a test:

#! /bin/sh

while :; do
date "+%H:%M:%S"
vmstat -m | grep 'routetbl[ ]' || exit
netstat -ran | egrep 'default|206\.213\.73\.12' || exit
echo "=" || exit
sleep 2 || exit
done

(Yes, this is crude.  But remember, the machine is 900 miles away and
I'm trying not to disrupt service too much.)

The output began like this:

19:41:56
 routetbl  3682   518K522K 21221K114730 0  16,32,64,128,256
default204.216.27.17  UGc  1823   60  wb0
=
19:41:58
 routetbl  3682   518K522K 21221K114730 0  16,32,64,128,256
default204.216.27.17  UGc  1823   60  wb0

I.e., there were 3682 route table structures in use, and 1823
references to the default route.  Then I made a connection to the
CVSup server from one of my own machines (206.213.73.12):

19:42:00
 routetbl  3684   518K522K 21221K114750 0  16,32,64,128,256
default204.216.27.17  UGc  1824   60  wb0
206.213.73.12  204.216.27.17  UGHW1   64  wb0

So far, so good.  A cloned route was created and the refcount on the
default route was incremented by one.  Two new route table entries
were allocated, and that seems to be normal and OK.

I immediately closed the connection, and it entered the TIME_WAIT
state on cvsup-master.  The script output remained as above for 60
seconds (2 * MSL), after which it changed to this:

19:42:59
 routetbl  3684   518K522K 21221K114750 0  16,32,64,128,256
default204.216.27.17  UGc  1824   62  wb0
206.213.73.12  204.216.27.17  UGHW3   0   64  wb0   3600

This still looks OK.  The cloned route has gained the "3" flag and
a 1-hour expiration time.  That is because the TIME_WAIT state has
ended, the PCB has been discarded, and the cloned route is now being
managed by the caching code in "sys/netinet/in_rmx.c".  (That's what
the "3" flag signifies.)  The basic idea of this code (as I understand
it) is to keep cloned routes for dead connections around for awhile
in case they are needed again soon.  That's useful since the cloned
routes contain RTT estimates and so forth.

Now we get to the interesting part.  One would expect the route to
remain cached for 3600 seconds.  There are ways that in_rmx.c can
expire it sooner than that, but I confirmed that those situations
(e.g., too many cached routes) aren't arising.  Nevertheless, the
route is deleted after roughly another 200 seconds:

19:46:14
 routetbl  3684   518K522K 21221K114780 0  16,32,64,128,256
default204.216.27.17  UGc  1824   64  wb0
206.213.73.12  204.216.27.17  UGHW3   0   64  wb0   3405
=
19:46:16
 routetbl  3682   518K522K 21221K114800 0  16,32,64,128,256
default204.216.27.17  UGc  1823   64  wb0

Using DDB and some of routed's tracing options I determined that
routed is deleting the route.  More on that later.  Anyway, given
that the route is being deleted, things still look OK in the above.
The route is deleted, the 2 route table entries are freed again, and
the refcount on the default route is decremented back to its
original value.  But look what happens in the next 2 seconds:

19:46:18
 routetbl  3684   518K522K 21221K114820 0  16,32,64,128,256
default204.216.27.17  UGc  1824   64  wb0

The 2 entries were allocated again and the refcount on the default
route was incremented.  Why?  I don't know (yet).  But the numbers
remain that way thereafter.  That's the leak, and I can reproduce it
reliably on cvsup-master.

Unfortunately, I cannot reproduce the problem here on my own -current
machine.  I tried to simulate the environment as accurately as
possible, including running routed.  On my machine, routed deletes the
cached route before it has expired too, but the leak doesn't happen.

One other thing.  Back on cvsup-master, I changed rc.conf so that it
sets the default route statically, and I disabled routed.  That has
completely eliminated the route table leak.

Any ideas?  Using DDB remotely through a console switch really isn't
much fun.  I'd prefer a Eureka! from somebody. :-)

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron


To Unsubscribe: send mail to [EMAIL PROTE

Re: calcru() warnings...

[Louis A. Mamakos]

I got a few calcru() warnings on a dual Pentium-III Xeon system.  It had been
up for around 9 or 10 days or so; I've since rebooted it.  Specific 
configuration
available if you need it.

louie




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

Re: - current diskless is it possible ?

[Doug Ambrisko]

Holm Tiffe writes:
| Is an NFS root supported in -current ?
| How is the syntax to set the rootdevice ?
| How about /boot/loader and friends <-> and etherboot ?
| (the port is outdated, it references etherboot-2.4.5.tar.gz
| and no one has this old file anymore, current is 2.4.10)

Yes it is possible, but you need to patch sys/i386/i386/autoconf.c. included
in this message.  I've only tested in the case of netbooting so I could
broken normal booting.

Then use Etherboot.  I also included it an uuencoded update to the 
etherboot port for etherboot-2.4.10 which can boot a FreeBSD ELF kenel.  
This all works as of -current (yesterday).  Sorry it takes so long
for the port to get updated and the Linux guys keep working on Etherboot
(which BTW they has code to boot FreeBSD now and they test it).  Then I 
have to wait for someone to read the pr's that I send in.  They when someone 
finally looks at it.  It is already obsolete.  Same thing with my sdcc 
port that needs updating.

I expect Mike will kill me for this, but it works and I don't have a PXE 
rom in this machine.  I prefer a netboot panic rather then panic'ing my 
laptop when testing things.

Doug A.

Index: sys/i386/i386/autoconf.c
===
RCS file: /cvs/freebsd/src/sys/i386/i386/autoconf.c,v
retrieving revision 1.143
diff -c -r1.143 autoconf.c
*** autoconf.c  1999/11/02 19:38:27 1.143
--- autoconf.c  1999/11/24 18:39:47
***
*** 48,53 
--- 48,54 
  #include "opt_bootp.h"
  #include "opt_ffs.h"
  #include "opt_cd9660.h"
+ #include "opt_nfs.h"
  #include "opt_nfsroot.h"
  #include "opt_bus.h"
  #include "opt_rootdevname.h"
***
*** 213,224 
--- 214,231 
cold = 0;
  }
  
+ #ifdef BOOTP
+ extern void bootpc_init();
+ #endif
  /*
   * Do legacy root filesystem discovery.
   */
  void
  cpu_rootconf()
  {
+ #ifdef BOOTP
+ bootpc_init();
+ #endif
  #if defined(NFS) && defined(NFS_ROOT)
  #if !defined(BOOTP_NFSROOT)
if (nfs_diskless_valid)
***
*** 226,232 
rootdevnames[0] = "nfs:";
  #endif
  #if defined(FFS) && defined(FFS_ROOT)
!   setroot();
  #endif
  }
  SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)
--- 233,240 
rootdevnames[0] = "nfs:";
  #endif
  #if defined(FFS) && defined(FFS_ROOT)
! if (!rootdevnames[0])
! setroot();
  #endif
  }
  SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)


begin 664 etherboot.tgz
M'XL(`!G].C@"`^U<:7/:3!+V5_0K>AW7QCG0?0`;4B$@>UD;<`%.]D.J>(48
M@0HA:768>%/Y[]LS`HP=9_VFUH%L/$]L(XE6S]'SS'2/6B'9C"3C*,JD@Y\&
MT&7+,N``0)55DWXBY-7GZ@0L63$-R]0T%4!1%=DX`.-@!\C3S$D`#IS%./'3
M>?0]N>6,D.#@MP/9V+_Y82#MU_ZR9FJF;%+[&YK,[;][^_?QX/'+4&39-/7_
M8G]-H_:7=471=(O:7].I_65N_Y^.6IR2Y(HDM77[W[E7:4W"/\(!Q^^/._PG
M<93Z691<[Y3_NG*'_[II:IS_NP!ENN0EA(S3B11'299*(>'Q!)$4VI$X4P(#&H%LAJ3=5JN@5*
MM5J5)*$E4:E4DMAQ[&3N[.9L/F5'G$[_Q_POS+OG^%\W#.;_JPJ/__=B_Y^Q
M"_`G[2];NJKIAD+M;VH:M_^^[/_8NP`_'O_KAJ;R]9_'_QQ[X?\C[P(\'/];
M=_AO6!:/_W^)^+\8%GPN>$K\?^Q=@(?Y;][EOZKJG/\[X?]B8F#HKWX;^AO:
M)O3G]'\R_,?A\.AE/,1_53:VXG^+QG\X&W#^[P*=E@''FT%0UD555&01NT2<
M_OL%U(%,7&-<'>MCLZ*ZQ-,UIVIZRMBJ&(8SUCQ%8`K&?IAG?I"65;$J*J(L
MJL:6#E4S9$>MJ%[%FQC:6)>KGJ%JQ+(\UQU799U/+[\"_]<;P0>[YK\JFS?[
M?[HF%_L_!N?_+O`,NF0)S/$'-PH"XF8^>@*+U6``+TIJ:*.;YX'/X`-)4BJ3
MD'_E?D(F->;"B0I^U7(R`FY"\*.XS![OF-"($S]@[@0*?9Q%BQK<02O*I]!8
MV0#>;'8CEC,_S0(BNM'BK?`,[SXZP6#E_:!5@_NBE?4@?GT%BF@4#HQ*D?4XKB#W5]?%K#F[>X0?^U^O71?CPO"^\OV>6O4LB_L;HLVUTD7
MM:,O%[W^<-!J][^N*DDO"T*W-[IH-,\:I]AC083C*?)P2(6>/\T3AXVJD+@D
M39WD6K@,C48A%%WW^5TL0M:ZJPW8`ZCI=[
M5AR`9U@"F>"?)5KX:C5,L193)Z4#&29.YJ`N(4Y(>5TS4A-*[@2VR[[56?`W
MVOU8HBAM;H'R+$JSNJ]5S'(>SL-H&997,30)O$+_./>#R9_23;DF").H[(%OIIK,FDEAM
MV'VK0@#'(R0X?KP@BN-K\!?.E(AX!_GL9Z`(@NB';I!/"+S!5HF4:^)B_I8O
MU;_M^K]^I/OX9?Q`_J=N*NSYGZ&:_/G/?NS//LN.L[OXS]3UU?Z/;"F6RO9_
M9+[_NQ.\?/D2UDX3.B#^M'22^-!S,U!5D*LUQ:II10Z(4"Z7-Z)WI2HU=27U
M\C;H.5CZ:ZL*[)0JP=.*#'A4%@":)^>-T\&K>JGG..%=\]I+6&0.>X<%CCD8$SP)\!EVM3E^1C2")8$9LX5+LK$"6!!%E%R
M31?IA`A[X?]X9_S'>=_8\%]C^S]\_W>7_&\RO_8^]JMR3=YB?R'XK0Q&5=_E
M?D5]7:D4W+]%Y$YOV()RJ]W!>&'4L;N7!:V>@1TZXR+PA%6H!W1\%AXJI'E,
M*2[\!26WM#5ZE\,1TX4Z[?.3XGBM\@1UQ>CLQID?3ID7/"&>DP<98'R0^0L2
MY1D3W-8X.!N][_6&=14U-KH##().&I?GPSH][MK#C[W^&>N4HH'?SF;_5<(O3_M^RN`9K[6U1OOCY[JZ_F23DOKC8;#S5@49X>WO@A]EUYZA9>\$.[#_SWD'^,?MKVD*
MS__=D_T?_QW@'\O_I>N_KBH\_W'E!=[)]$MPF8
MI`FJ4M/U]38!SRG^5?E?#(9'+N/A]1_Y;UJ:H2(L]OZGI?/U?R?HDHP]?%@_
MB7#$*,\D^_P$BJ0T'@8\)?ZS2?[1RW@P_T-E_)?I__YAZ$7^C\;YOQ,,9SY-
M_)T06#HIT"<`?N@$U^`ET>)F4@@G-!4A9$F#YW2/';PHF*LZL3/V\13]2A&@G4'F9?'SE.DKYAD0J"`=B"DJ
M*82<((U@AM5R8$'"_$;-M2@((JW@7X&FJ19/3E$L(2S1,0,_!);T<3.ZBS12
MU&M/_`P.BR?9AX)/VX1>S\1/B$MC7O98=A&A)@^;EB=884'H1AE!.>PIOZ@,
M2\YPHR3)8Y;8ZJ=ICCU(NZ@--/LSCN(\<-A=A+7*#[U(2+,D=ZE2E&*9JED$
M013-`6N`M:+%BL(^^<_#^`\X[=E0`'@```<'
`
end


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

Re: calcru() warnings...

[Bob Bishop]

Hi,

At 8:00 pm +0100 24/11/99, Poul-Henning Kamp wrote:
>I still hear reports of sporadic calcru() warnings.
>
>If any of you see these, could you try to see if they correlate
>to the uptime of the machine in question ?

Nov 23 00:03:35 bludnok /kernel: [boot]

Nov 24 09:02:06 bludnok /kernel: calcru: negative time of -4660895 usec for
pid 76002 (cc)

Ie up just under 9 hours. Building world at the time. This box is running
SMP, full details on request.


--
Bob Bishop  (0118) 977 4017  international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254  between 0800 and 1800 UK




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

- current diskless is it possible ?

[Holm Tiffe]

Hi,

I have an unconventional setup at home, my PC and an little 386/40 w/o
NPU and disk that is routing my net over an ISDN line with i4b
to the world.
(the router is because there are no free slots anymore in the PC to put
the ISDN card in, it is an oldish dual P100 EISA/PCI machine running -current
from 3 days ago)
So far so good.
The problem is, the os on this little diskless router is dated. It is a
pre ELF 3.0-current with an I4b from this time too.

I have had some problems to get my setup with an new provider (new job)
working on an ascent max 1800 and I have decided to update this old router.

The router has an wd8013 with an nb8390 boot rom, this seems to make an a.out
kernel the way to go (currently)

(the linker claims on an symbol _swapdev that he cloudn't find, please someone
from the committers can comment this symbol out in sys/i386/i386/symbols.raw
nobody needs it anymore)

Now I get the Root mount failed: 22 - problem and the machine is asking nicley
for a root device. NFS is NOT listed in the list of possible bootdevices, only MFS ?!
and something like nfs:139.20.129.5:/usr1/testroot seems to be totally wrong here
  ^^
I get :
no search device: testroot
setrootdevname failed.
(from my memory, may be a little incorrect)

the panic following later is surely related on to this, but it is a page fault.

What should I do ?

Is an NFS root supported in -current ?
How is the syntax to set the rootdevice ?
How about /boot/loader and friends <-> and etherboot ?
(the port is outdated, it references etherboot-2.4.5.tar.gz
and no one has this old file anymore, current is 2.4.10)

Any hints ?

Thanks in advance,

Holm
PS: sorry for my poor english
-- 
FreibergNet Systemhaus GbR  Holm Tiffe  * Administration, Development
Systemhaus für Daten- und Netzwerktechnik   phone +49 3731 781279
Unternehmensgruppe Liebscher & Partnerfax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13http://www.freibergnet.de/



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

calcru() warnings...

[Poul-Henning Kamp]

I still hear reports of sporadic calcru() warnings.

If any of you see these, could you try to see if they correlate
to the uptime of the machine in question ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

HEADS-UP: bdevs have been assimilated.

[Poul-Henning Kamp]

I belive I have now fully assimilated the bdevs into the cdevs in
the kernel.  This means that we have reached the day where it should
be of no consequence if you mount /dev/wd0a or /dev/rwd0a.

Vinum users: Don't do anything to your vinum configuration until
grog tells you it is OK!

To test this, take your /etc/fstab file and put a 'r' in front of
the device names, ie. change:

/dev/ad0s1a   /   ufs rw 11
to
/dev/rad0s1a   /   ufs rw 11
 ^
and reboot and see if your system feels any different.

If I don't hear reports of trouble, I will go a head with the semifinal
and final steps of the operation:

change MAKEDEV / sysinstall to create only cdevs.

Make the bmaj -> cmaj table static and historical and remove
the d_bmaj field from cdevsw.

Poul-Henning

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Threads and my new job.

[Geoff Buckingham]

On Wed, Nov 24, 1999 at 01:31:44PM +, Nick Hilliard wrote:
> > Why do we need to smite the Linux database servers? With threads in their 
> > current state they already outperform Linux's native threads by ~50x for 
> > things like sending mail. I would assume that the differences in database 
> > performance is similar.
> 
> The threads (& the old nfs issues which have now thankfully been fixed) in
> their current state led bCandid to write about the Cyclone news router:
> 
> : Issues the w/FreeBSD kernel and buggy threads have required our development
> : team to wait until improvements to the OS can be made.  We did have a beta
> : posted on our website for a while but have since removed it.
> 
> disclaimer: I am not a thread hacker.


To this I would add that a number of commercial products currently available
for FreeBSD depend on the Linux threads implimentation, notably Inktomis'
depending on the future of the linux threads stuff, some diplomacy and 
vendor support may be necesary.

What is the current status of the linux threads (Particularly with regard to
SMP, which I recall was a problem)?

How far from the userland bound original has libc_r moved ?

Is the BSDi thread stuff completely seperate from all of this?

-- 
GeoffB 


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

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: So please explain the logic you want implemented once people have
: stopped haggeling about it, it is rather trivial.

OK.  I'll likely state what I'd like to see as a patch.

: I pressume we want the same policy for /proc/*/cmdline as for the
: sysctl ps(1) uses ?

Yes.  I'll firm this up later today and send an exact proposal out so
we can kill this.

Warner


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

Re: Make buildworld blowing up

[Christopher Shumway]

On Tue, 23 Nov 1999, David O'Brien wrote:

> > Anyone have any ideas whats going on here?
> 
> Yep.  ;-)
>  
> > yacc: e - line 30 of "c-parse.y", syntax error
> > %expect 51
> > ^
> > *** Error code 1
> 
> The problem is rev 1.92 of src/Makefile.inc1.  With that change, the
> tools needed to build GCC aren't made first.  I added a few Bison-like
> features to Byacc that GCC depended on.  The non-tradional "%expect" is
> one of them.
> 
> If you manually build and install src/usr.bin/yacc/, a `make world'
> should then work.  Acutally, you should also do the same for
> src/gnu/usr.bin/bison/ as I think you'll hit another problem later in the
> build.

Excelent, that got me past the first hurdle :)

But now its blowing up when compiling
/usr/src/gnu/usr.bin/binutils/gdb/

/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:39: readline
/readline.h: No such file or directory
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:40: readline
/history.h: No such file or directory
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function
 `line_completion_function':
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: `rl_co
mpleter_word_break_characters' undeclared (first use in this function)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: (Each
undeclared identifier is reported only once
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: for ea
ch function it appears in.)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function
 `readline_line_completion_function':
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1885: `rl_li
ne_buffer' undeclared (first use in this function)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1885: `rl_po
int' undeclared (first use in this function)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function
 `command_line_input':
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:2087: warnin
g: assignment makes pointer from integer without a cast
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function
 `show_commands':
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3254: syntax
 error before `*'
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3261: `histo
ry_base' undeclared (first use in this function)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3298: invali
d type argument of `->'
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function
 `init_main':
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3467: `rl_co
mpletion_entry_function' undeclared (first use in this function)
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3470: `rl_re
adline_name' undeclared (first use in this function)
*** Error code 1
Stop.




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

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Warner Losh writes:
>: sef has sent me patches that I've not had a chance to review that
>: appear to implement this.
>
>Actually, these patches do something else.  My mistake for reading
>them before caffeine.

So please explain the logic you want implemented once people have
stopped haggeling about it, it is rather trivial.

I pressume we want the same policy for /proc/*/cmdline as for the
sysctl ps(1) uses ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Overflow in banner(1)

[Dan Moschuk]

| sizeof() is an operator whose value is determined at compile time.
| sizeof(*buf) gives the size of what buf points to.  This would be `1' if
| buf were a char*, or `4' if buf were an int* [on the i386].

Ahh, so I've probably seen this concept used only on structures then.

-- 
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"


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

Re: Overflow in banner(1)

[David O'Brien]

> I've never done this myself, but I've always been under the impression that
> sizeof(*buf) would work for dynamically allocated buffers.

sizeof() is an operator whose value is determined at compile time.
sizeof(*buf) gives the size of what buf points to.  This would be `1' if
buf were a char*, or `4' if buf were an int* [on the i386].

-- 
-- David([EMAIL PROTECTED])


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

Re: Threads and my new job.

[Kip Macy]

I will admit that I have had odd behaviours with threads in developing 
Lyris on FreeBSD that I have not seen on Solaris, NT, or Linux. I will 
see things like what appears to be the thread scheduler stop scheduling 
threads and just do a busy wait. I have not tracked it down any further 
for lack of time.
-Kip

On Wed, 24 Nov 1999, Nick Hilliard wrote:

> > Why do we need to smite the Linux database servers? With threads in their 
> > current state they already outperform Linux's native threads by ~50x for 
> > things like sending mail. I would assume that the differences in database 
> > performance is similar.
> 
> The threads (& the old nfs issues which have now thankfully been fixed) in
> their current state led bCandid to write about the Cyclone news router:
> 
> : Issues the w/FreeBSD kernel and buggy threads have required our development
> : team to wait until improvements to the OS can be made.  We did have a beta
> : posted on our website for a while but have since removed it.
> 
> disclaimer: I am not a thread hacker.
> 
> Nick
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
> 



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

Re: Overflow in banner(1)

[Dan Moschuk]

| Now rather than try to call us stupid, Kris (and only Kris) could say,
| "well, I've decided to go with a dynamically allocated buffer, so of
| course I can't use sizeof() any more".

I've never done this myself, but I've always been under the impression that
sizeof(*buf) would work for dynamically allocated buffers.

-- 
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"


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

Re: FreeBSD security auditing project.

[Warner Losh]

In message <[EMAIL PROTECTED]> Dan Moschuk writes:
: I have a set up diff's that introduce OpenBSDs concept of random pids and
: source port (with a sysctl knob for you sequential weenies) that will have
: to be updated again before I commit them.

I'd like to review this before it goes in, but if I'm unresponsive
don't let this request stop you.

This is the second class of things we can do to FreeBSD to make it
more secure.  One is to find bugs in the current programs that might
lead to root (and others that don't, since bugs are bugs).  The other
is to step back and say "hey, if we did blah, then it would
significantly deter foo attacks."

Warner


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

Re: FreeBSD security auditing project.

[Michael Kennett]

Garrett Wollman wrote:
> 
> Perhaps if name[] had been declared thus:
> 
> #define   INTTYPE_NCHARS(t) ((sizeof(t) * 3 * CHAR_BIT + 7) / 8)
> 
>   char name[(sizeof "ipfw: ") + INTTYPE_NCHARS(int)];

Or alternatively (removing a bit more magic):

#include 

#define INTTYPE_NCHARS(t)   (howmany (sizeof(t) * 3 * CHAR_BIT, 8))

The macro howmany() is quite useful. It is also in 

Mike Kennett
([EMAIL PROTECTED])



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

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Warner Losh writes:
: sef has sent me patches that I've not had a chance to review that
: appear to implement this.

Actually, these patches do something else.  My mistake for reading
them before caffeine.

Warner


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

Re: FreeBSD security auditing project.

[Warner Losh]

In message <[EMAIL PROTECTED]> Alexey Zelkin writes:
: What's going on with FreeBSD Auditing Project
: (http://www.FreeBSD.org/auditors.html) ?  Is it still alive ?
: I think this task is task of this project members. Or will be ;-)

Went gangbusters for a short while.  Everybody was jazzed.  Parts of
the tree had bugs fixed.  Some bug fixes wound up on the floor.  Poor
central coordination and management of this project was likely a
factor.  It accomplished some things, but left others undone.  It
found nothing major that was snuck in while freefall's root had been
compromised (which was the impetus behind the project in the first
place).

Warner



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

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Peter Wemm writes:
: For example, in "workstation" mode, the reasonable default is "open",
: because typically there is one user on the box (other than root) and that
: person has root access.  Excessive hiding info from that user just means
: that they'll have to use root more, or will give up the idea of using a mortal
: user entirely and run everything as root (a Really Bad idea, think of Windoze
: and viruses etc etc).

True.

: In a dedicated server role, again it might be appropriate to default
: it to "open" (dedicated server being something like a squid box),
: again there will be a couple of sysadmin type users or people who
: have to monitor things.  Hiding information gains nothing there
: either.

I disagree with this, but that is because I've rarely seen a totally
dedicated server.  A simple fileserver that does nothing else would
want to be open in this respect since few people have accounts.

: In other roles, including something like a shell server box with presumably
: hostile users (you reasonably have to assume this), you want everything you
: possibly can to be locked down.

Firewall, dialup boxes, dns servers, etc are good candidates to be
locked down.

: Oh for ACL's, privilige attributes, etc.  It would solve this sort of thing
: nicely so that you could allow admin users to see what's going on
: (including a ps -ax and see what the users are running) without having to
: constantly (ab)use root and the dangers of overusing that.

sef suggested this be a procfs mount option.  I think I like this more
than the sysctl option, but don't strong opinion either way (sysctl is
more like most of the rest of the system, while a mount option would
be harder to change on the fly).  Having it be a mount option would
make it possible to have a GID that the files are "owned" by that
could be 'operator' so that operators can see the args, and possibly
other things.

Warner


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

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Warner Losh writes:
: 
: >Not all will agree with this, and it is a change from the past so
: >there needs to be a sysctl to control this.  And given that it is a
: >radical change from the past, it needs to default to open.
: 
: Now, I can't tell if you wore the security-master hard-hat in this
: email or not, and I see some quite divergent australian positions,
: so I will sit tight until I see a little bit more of a consensus.

It was with my hat on, but lemme explain a little how I got here.

Before the recent changes to ps, procfs used to not disclose the
command line.  When it was modified to be used with a ps that didn't
need to be set[gu]id it lost this.  I wanted to see it restored for
those people that had depended on this, but realized that it would be
unpopular (and unnecessary) for many people.  As part of the change to
restore the behavior, I wanted the sysctl.  Now that it is half there,
I'd like the other half to complete the picture.

The reason that it was a big deal to me was that on the old system if
you turned off the setuidness of ps, w, et al you would block
disclosure of args/env vars, etc, but still have access to process
lists.  With the change, there was no way to do this which represented
a weakening of the overall system on the whole, despite the strenth
added by taking the setgid bit off ps.

sef has sent me patches that I've not had a chance to review that
appear to implement this.

Warner


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

Re: FreeBSD security auditing project.

[Dan Moschuk]

| Hello FreebSD'ers!
| 
| [ Apologies to committers, I have Bcc'ed you to ensure you got
|   this; you may get two copies. ]
| 
| I have been charged with the duty of ensuring that FreeBSD gets a
| security audit that has the credibility of OpenBSD's.
| 
| Consider this to be a request-for-discussion that will head us over to
| the actual work of getting it done.

Great to hear that we are finally doing this. :-)

| My proposals are pretty simple;
| 
| 1) We need to eyeball _all_ of the code for potential security holes,
| and fix those ASAP.
| 
| 2) I propose that  diff(1) FreeBSD with {Open|Net}BSD, and with a
| security perspective apply those bits that look relevant and that will
| work. Who nose - we may even pick up some useful featurez!

I have a set up diff's that introduce OpenBSDs concept of random pids and
source port (with a sysctl knob for you sequential weenies) that will have
to be updated again before I commit them.

-- 
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"


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

Re: ps on 4.0-current

[Garrett Wollman]

< said:

> This was discussed close to death before the changes were committed,

Where, and by whom?  I don't recall seeing any such discussion on
-security.

> and the current behaviour (restricted access) has been agreed by 
> general consensus to be the most appropriate.

Agreed by whom?  Remember POLA?

> Making this behaviour tunable would be bad; it adds another option 

Indeed; it should be reverted completely.  Portable programs may not
rely on their argv[] being ``secret''.  Portable sysadmins rely on
argv[] not being ``secret''.

Having bogus behavior such as this encourages sysadmins to do all
their work as root -- a very Bad Thing.  Not only that, it violates 20
years of UNIX tradition.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: FreeBSD security auditing project.

[Garrett Wollman]

< said:

> #define SNPARGS(buf, len) buf + len, sizeof(buf) > len ? sizeof(buf) - len : 0
> char action2[32], proto[47], name[18], fragment[17];
> /* Print command name */
> snprintf(SNPARGS(name, 0), "ipfw: %d", f ? f->fw_number : -1);

> Despite the fact that the buffer name[] was made to be exactly the
> largest size

Exactly the largest size of what?  All I see here is a magic number.

Perhaps if name[] had been declared thus:

#define INTTYPE_NCHARS(t) ((sizeof(t) * 3 * CHAR_BIT + 7) / 8)

char name[(sizeof "ipfw: ") + INTTYPE_NCHARS(int)];

...but even then, if KNF is followed, this declaration might be so far
away from the printf format that when the format is modified, the
programmer might forget to modify the declaration as well.

snprintf is a good thing.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: Overflow in banner(1)

[David O'Brien]

On Wed, Nov 24, 1999 at 09:58:51AM +0200, John Hay wrote:
> Well the original line is plain wrong if Brian's patch is being used,
> because there message is a pointer and the size of a pointer is 4.

Yes, yes, yes.  Warner and I are *not* that stupid WRT C.  We were both
commenting on the *original* proposed patch.  Geez.

Now rather than try to call us stupid, Kris (and only Kris) could say,
"well, I've decided to go with a dynamically allocated buffer, so of
course I can't use sizeof() any more".
 
-- 
-- David([EMAIL PROTECTED])


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

Re: Netscape and -current

[Bruce Evans]

On Tue, 23 Nov 1999, Brian Fundakowski Feldman wrote:

> On Wed, 24 Nov 1999, Bruce Evans wrote:
> 
> > Hmm.  My netscape works, but I didn't use merge that commit.  I had already
> > inadvertly fixed the bug in another way while cleaning up.
> > ...
> > #if defined(COMPAT_43) || defined(COMPAT_SUNOS)
> > if (((struct osigcontext *)uap->sigcntxp)->sc_trapno == 0x01d516)
> > return (osigreturn(p, (struct osigreturn_args *)uap));
> > #endif
> 
> I don't see how this fixes things, other than hiding it.  Since the i386

I was in a hurry and didn't notice that my inadvertent fix wasn't complete :-).

> memory model we use maps kernel and user memory all at the same time,
> this code is reading directly from user space memory, right?  If this is

It could be reading from anywhere with an invalid sigcntxp.  Reading from
certain locations may cause a panic.

> the case, wouldn't a copyin() be the proper thing to do?  At least doing
> the useracc() would be better than doing nothing, wouldn't it?

I plan to use copying and delete the useracc()'s.  This will be much faster
Checking the magic number is inconvenient, since a copyin() with size
(max of the 2 context sizes) may fail and a copyin() with size 
(min of the 2 context sizes) would leave us with an extra copyin() to do
in the usual (new sigreturn()) case.  I'll try using fuword() to read the
magic byte.

Bruce



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

Re: Threads and my new job.

[Nick Hilliard]

> Why do we need to smite the Linux database servers? With threads in their 
> current state they already outperform Linux's native threads by ~50x for 
> things like sending mail. I would assume that the differences in database 
> performance is similar.

The threads (& the old nfs issues which have now thankfully been fixed) in
their current state led bCandid to write about the Cyclone news router:

: Issues the w/FreeBSD kernel and buggy threads have required our development
: team to wait until improvements to the OS can be made.  We did have a beta
: posted on our website for a while but have since removed it.

disclaimer: I am not a thread hacker.

Nick


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

Buildworld broken in 'usr.bin/kdump' due to ipfilter

[nnd]

Buildworld of today current is broken due to
importing of ip_filter's header files with ioctls which
in turn broke building 'usr.bin/kdump'.

It seems to me that 'mkioctls' script in
'kdump' is "over-automated" - it build the list of the
'ioctl_includes' 'grepping' through the 'include' directory.
But often (as in today's sources) new files with ioctls
require manually inserting "prerequisite" includes in the
same 'mkioctl' script. May be it'll be better if we manually
insert BOTH the includes with ioctls and prerequisite files ?

N.Dudorov
 


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

Compiling XFree86 under Current

[Fritz Heinrichmeyer]

Here is how i compiled XFree86 today (an additonal file for
/usr/ports/x11/XFree86/patches):

http://es-i2.fernuni-hagen.de/~jfh/FreeBSD_Documentation/node7.html

-- 
Fritz Heinrichmeyer mailto:[EMAIL PROTECTED]
FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany)
tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh


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

Re: FreeBSD security auditing project.

[Rodney W. Grimes]

> 
> "Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> 
> > It's not so much that they where ``allowed'' to do it, it is more the
> > matter that they where never directly served with legal papers from USL/Novell
> > to cease all use of Net/2.  Nor did they ever enter into any agreement,
> > that I am aware of, with respect to Net/2 code with any party other
> > than UCB.
> 
> That's half true.  No letter ever received asked us to `cease all use
> of Net/2'.  However, as has been publically stated *numerous* times,
> there does exist an agreement between NetBSD and USL stating that,
> after certain Net/2 files were removed and certain others were updated
> to their 4.4-Lite versions, USL would not bother us again.

That agreement is different than the agreement I have before me.

> 
> > These agreements basically say that the parties would stop all use of
> > Net/2 based code and replace it with BSD4.4 Lite, [...]
> 
> That's false.  If the FreeBSD agreement is *anything* like the NetBSD
> one, it covers only specific files, not the entire source tree.

You can't make the claim that this is false, you have not seen the document,
and you can't.  I will assert my statement is true.  I can't say anymore
about it than that as the agreement itself says that it's contents are not
to be disclosed.

The agreement evedently does not look like the one that NetBSD signed.

> 
> > One could make claim that Novell/USL seriously failed to do ``due dilegence'',
> > but they where not protecting a trademark, but instead a copyright and they
> > could, if they still owned the code. come along and slap NetBSD/OpenBSD
> > with a pretty healthy law suite.
> 
> That's also false.  Worse, it's FUD.

Agreed, given the other statements.

> > Technically if I where to bring a NetBSD repository over to my box and
> > then let anyone other than myself even look at it I would be in violation
> > of the USL/Novell agreement due to the fact that the repository contains
> > Net/2 code.  :-(.
> 
> And that's false, too.

You can't know that, you don't know what my agreement says.  Unless I missed
it some place the ,v files of the NetBSD repository where not purged of
the Net/2 code, unless this was done offline in a non-public manner.  That
I might not know about.  Though the legal agreement between NetBSD and
USL/Novell may have only required NetBSD to purge certain files, my
agreement is very explicit about ALL of Net/2.

> Please check your facts before spewing about legal matters.

My facts on the legal points of this issue are probably at least an order
of magnitude more correct than yours.  NetBSD wouldn't have even seen something
as simple as what it did get from USL had I not spent a month of my time
working with Novel legal to have something palatible we (WC and myself)
could agree to.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Threads and my new job.

[Julian Elischer]

Firstly there is some threads discussion going on in -arch so 
I'm going to really reply to this over there..

This is just redirector mail


julian

On Mon, 22 Nov 1999, Jason Evans wrote:

> Walnut Creek has hired me as a full time employee to work primarily on
> improving and expanding FreeBSD's threads support.  This is very exciting
> to me, and I hope my work will be of benefit the FreeBSD community.  
> 
[chop]





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

Re: buildworld across signal changes not quite right

[Marcel Moolenaar]

David Scheidt wrote:
> 
> On Tue, 23 Nov 1999, David O'Brien wrote:
> 
> > > Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current
> > > buildworld running on an older -current system now progresses much
> > > further - in fact it now completes :-).
> >
> > Actually, I've been seeing just the opposite.
> > Before you could build a -CURRENT kernel and then the world.  Now those
> > with worlds from this past summer can't build today's world regardless
> > of which of userland or kernel is built first.
> 
> The upgrade from -STABLE is also broken because of this.  The %expect stuff
> is blowing up.  I haven't yet tried to see if building yacc and bison
> manually fixes things or not.

It will.

> I will tomorrow, when I have access to the
> box, assuming my workload doesn't try to kill me first.  (I hadn't reported
> it, because I haven't had time to investigate properly. )

Be prepared to fix gcc and dd too.

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Re: buildworld across signal changes not quite right

[Marcel Moolenaar]

Mark Murray wrote:
> 
> > I'm not sure how to fix this problem.  Unlike our other build tools,
> > perl is not designed to be able to be cross-built:  It builds bits
> > of itself and assumes they can be safely executed to build other bits.
> 
> Perl is hugely fragile; cross-building it is a big PITA. If you
> have any smart ideas, I'm all ears.

I haven't paid any special attention to it yet.

> (I may have mentioned before that I hate the perl build).

No, but it is so noted now :-)

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

ST-506, ESDI and BAD144 ?

[Poul-Henning Kamp]

Sørens new ATA driver can handle all IDE disks as far as has been
tested now, but it doesn't provide bad sector remapping which is
needed for ESDI and ST-506 disks.

Having two drivers fight for the same class of drivers is a rather
messy process, and it complicates the code a fair bit, not to
mention the clutter in end-user documentation.

Considering that most of the machines with ST-506 and ESDI disks
are limited to 16MB ram anyway, I think it would be reasonable to
simply tell the users of these old irons to stick with the 3.X
branch until end of life (there is probably at least 1.5 years more
life in the 3.X branch judging from the history of the 2.2.X branch).

So I would like to propose that we discontinue support for ST-506,
ESDI disks and BAD144 bad-sector remapping starting with the 4.0
release.

So, is anyone running -current on ESDI or ST-506 disks in 
actual applications (as opposed for the gadget/novelty thrill or
testing purposes) ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: FreeBSD security auditing project.

[Brad Knowles]

At 1:41 AM -0500 1999/11/24, Brian Fundakowski Feldman wrote:

> Our code doesn't run an a system _anything_ like that.

That may well be true today, however as FreeBSD gets more widely 
ported to other platforms, and as the "native" platforms it runs on 
progress, this might change in the future.  I'd suggest erring on the 
side of paranoia in this case.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  
|o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels   |o|
|o| http://www.skynet.be Belgium   |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.


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

Re: FreeBSD security auditing project.

[Alexey Zelkin]

hi,

 MM> I have been charged with the duty of ensuring that FreeBSD gets a
 MM> security audit that has the credibility of OpenBSD's.

What's going on with FreeBSD Auditing Project
(http://www.FreeBSD.org/auditors.html) ?  Is it still alive ?
I think this task is task of this project members. Or will be ;-)

 MM> I'll get a mailing list going if this is deemed necessary.

audit-*@FreeBSD.org ? Or create general list [EMAIL PROTECTED] ?

-- 
/* Alexey Zelkin   && [EMAIL PROTECTED]*/
/* Tavric National University  && [EMAIL PROTECTED]  */
/* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */


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

Re: FreeBSD security auditing project.

[scanner]

On Wed, 24 Nov 1999, Doug Rabson wrote:

> We need to put audit tags into the source tree when a file is audited.
> That allows the diffs to be audited later which should be a smaller job
> and then the audit tag slides forward.

Not to interrupt in the middle of this discussion but you might
want to check with robert watson before you guys get too deep here since
he is working on a FUNDED Posix.1e implementation for FreeBSD. And has
already posted some EARLY MAC code. It might be usefull to work with him
as well. Just a thought.

Chris

--

"I've always been mad, I know I've been mad, like most of us have. And you
have to explain why you were mad, even if you're not mad." -PF DsoTM

===| Open Systems FreeBSD Consulting.
   FreeBSD 3.3 is available now!   | Yahoo Messenger ID: opsys_98
---| 1402 N. Washington, Wellington, KS 67152
   FreeBSD: The power to serve!| E-Mail: [EMAIL PROTECTED]
  http://www.freebsd.org   | Consulting, Network Engineering, Security
===| http://open-systems.net



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

Re: ps on 4.0-current

[Peter Wemm]

Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> : Warner ?

[.. reasons for and against ..]

> Not all will agree with this, and it is a change from the past so
> there needs to be a sysctl to control this.  And given that it is a
> radical change from the past, it needs to default to open.
> 
> Warner

Without wanting to get "please send patches" (I fear sysinstall as much as
anyone), I think it would be really nice to create a place where we can set
a default 'security profile' or something which arranges for these sorts
of things to be set according to the role of the machine.

For example, in "workstation" mode, the reasonable default is "open",
because typically there is one user on the box (other than root) and that
person has root access.  Excessive hiding info from that user just means
that they'll have to use root more, or will give up the idea of using a mortal
user entirely and run everything as root (a Really Bad idea, think of Windoze
and viruses etc etc).

In a dedicated server role, again it might be appropriate to default it to
"open"  (dedicated server being something like a squid box), again there will be
a couple of sysadmin type users or people who have to monitor things.  Hiding
information gains nothing there either.

In other roles, including something like a shell server box with presumably
hostile users (you reasonably have to assume this), you want everything you
possibly can to be locked down.

Oh for ACL's, privilige attributes, etc.  It would solve this sort of thing
nicely so that you could allow admin users to see what's going on
(including a ps -ax and see what the users are running) without having to
constantly (ab)use root and the dangers of overusing that.

Cheers,
-Peter



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

Re: FreeBSD security auditing project.

[Doug Rabson]

On Tue, 23 Nov 1999, David O'Brien wrote:

> > So when Joe Blow clicks on (say) src->bin->cat he'll find that
> > (say) markm eyballed the code and kris diffed it with OpenBSD
> > and merged in  fixes - "cat now considered safe".
> 
> Until the next commit to cat.
> 
> A security review is never done.  We need to be in a mode where every
> commit is suspect and people are compelled to review it.  BDE's use of
> CTM to review changes is actually rather affective in this reguard.

We need to put audit tags into the source tree when a file is audited.
That allows the diffs to be audited later which should be a smaller job
and then the audit tag slides forward.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>I'm trying to figure out how what started as a fix to a panic turned into
>such a big mess.  And I don't even think the panic has even been fixed ---
>it's just been made more obscure.

The panic hasn't been fixed, as has been repeatedly stated, but at least
a SMP machine doesn't panic when you run the 3rd command they teach you in 
any "UNIX for dummies" book.

>In otherwords, nothing ps does blocks.  I can't imagine how changing 
>the way arguments are fetched by encumbering procfs with even more 
>junk would generate a sufficient boost in performance to be either 
>noticeable visually or worth doing at all.

Matt, lets talk about this when you have examined the code in some detail.

>It would be nice if the procfs panics were fixed, but not at the cost
>of all of this.

The procfs panics are not fixed, I know that Allan Cox has looked at it.

Poul-Henning

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:

>Not all will agree with this, and it is a change from the past so
>there needs to be a sysctl to control this.  And given that it is a
>radical change from the past, it needs to default to open.

Now, I can't tell if you wore the security-master hard-hat in this
email or not, and I see some quite divergent australian positions,
so I will sit tight until I see a little bit more of a consensus.

Poul-Henning

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: Warner ?

Like I've said in private mail to many different people on this issue,
there needs to be a sysctl which controls this, and it needs to be
open by default.

There are many cases where unwanted information is disclosed
inadvertantly by these arguments.  It invades the privacy of the users
to do so.  I don't want anybody to find out that I'm sending mail to
[EMAIL PROTECTED] because they can see my ps args, for example, or that my
chat script is doing stupid things and putting the password on the
command line.  or if I'm aiding law enforcement looking for the string
"SecreTTWarEzz" to see who is posting them from my machine, I don't
want anyone to know what I'm looking for.  People generally take care
to not include sensitive information on the command line, but
sometimes this can't be helped.

Not all will agree with this, and it is a change from the past so
there needs to be a sysctl to control this.  And given that it is a
radical change from the past, it needs to default to open.

Warner


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