Re: mktemp() patch
> > Why not just XOR the whole lot into the current ${randomnumber}?
> > That way, at least the effort of the whole calculation is not wasted
> > as much.
>
> Why to XOR true random bits from arc4random() with non-random bits from
> getpid()? It only weakens. Better way is just remove any getpid() code and
> left arc4random() only.
Rubbish. A XOR B is random if at least one of A or B is random.
That is a pretty fundamental theorem of Cryptography. My suggestion
_strengthens_ the random number. All you lose is one bit if it
turns out that BOTH A and B are random, because they get combined
into one.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
> > Then you will get collisions which you will have to deal with. I am not
> > familiar with the code but if we can handle collisions nicely then that
> > would be the way to go: 64^6 = 2^36 possibilities which is nice...
>
> 1) Just totally opposite: mixing random with non-random sources you'll get
> into collision much faster then with random source only. 2) Yet, of course,
> the code handles collisions.
Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: >It's an issue. Nice values count for less than before due to fixes > that Luoqi Chen made (and I committed). The behavior now isn't optimal, > but it is better than the system locking up. NICE_WEIGHT might be okay > to keep at 2. Try the attached diff; I'm pretty sure it won't blow > things up :) >The diff should make a process at -20 which uses all available CPU > schedule just slightly the ahead of a process at +20 which uses no CPU. > A process which uses full CPU at 0 niceness would have a priority of > 128, whereas a process using no CPU at 0 niceness would have a priority > of 90. All processes will always have a priority less than or equal to > 128, which is the priority at which a process with a niceness of +20 > always runs at. A +20 process won't get better priority than anything > else, period. Try it out, see how it works for you:) I think this is not the clear solution for descibed problem 'couse the dnetc client still gets a priority and still have the share of time while other programs might run. For me idprio works great. Just change last string in the starting shell scipt. idprio 31 su nobody -c "$dir/dnetc -quiet" 2>/dev/null >/dev/null & -- [WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
>It's probably better to just get rid of the PID and use randomness >throughout the name than to use 72 characters. 64^6 vs. 2*(72^3) . I seem to be in the minority on this, but in general I *like* the idea that the tempfiles include the pid. It's bad because it makes it easier for an evil-person to guess what the next tempfile will be, but it's nice in after-the-fact situations, where there are a bunch of tempfiles left over, and you're wondering which ones are related (in the sense of having come from the same process, and you can then check if the process is still running). Not a big issue for me, as I doubt I have taken advantage of this more often than about once every two years, but I thought I would at least mention it. --- 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: VMware detection code in boot loader
> We have inb and outb. Can't vmware be written in Forth? If inl cannot be > replaced with inb, I'd rather add inl than vmware. > But we can't set registers to specific values before inb/outb, which also means our inb/outb are quite useless in making BIOS calls. > IMHO, it would be better to add > > exec="include /boot/vmware.4th" > > to the end of your /boot/loader.conf, and either execute vmware-conf > from there or script the whole thing: > > s" arch-i386" environment? [if] > \ Get vmware version, magic > 0x564d868 ( VMware magic ) = [if] > .( VMware version ) . cr > .( Loading /boot/vmware.conf...) cr > s" /boot/vmware.conf" read-conf > [else] > drop > [then] > [then] > > Either way, no changes to /boot/loader.rc would be required. > This looks much better, I didn't know we could tell the loader to execute a script in loader.conf. > -- > Daniel C. Sobral (8-DCS) > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Hmmm - I have to go check this. My reality assumptions are shattered. > -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Luoqi Chen wrote: > > > We have inb and outb. Can't vmware be written in Forth? If inl cannot be > > replaced with inb, I'd rather add inl than vmware. > But we can't set registers to specific values before inb/outb, which also > means our inb/outb are quite useless in making BIOS calls. BIOS calls? Y'know, I once argued for a vm86intr() (or whatever it is called) on FICL, in case applications needed it. As for setting registers ti specific values... huh? Why does this matter? Can you explain exactly what your code does and how? I'd much prefer this could be done from a .4th file, as this is something ports and third-parties might like to do. > > Either way, no changes to /boot/loader.rc would be required. > > > This looks much better, I didn't know we could tell the loader to execute a > script in loader.conf. I try to keep it a secret. :-) While the exec="" stuff allows for arbitrary code execution (as do _after, _before and _error), this sort of thing is best avoided if possible on a configuration file. This particular case, though, is precisely the kind of exception to the rule I had in mind. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Sat, 10 Jun 2000, Volodymyr Kostyrko wrote: > On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: > >It's an issue. Nice values count for less than before due to fixes > > that Luoqi Chen made (and I committed). The behavior now isn't optimal, > > but it is better than the system locking up. NICE_WEIGHT might be okay > > to keep at 2. Try the attached diff; I'm pretty sure it won't blow > > things up :) > >The diff should make a process at -20 which uses all available CPU > > schedule just slightly the ahead of a process at +20 which uses no CPU. > > A process which uses full CPU at 0 niceness would have a priority of > > 128, whereas a process using no CPU at 0 niceness would have a priority > > of 90. All processes will always have a priority less than or equal to > > 128, which is the priority at which a process with a niceness of +20 > > always runs at. A +20 process won't get better priority than anything > > else, period. Try it out, see how it works for you:) > > I think this is not the clear solution for descibed problem 'couse the dnetc >client still gets a priority and still have the share of time while other programs >might run. For me idprio works great. Just change last string in the starting shell >scipt. There is no clear solution at all... try it out. Of _course_ it still gets a share of the time. If it didn't, then it could deadlock the system (like idprio and rtprio both can). > idprio 31 su nobody -c "$dir/dnetc -quiet" 2>/dev/null >/dev/null & > > -- > [WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net] -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Sat, Jun 10, 2000 at 10:56:00AM +0300, Volodymyr Kostyrko wrote: > > I think this is not the clear solution for descibed problem 'couse the > dnetc client still gets a priority and still have the share of time while > other programs might run. For me idprio works great. Just change last > string in the starting shell scipt. > > idprio 31 su nobody -c "$dir/dnetc -quiet" 2>/dev/null >/dev/null & I had no idea this wonderful little utility existed. It's a godsend! Thanks. -jake -- Jacob A. Hart <[EMAIL PROTECTED]> Powered by: FreeBSD 5.0-CURRENT #17: Fri Jun 9 21:58:34 EST 2000 "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Kris Kennaway wrote: > > > Bad example. Not _all_ filenames but temp. ones only which allows to run > > FreeBSD binary in MSDOS FS with MSDOS files. > > The point is the same. Files created by FreeBSD binaries during the course > of operation don't conform to an 8.3 monocase naming scheme (think of > dotfiles for example). I don't believe there's such a thing as a lowest > common denominator of file system naming conventions - either a filesystem > can support UFS names (perhaps through a translation later) or it's not > suitable for running FreeBSD from. With this line of reasoning, why don't you go all the way and add control characters and stuff? They are allowed by ufs, and shell even grok them. In fact, commands such as ls even have flags to deal with them. Kris, IT IS THE APPLICATION THAT DICTATE YOUR NEEDS. The reasoning above would more likely get FreeBSD to be discarded than the FS. If the OS won't bend to the users' need, it will get dumped, period. As we position FreeBSD as a server system, the need to support foreign filesystems WELL increases. FIOFO (with all due respect :). > > mktemp() makes temp files in any directory including current one. > > Yes, but in practice it's not used that way since you can't write to most > directories on the system except ~ and /tmp and relatives. Tell that to vim. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Kris Kennaway wrote: > > Instead of using only alphabetic characters, the patch uses the following > character set: > > 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ > > which is not believed to cause any problems with shells. The PID is also Huh? # does not cause problems? : does not cause problems? Mind you, shells don't have problems with any character at all in a filename if they are properly written, but if you are expecting the filenames generated by mktemp() to be handled by shell, they ought to pass the IFS=':'; for file in $filelist test. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Strange rpc.statd and mount_nfs
As was pointed out, rcp.statd is supposed to have a large VSZ, but
mount_nfs should not and my swap was getting used up.
mount_nfs will do an RPC clntudp_create for every attempt, but
only a clnt_destroy after a success.
Here is a rather suspicious fix, I have not looked at rpc call
use in detail:
--- mount_nfs.c.origSat Jun 10 11:08:19 2000
+++ mount_nfs.c Sat Jun 10 11:09:06 2000
@@ -784,10 +784,11 @@
warnx("%s", clnt_sperror(clp,
"bad MNT RPC"));
} else {
- auth_destroy(clp->cl_auth);
- clnt_destroy(clp);
retrycnt = 0;
}
+ auth_destroy(clp->cl_auth);
+ clnt_destroy(clp);
+ so = RPC_ANYSOCK;
}
}
if (--retrycnt > 0) {
On 08-Jun-00 Jonathan Hanna wrote:
>
> I am running a fairly recent current and noticed my swap seemed
> a little overused.
>
> bash-2.02$ uname -a
> FreeBSD roller.pangolin-systems.com 5.0-CURRENT FreeBSD 5.0-CURRENT #41: Sun May 14
>11:50:20 PDT 2000 [EMAIL PROTECTED]
sy
> stems.com:/home/src/sys/compile/ROLLER i386
> bash-2.02$ uptime
> 11:27PM up 3 days, 5:15, 7 users, load averages: 0.21, 0.17, 0.14
>
> ps shows:
...
> 0 212 1 29 2 0 2630360 select IWs ??0:00.00 rpc.stat
This is expected.
> This looks big.
> 0 1382 1 0 2 0 3716 352 select I ??0:01.02 xterm -geometry
>80x25 -fg springgree
...
> 1000 1504 1 0 10 0 86368 408 nanslp Is??0:07.93 nfs -o bg -o
>noauto ghost-p1:/home/j
>
> This seems rather large as well.
Not expected.
...
> I do remember an nfs mount failing and perhaps being backgrounded.
This was it, in normal circumstances the problem would not show up.
I guess I shouldn't be leaving failing mounts around!
Jonathan Hanna <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tcsh history and month bugfix: tc.prompt.c v3.38
This has been applied.
+ Kim
| From:"Andrey A. Chernov" <[EMAIL PROTECTED]>
| Date:Fri, 21 Apr 2000 08:36:12 +0400
|
| --- tc.prompt.c.bak Thu Apr 20 11:47:23 2000
| +++ tc.prompt.c Fri Apr 21 08:31:17 2000
| @@ -222,7 +222,7 @@
| fmthist('R', info, (char *) (cz = cbuff), sizeof(cbuff));
| else
| cz = (unsigned char *) str;
| - if (str != NULL)
| + if (cz != NULL)
| for (; *cz; *p++ = attributes | *cz++)
| if (p >= ep) break;
| break;
| @@ -477,7 +477,7 @@
| case 'w':
| if (p >= ep - 5) break;
| for (cz = (unsigned char *) month_list[t->tm_mon]; *cz;
| - *p++ = attributes | *cz++);
| + *p++ = attributes | *cz++)
| if (p >= ep) break;
| break;
| case 'W':
| --
| Andrey A. Chernov
| <[EMAIL PROTECTED]>
| http://nagual.pp.ru/~ache/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Boot Manager
On Fri, 9 Jun 2000, John Hengstler wrote: > Greetings, > > What is the quick way to restore the boot manager (dual os). Lost it when I > reloaded Win98. man boot0cfg Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Jail panics on current
Hi ..
if i try to run /etc/rc of my jail with the following:
/usr/sbin/jail /extra/panic panic 192.168.10.7 /bin/sh /etc/rc
i get an panic on:
FreeBSD du.1st.dudi.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jun 9
19:02:27 CEST 2000
[EMAIL PROTECTED]:/usr/src2/sys/compile/1st.dummynet i386
snap of gdb -k :
(23:24:16):root:1st.debug# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.3
(kgdb) core-file /var/crash/vmcore.3
IdlePTD 3153920
initial pcb at 284fc0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01705b5
stack pointer = 0x10:0xca35dee8
frame pointer = 0x10:0xca35def4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 33996 (inetd)
interrupt mask = none
panic: from debugger
panic: from debugger
Uptime: 14m45s
dumping to dev #ad/0x20011, offset 262144
dump ata1: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01522c9 in panic (fmt=0xc0236bd4 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc0128f7d in db_panic (addr=-1072233035, have_addr=0, count=-1,
modif=0xca35dd54 "") at ../../ddb/db_command.c:433
#3 0xc0128f1b in db_command (last_cmdp=0xc0266b5c, cmd_table=0xc02669bc,
aux_cmd_tablep=0xc0280f48) at ../../ddb/db_command.c:333
#4 0xc0128fe2 in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc012b247 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc020e0da in kdb_trap (type=12, code=0, regs=0xca35dea8)
at ../../i386/i386/db_interface.c:158
#7 0xc021a634 in trap_fatal (frame=0xca35dea8, eva=4)
at ../../i386/i386/trap.c:922
#8 0xc021a2fd in trap_pfault (frame=0xca35dea8, usermode=0, eva=4)
at ../../i386/i386/trap.c:820
#9 0xc0219eaf in trap (frame={tf_fs = -1072431088, tf_es = 16,
tf_ds = -912982000, tf_edi = 2, tf_esi = 0, tf_ebp = -902439180,
tf_isp = -902439212, tf_ebx = 0, tf_edx = -902439128, tf_ecx = 0,
tf_eax = -912942112, tf_trapno = 12, tf_err = 0, tf_eip =
-1072233035,
tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = -902439040})
at ../../i386/i386/trap.c:426
#10 0xc01705b5 in socreate (dom=28, aso=0xca35df20, type=2, proto=0,
p=0xc9959be0) at ../../kern/uipc_socket.c:138
---Type to continue, or q to quit---
#11 0xc0173c79 in socket (p=0xc9959be0, uap=0xca35df80)
at ../../kern/uipc_syscalls.c:119
#12 0xc021a931 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077939036, tf_esi = -1077938908, tf_ebp = -1077939004,
tf_isp = -902438956, tf_ebx = 269511812, tf_edx = -1077938908,
tf_ecx = 269503024, tf_eax = 97, tf_trapno = 12, tf_err = 2,
tf_eip = 269225128, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077939080,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#13 0xc020ea15 in Xint0x80_syscall ()
#14 0x100b0f1a in ?? ()
#15 0x8049cab in ?? ()
#16 0x8049aa1 in ?? ()
(kgdb)
Hope this helps .. if i can be of any assistance let me know.
Grtx,
Bart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Fri, 9 Jun 2000, Andrey A. Chernov wrote: > On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote: > > > would be the way to go: 64^6 = 2^36 possibilities which is nice... > > > > 1) Just totally opposite: mixing random with non-random sources you'll get > > into collision much faster then with random source only. 2) Yet, of course, > > the code handles collisions. > > Part 2) need to be clarified too. The code _attempt_ to handle collision, > but collision race can occurse between two processes checking for collision, > so getpid() insertion prevents this. I am not against of removing > getpid() code totally, just against of "randomization" of it, suggested in > the patch, which increase collision chance. The patch doesn't do this -at present it only XORs getpid() with a single random bit which is untouched by getpid() (since PIDs will only be less than 9). Obviously, overwriting bits which are actually returned from getpid() would be stupid since it turns them totally random and thereby invalidates their use for collision protection. Given the other replies in this thread I think I'll just remove the PID stuff altogether and make the temp filename only constructed from alphanumeric character. The price is that there's a chance of collision between two programs who mktemp() and come up with the same random filename, which is a theoretical security risk (at present only something with the same PID can come up with a colliding tempfile name) but the probability is altogether pretty small. I'll do some calculations to estimate the exact level of risk here. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, 10 Jun 2000, Kris Kennaway wrote: > Given the other replies in this thread I think I'll just remove the PID > stuff altogether and make the temp filename only constructed from > alphanumeric character. The price is that there's a chance of collision > between two programs who mktemp() and come up with the same random > filename, which is a theoretical security risk (at present only something > with the same PID can come up with a colliding tempfile name) but the > probability is altogether pretty small. I'll do some calculations to > estimate the exact level of risk here. Actually, it's not of course a security risk in the new algorithm (this is mktemp() after all), but it's a potential failure mode which can cause applications to fail in ways they otherwise wouldn't (with some very low probability) on a normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Kris Kennaway wrote: > > On Sat, 10 Jun 2000, Kris Kennaway wrote: > > > Given the other replies in this thread I think I'll just remove the PID > > stuff altogether and make the temp filename only constructed from > > alphanumeric character. The price is that there's a chance of collision > > between two programs who mktemp() and come up with the same random > > filename, which is a theoretical security risk (at present only something > > with the same PID can come up with a colliding tempfile name) but the > > probability is altogether pretty small. I'll do some calculations to > > estimate the exact level of risk here. > > Actually, it's not of course a security risk in the new algorithm (this is > mktemp() after all), but it's a potential failure mode which can cause > applications to fail in ways they otherwise wouldn't (with some very low > probability) on a normal system. But, I don't think it's a big enough > problem to worry about (numbers still coming :-) It's not a new situation, any application that can write to /tmp can create files that collide with other program's use of mktemp(). Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_\_| \ _|/' \/ (_)>(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote: > > Actually, it's not of course a security risk in the new algorithm (this is > > mktemp() after all), but it's a potential failure mode which can cause > > applications to fail in ways they otherwise wouldn't (with some very low > > probability) on a normal system. But, I don't think it's a big enough > > problem to worry about (numbers still coming :-) > > It's not a new situation, any application that can write to /tmp can > create files that collide with other program's use of mktemp(). Not under the current mktemp() since the PID is unique (except for wraparounds) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Kris Kennaway wrote: > > On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote: > > > > Actually, it's not of course a security risk in the new algorithm (this is > > > mktemp() after all), but it's a potential failure mode which can cause > > > applications to fail in ways they otherwise wouldn't (with some very low > > > probability) on a normal system. But, I don't think it's a big enough > > > problem to worry about (numbers still coming :-) > > > > It's not a new situation, any application that can write to /tmp can > > create files that collide with other program's use of mktemp(). > > Not under the current mktemp() since the PID is unique (except for > wraparounds) mktemp() is not the only function that creates files in /tmp. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_\_| \ _|/' \/ (_)>(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.x buildworlds broken on -current
Recent compiler changes seem to have broken the ability to do 4.x buildworlds under -current - I've tested this on beast.freebsd.org and my own machines and got the same result. The build dies during the compiler phase with lots of stuff like: /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `finish_function': c-decl.o(.text+0x8360): multiple definition of `finish_function' decl.o(.text+0x10880): first defined here /usr/libexec/elf/ld: Warning: size of symbol `finish_function' changed from 3003 to 565 in c-decl.o /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `implicitly_declare': c-decl.o(.text+0x2a81): undefined reference to `maybe_objc_check_decl' /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `finish_decl': c-decl.o(.text+0x4b1c): undefined reference to `maybe_objc_check_decl' c-decl.o(.text+0x4b51): undefined reference to `maybe_objc_check_decl' c-decl.o(.text+0x4bce): undefined reference to `maybe_objc_check_decl' /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `grokfield': c-decl.o(.text+0x6a92): undefined reference to `maybe_objc_check_decl' /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o)(.text+0x7077): more undefined references to `maybe_objc_check_decl' follow *** Error code 1 1 error On a related note, are there any freebsd.org machines which are still 4.x which can be used for buildworld testing? I used to use beast, but it's now 5.0 as well. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
> As for setting registers ti specific values... huh? Why does this > matter? Can you explain exactly what your code does and how? > VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
> > As for setting registers ti specific values... huh? Why does this > > matter? Can you explain exactly what your code does and how? > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > register is set to a magic value, otherwise it would be handled as any > other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. -- \\ 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] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
strange messages at bootup
I just came over from 4.0 yesterday, and now I get some odd messages that weren't there before. unknown0: at iomem 0-0x9fbff,0x9fc00-0x9,0xe-0xf,0x10-0x4fe,0x4ff-0x4ff7fff,0x4ff8000-0x4ff,0xfffc-0x on isa0 unknown: can't assign resources unknown1: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: at port 0x40-0x43 irq 0 on isa0 unknown3: at port 0x70-0x73 irq 8 on isa0 unknown: can't assign resources unknown4: at port 0x61 on isa0 npxisa0: at port 0xf0-0xff irq 13 on isa0 unknown: can't assign resources unknown5: at port 0xff00-0xff3f,0xff40-0xff4f on isa0 unknown6: on isa0 unknown7: at port 0xcf8-0xcff on isa0 unknown8: at port 0x3f8-0x3ff irq 4 on isa0 unknown9: on isa0 unknown: can't assign resources unknown: can't assign resources What are these? Are they possibly related to my mouse no longer working (it's not the "out of sync" problem)? How can I get rid of them? I think they are from the ppbus driver checking for attached devices, I'll put the entire dmesg here for context. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Sat Jun 10 16:09:51 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RJK191 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 167046041 Hz CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 83820544 (81856K bytes) avail memory = 78753792 (76908K bytes) Preloaded elf kernel "kernel" at 0xc02c. Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pci0: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 10 pci0: at 7.3 pci0: at 10.0 irq 11 pcm0: port 0xee80-0xeebf irq 10 at device 11.0 on pci0 pci0: (vendor=0x109e, dev=0x0350) at 18.0 irq 10 xl0: <3Com 3c900-TPO Etherlink XL> port 0xef00-0xef3f irq 11 at device 19.0 on pci0 xl0: Ethernet address: 00:60:97:6d:9c:d8 xl0: selecting 10baseT transceiver, half duplex fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> ppc0: This ppc chipset does not support the extended I/O port range...no problem ppc0: at port 0x378-0x37b irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: SCP,VLINK lpt0: on ppbus0 lpt0: Interrupt-driven port unknown0: at iomem 0-0x9fbff,0x9fc00-0x9,0xe-0xf,0x10-0x4fe,0x4ff-0x4ff7fff,0x4ff8000-0x4ff,0xfffc-0x on isa0 unknown: can't assign resources unknown1: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: at port 0x40-0x43 irq 0 on isa0 unknown3: at port 0x70-0x73 irq 8 on isa0 unknown: can't assign resources unknown4: at port 0x61 on isa0 npxisa0: at port 0xf0-0xff irq 13 on isa0 unknown: can't assign resources unknown5: at port 0xff00-0xff3f,0xff40-0xff4f on isa0 unknown6: on isa0 unknown7: at port 0xcf8-0xcff on isa0 unknown8: at port 0x3f8-0x3ff irq 4 on isa0 unknown9: on isa0 unknown: can't assign resources unknown: can't assign resources ad0: 6204MB [13446/15/63] at ata0-master using UDMA33 acd0: CDROM at ata1-master using PIO3 Mounting root from ufs:/dev/ad0s2a lpt0: switched to polled standard mode -- Ray Kohler <[EMAIL PROTECTED]> FreeBSD -- The Power to Serve The lion and the calf shall lie down together but the calf won't get much sleep. -- Woody Allen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, Jun 10, 2000 at 02:31:23PM -0700, Kris Kennaway wrote: > between two programs who mktemp() and come up with the same random > filename, which is a theoretical security risk (at present only something > with the same PID can come up with a colliding tempfile name) but the > probability is altogether pretty small. I'll do some calculations to > estimate the exact level of risk here. Please note that you turn never probavility into small one, and it is degradation. "never" is not completely never, of course, but if temp file stays until pids wrapped. -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote: > :1) Just totally opposite: mixing random with non-random sources you'll get > :into collision much faster then with random source only. 2) Yet, of course, > :the code handles collisions. > : > :-- > :Andrey A. Chernov > :<[EMAIL PROTECTED]> > > Think about it. If you mix a random number with a non-random number, > using xor, what you get is a random number. It's neither stronger > nor weaker. No, you'll get weaker random number, it badly affects random distribution. OR or AND will affect more. What you say is true only if second XOR part is 0 or -1 or changed between them or simple constant. I.e. if not _all_ bits XORed in the same way, it affects. -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote:
> Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
Only if predictable have the same bits number as random. If not all bits of
random XOR-ed (i.e. half of random), it becomes weaker.
BTW, if they have the same bits number,
there is no reason to XOR random with predictable, random is not become
more random.
--
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, Jun 10, 2000 at 09:13:30AM +0200, Mark Murray wrote: Well, I tend to agree that it is not weakens random, but I not see any improvement too. > That is a pretty fundamental theorem of Cryptography. My suggestion > _strengthens_ the random number. All you lose is one bit if it If it not weakers I can't see why it strenghthens. I.e. you can constantly strenghthens generator with passing it through XOR -1? If not, why any other value is better than -1? -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, Jun 10, 2000 at 07:43:06PM -0700, Andrey A. Chernov wrote:
> On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote:
> > Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
>
> Only if predictable have the same bits number as random. If not all bits of
> random XOR-ed (i.e. half of random), it becomes weaker.
Forget this, I change my mind here.
> BTW, if they have the same bits number,
> there is no reason to XOR random with predictable, random is not become
> more random.
But still confirm this.
--
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sat, Jun 10, 2000 at 07:36:10PM -0700, Andrey A. Chernov wrote: > On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote: > > :1) Just totally opposite: mixing random with non-random sources you'll get > > :into collision much faster then with random source only. 2) Yet, of course, > > :the code handles collisions. > > : > > :-- > > :Andrey A. Chernov > > :<[EMAIL PROTECTED]> > > > > Think about it. If you mix a random number with a non-random number, > > using xor, what you get is a random number. It's neither stronger > > nor weaker. > > No, you'll get weaker random number, it badly affects random distribution. Forget this, I change my mind. It is not weaker, but not strengtenth too. -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange messages at bootup
On Sat, Jun 10, 2000 at 09:24:28PM -0400, Ray Kohler wrote: > I just came over from 4.0 yesterday, and now I get some odd messages > that weren't there before. > > unknown0: at iomem >0-0x9fbff,0x9fc00-0x9,0xe-0xf,0x10-0x4fe,0x4ff-0x4ff7fff,0x4ff8000-0x4ff,0xfffc-0x > on isa0 I would hazard the guess that you now have the PNPBIOS directive in your kernel config file... > -- > Ray Kohler <[EMAIL PROTECTED]> > FreeBSD -- The Power to Serve > The lion and the calf shall lie down together but the calf won't get > much sleep. > -- Woody Allen > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange messages at bootup
On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote: > On Sat, Jun 10, 2000 at 09:24:28PM -0400, Ray Kohler wrote: > > I just came over from 4.0 yesterday, and now I get some odd messages > > that weren't there before. > > > > unknown0: at iomem >0-0x9fbff,0x9fc00-0x9,0xe-0xf,0x10-0x4fe,0x4ff-0x4ff7fff,0x4ff8000-0x4ff,0xfffc-0x > on isa0 > > I would hazard the guess that you now have the PNPBIOS directive > in your kernel config file... Actually, I don't have PnP in my config file. That's why I think this is so weird... -- Ray Kohler <[EMAIL PROTECTED]> FreeBSD -- The Power to Serve Speak softly and carry a +6 two-handed sword. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange messages at bootup
On Sun, Jun 11, 2000 at 12:30:45AM -0400, Ray Kohler wrote: > On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote: > > I would hazard the guess that you now have the PNPBIOS directive > > in your kernel config file... > > Actually, I don't have PnP in my config file. That's why I think > this is so weird... It's on by default now. -Chris -- [EMAIL PROTECTED] | yawn. [EMAIL PROTECTED]| Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange messages at bootup
On Sat, Jun 10, 2000 at 09:33:51PM -0700, Chris Piazza wrote: > On Sun, Jun 11, 2000 at 12:30:45AM -0400, Ray Kohler wrote: > > On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote: > > > I would hazard the guess that you now have the PNPBIOS directive > > > in your kernel config file... > > > > Actually, I don't have PnP in my config file. That's why I think > > this is so weird... > > It's on by default now. Can I turn it off somehow? Or otherwise fix it? -- Ray Kohler <[EMAIL PROTECTED]> FreeBSD -- The Power to Serve Pure drivel tends to drive ordinary drivel off the TV screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Strange rpc.statd and mount_nfs
:Here is a rather suspicious fix, I have not looked at rpc call
:use in detail:
:
:--- mount_nfs.c.origSat Jun 10 11:08:19 2000
:+++ mount_nfs.c Sat Jun 10 11:09:06 2000
:@@ -784,10 +784,11 @@
:warnx("%s", clnt_sperror(clp,
:"bad MNT RPC"));
:} else {
:- auth_destroy(clp->cl_auth);
:- clnt_destroy(clp);
:retrycnt = 0;
:}
:+ auth_destroy(clp->cl_auth);
:+ clnt_destroy(clp);
:+ so = RPC_ANYSOCK;
Good catch! This patch looks good to me, I am going to go ahead
and commit it.
Resetting 'so' is good code form, but I went through the rpc code
and it wasn't an operational bug ... the rpc code can overwrite so
in the case of a failure but only with '-1', which is RPC_ANYSOCK
anyway. Still, it's good not to make assumptions.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.x buildworlds broken on -current
On Sat, 10 Jun 2000, Kris Kennaway wrote: > Recent compiler changes seem to have broken the ability to do 4.x > buildworlds under -current - I've tested this on beast.freebsd.org and my > own machines and got the same result. The build dies during the compiler > phase with lots of stuff like: > > >/morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): > In > function `finish_function': > c-decl.o(.text+0x8360): multiple definition of `finish_function' > decl.o(.text+0x10880): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `finish_function' changed > from 3003 to 565 in c-decl.o > ... This is a bug in the cc Makefiles in 4.x. It was fixed in -current in: # RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_int/Makefile,v # Working file: Makefile # head: 1.26 # ... # # revision 1.26 # date: 2000/05/24 20:02:21; author: obrien; state: Exp; lines: +2 -2 # Move c-decl.c out of the common libcc_int.a into the binary Makefiles # where it is used. c-decl has symbols that conflict with several of the # cc1plus sources. # # GNU `ld' was changed in Dec 1999 to be more be compatable with the way that # other linkers work (specifically in the Solaris linker). The 2.9.1 `ld', # did the Wrong Thing in that if a library contained a common symbol that # matched a definition of that symbol in another (already linked in object) # it would also be linked in, even if there was no other reason to do so. # This is wrong. The library should only be linked in if it contains # non-common, non-weak symbols which are needed by previously linked in # objects. # etc. This could be fixed by MFC to RELENG_4, but bootstrapping from 4.0, 3.x and 2.x is much harder to fix. Building old kernels under -current is becoming difficult. I build kernels for RELENG_3 and RELENG_4. This causes a lot of new warnings about invalid assembler, but still works, at least a week ago. I left genassym(1) in /usr/bin to avoid breaking the build of RELENG_4 kernels until the genassym changes are MFC'ed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
