headers
Garance A Drosihn | 1 Aug 2004 03:37
Picon
Favicon

Random-ness when booting into single-user

When I was at the devsummit, a few developers remarked at the
annoying situation one can get into when booting into single-
user mode.  Something about various operations which can hang
because they need some random number(s), but at that point
/dev/random (or whatever the key thing is) has not been seeded
with enough entropy to give random numbers.  Apparently once
you get into this state, you have to start typing a lot of
random gibberish to get past the problem.  Something about
"dancing the fandango", if I remember right.

Happily I have not run into this, and I think I would like to
make sure that I don't run into it -- even though I obviously
don't remember any of the details...

I have been looking at sbin/init/init.c, and I was wondering
if it might be fairly easy to provide a fix to this situation.
Let's say you request single-user mode.  If you asked for
single-user mode, init.c is what will ask you which shell you
want use.

Once it knows the shell, couldn't it just do something like
first execute:
     ${SHELL} -c /etc/rc.d/preseedrandom
(and ignore any failures)

And *then* execute the standard
     ${SHELL}
for single-user mode?

Or maybe it would execute some other script to seed the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steve Kargl | 1 Aug 2004 03:47
Picon

Re: Random-ness when booting into single-user

On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote:
> 
> Happily I have not run into this, and I think I would like to
> make sure that I don't run into it -- even though I obviously
> don't remember any of the details...

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c

--

-- 
Steve
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Garance A Drosihn | 1 Aug 2004 04:02
Picon
Favicon

Re: Random-ness when booting into single-user

At 6:47 PM -0700 7/31/04, Steve Kargl wrote:
>On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote:
>>
>>  Happily I have not run into this, and I think I would like to
>>  make sure that I don't run into it -- even though I obviously
>>  don't remember any of the details...
>
>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c

Ah.  I see that says

    Start the entropy device insecure/unblocked. I'll be
    handing over responsibility for critical randomness
    requirements (like sshd)to rc.d/*

Has rc.d/* been changed to match?

Thanks for the pointer.

--

-- 
Garance Alistair Drosehn            =   gad <at> gilead.netel.rpi.edu
Senior Systems Programmer           or  gad <at> freebsd.org
Rensselaer Polytechnic Institute    or  drosih <at> rpi.edu
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Garance A Drosihn | 1 Aug 2004 04:27
Picon
Favicon

Re: Random-ness when booting into single-user

At 10:02 PM -0400 7/31/04, Garance A Drosihn wrote:
>At 6:47 PM -0700 7/31/04, Steve Kargl wrote:
>>On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote:
>>>
>>>  Happily I have not run into this, and I think I would like to
>>>  make sure that I don't run into it -- even though I obviously
>>>  don't remember any of the details...
>>
>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c

Which had the companion change at:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev_soft.c

This suggests another tactic.  randomdev_soft.c could go back to
having random.sys.seeded default to 0, and maybe init.c could
change it to 1 (if it is 0) before dropping into single-user mode,
and then change it back (if it had been 0) before coming up in
multi-user mode.  [assuming that can be done]

That way we wouldn't have to change anything in /etc/rc.d, and
we have something safer than my previous suggestion.

--

-- 
Garance Alistair Drosehn            =   gad <at> gilead.netel.rpi.edu
Senior Systems Programmer           or  gad <at> freebsd.org
Rensselaer Polytechnic Institute    or  drosih <at> rpi.edu
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Long | 1 Aug 2004 04:26
Picon
Favicon

Re: Random-ness when booting into single-user

Garance A Drosihn wrote:

> At 6:47 PM -0700 7/31/04, Steve Kargl wrote:
> 
>> On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote:
>>
>>>
>>>  Happily I have not run into this, and I think I would like to
>>>  make sure that I don't run into it -- even though I obviously
>>>  don't remember any of the details...
>>
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c
> 
> 
> Ah.  I see that says
> 
>    Start the entropy device insecure/unblocked. I'll be
>    handing over responsibility for critical randomness
>    requirements (like sshd)to rc.d/*
> 
> Has rc.d/* been changed to match?
> 
> Thanks for the pointer.
> 

I believe that Mark is still finishing this part of the work.  See the
5.3 TODO list for more details.

Scott
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Long | 1 Aug 2004 20:01

PCI-Express support

All,

I've emailed before about supporting various aspects of PCI-Express and 
especially MSI, but haven't really gotten too far with it due to lack of
resources.  I now how access to a system that can do PCI-Express (PCI-E)
so I'd like to revisit it and see what can be added for 5-STABLE.  There
are three general areas that need to be addressed in some form or another:

Enhanced Configuration Space:
PCI-E introduces an enhanced PCI Configuration space that allows for
each function to have 4096 bytes of space instead of just 256.  The
Intel Lindenhurst chipset exposes this space via a memory-mapped
window instead of the old slow type 1/2 ioport configuration methods.
It appears that if the northbridge supports the enhanced config space
then all PCI, PCI-X, and PCI-E devices will show up in it as well as
in the legacy space.

Proper support likely entails splitting up the pci host-bridge drivers
so that a given ACPI or legacy front-end can plug into a given enhanced
or legacy configuration layer.  This definitely is not going to happen
in time for 5.3, though.  A hack that could work for 5-STABLE would be
to provide pcie_[read|write]_config() methods that would compliment the
existing pci methods and be available for drivers that want to access
the >255 configuration addresses.  Devices are already showing up that
want to use these registers, btw.  The mechanics of doing this would
involve using pmap_mapdev() to map in the range that is specific to each
function, and then hang this information off of the pcicfg structure.
It's a bit hackish, yes, but it does seem to work in tests that a
colleague of mine has done.
(Continue reading)

Permalink | Reply | 13 comments |
headers
M. Warner Losh | 1 Aug 2004 20:41

Re: PCI-Express support

In message: <410D2FEA.5050504 <at> samsco.org>
            Scott Long <scottl <at> samsco.org> writes:
: In order to keep the API as consistent as possible between classic 
: interrupt sources and MSI sources, I'd like to add a new bus method:
: 
: int
: bus_reserve_resource(device_t, int *start, int *end, int *count, int flags);
: 
: start, end, and count would be passed is as the desired range and would
: map to the per-function interrupt index in MSI.  On return, the range
: supported and negotiated by the OS, bus, and function would be filled
: into these values.  flags would be something like SYS_RES_MESSAGE.
: Internal failure of the function would be given in the return value.
: Whether failure to support MSI should be given as an error code return
: value can be debated.  This function will also program the MSI
: configuration registers on the device to use the correct message cookie
: and number of messages.

How is this different than bus_alloc_resource and adding
SYS_RES_MESSAGE to the list of resources?  You can get the same
information using bus_alloc_resource w/o the RF_ACTIVE flag.
bus_alloc_resource also has two args, one for the type, and another
for the flags (which is a different type).  start/end should be u_long
to match newbus' other use of this stuff (actually, they should be a
typedef, but that's a bigger change).

You then would just trap the SYS_RES_MESSAGE at the right places to
configure things.  In this case, the right places would be the pci
bridge code.  There would be no need to have separate drivers for
PCI-Express for the short term, since you could easily flag things as
(Continue reading)

Permalink | Reply | 3 comments |
headers
M. Warner Losh | 1 Aug 2004 20:44

Re: PCI-Express support

[[ replying to different aspects of this in different threads ]]

In message: <410D2FEA.5050504 <at> samsco.org>
            Scott Long <scottl <at> samsco.org> writes:
: Adding this for 5.3 is feasible, I think, and doesn't add a whole lot
: of risk.  PCI-E provides a legacy mde for interrupts that simulates
: PCI interrupt lines, so drivers can choose whether to use MSI or the
: legacy interrupt methods.

Code freeze is in 2 weeks.  I don't think it reasonable to have things
cooked enough by then to add this.  We've got enough going into 5.3
already, and these changes will be at the heart of the pci system,
which is a very big risk if it is done slightly badly.  Given the
large number of systems out there, I'd imagine that we'll have lots of
problems with this.  Smaller risk changes that Matt Dodd and I have
made over the years have resulted in big trouble.

I'd recommend that we give it a pass for 5.3.

Warner
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
M. Warner Losh | 1 Aug 2004 20:54

Re: PCI-Express support

In message: <410D2FEA.5050504 <at> samsco.org>
            Scott Long <scottl <at> samsco.org> writes:
: Proper support likely entails splitting up the pci host-bridge drivers
: so that a given ACPI or legacy front-end can plug into a given enhanced
: or legacy configuration layer.  This definitely is not going to happen
: in time for 5.3, though.  A hack that could work for 5-STABLE would be
: to provide pcie_[read|write]_config() methods that would compliment the
: existing pci methods and be available for drivers that want to access
: the >255 configuration addresses.  Devices are already showing up that
: want to use these registers, btw.  The mechanics of doing this would
: involve using pmap_mapdev() to map in the range that is specific to each
: function, and then hang this information off of the pcicfg structure.
: It's a bit hackish, yes, but it does seem to work in tests that a
: colleague of mine has done.

Why not just have the bridge do a bus_alloc_resource for those things?
That would cause the pmap_mamdev() to happen behind the scenes.  We
already do a number of things like this in the CardBus driver, but on
a smaller scale.

But is there really a reason we need pcie_*_config routines?  wouldn't
the pcib_* routines do the same job nicely?  They are already
virtualized so that we can plug in the pcie bridge functionality to
the existing bridge drivers if there is a pcie structure allocated to
the pcicfg.  Why invent an interface that we know we're going to
deprecate in short order when the existing interface can be used.

In the pci_pci.c code, we could add a couple of ifs in
pcib_{read,write}_config if the bridge supports it, for example.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Poul-Henning Kamp | 1 Aug 2004 22:16
Picon
Favicon

Re: PCI-Express support

In message <410D2FEA.5050504 <at> samsco.org>, Scott Long writes:
>All,
>
>I've emailed before about supporting various aspects of PCI-Express and 
>especially MSI, but haven't really gotten too far with it due to lack of
>resources.  I now how access to a system that can do PCI-Express (PCI-E)
>so I'd like to revisit it and see what can be added for 5-STABLE.  There
>are three general areas that need to be addressed in some form or another:
>
[...]
>
>Adding this for 5.3 is feasible, I think, and doesn't add a whole lot
>of risk.

OK, who are you and what have you done to Scott Long ?

Scott would never even think about suggesting something like this two
weeks before we lock down the tree for a -stable branching.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 4 comments |

Gmane