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:
>
: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,
:
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...
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
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
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
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,
>
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
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
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 bi
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
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 a
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 p
> > 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 por
> 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
T
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
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 (
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
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
> > b
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
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 f
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
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 m
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
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 deta
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
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
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
> st
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 th
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 c
> 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
>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-perso
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
> > 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'l
> > 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
35 matches
Mail list logo
