Boot Loader

Boot Loader

[Erik Christiansen]

G'day,

   Having proved the gnu powerpc-linux toolchain by building and
running a simple program on our custom ppc850SAR board, the next step
seems to be a boot loader.

   Had a look at http://sourceforge.net/projects/u-boot , as recently
mentioned by Jerry Van Baren, but the site states "This Project Has Not
Released Any Files", and the cvs repository link states "Only project
developers can access the CVS tree via this method."

   So, instead, I've downloaded ppcboot-2.0.0., which seems to be the
maiden name of u-boot, anyway.

   Until the U-Boot surfaces, would this be a good way to go, when faced
with a custom board?

Regards,
Erik


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Boot Loader

[Wolfgang Denk]

In message <20021209060509.GA5743@dd.nec.com.au> you wrote:
>
>    Had a look at http://sourceforge.net/projects/u-boot , as recently
> mentioned by Jerry Van Baren, but the site states "This Project Has Not
> Released Any Files", and the cvs repository link states "Only project
> developers can access the CVS tree via this method."

It is correct that we haven't released an official version of  U-Boot
yet, but as you can see from the project page it is based on PPCBoot,
which has been around for _some_ time.

And of course the CVS repository  _is_  available  to  everybody  for
anonymous CVS access. The page you quote is pretty clear:

	Anonymous CVS Access

        This project's SourceForge.net CVS repository can be checked
        out through anonymous (pserver) CVS with the following
        instruction set. The module you wish to check out must be
        specified as the modulename. When prompted for a password for
        anonymous, simply press the Enter key.

	cvs -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot login

	 cvs -z3 -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot co modulename

         Updates from within the module's directory do not need the
	-d parameter.

Developer access is indeed for developers only.

>    Until the U-Boot surfaces, would this be a good way to go, when faced
> with a custom board?

No.  You  should  not  spend  time  on  a  project  which  has   been
discontinued. Just download the latest (top of tree) version from the
U-Boot CVS server.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Ernest asks Frank how long he has been working for the company.
        "Ever since they threatened to fire me."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[U-Boot-Users] Re: Boot Loader

[Marius Groeger]

On Mon, 9 Dec 2002, Wolfgang Denk wrote:

> >    Until the U-Boot surfaces, would this be a good way to go, when faced
> > with a custom board?
>
> No.  You  should  not  spend  time  on  a  project  which  has   been
> discontinued. Just download the latest (top of tree) version from the
> U-Boot CVS server.

Please note that not everyone can access SF's Anon-CVS because of
their corporate firewalls. Are the nightly CVS snapshots available to
everyone?

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger at sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

[U-Boot-Users] Re: Boot Loader

[Wolfgang Denk]

In message <Pine.LNX.4.40.0212091023490.1617-100000@mag.devdep.sysgo.de> you wrote:
>
> > No.  You  should  not  spend  time  on  a  project  which  has   been
> > discontinued. Just download the latest (top of tree) version from the
> > U-Boot CVS server.
> 
> Please note that not everyone can access SF's Anon-CVS because of
> their corporate firewalls. Are the nightly CVS snapshots available to
> everyone?

Yes, they are.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Voodoo Programming: Things programmers do that  they  know  shouldn't
work  but they try anyway, and which sometimes actually work, such as
recompiling everything.                             - Karl Lehenbauer

Re: Boot Loader

[Erik Christiansen]

On Mon, Dec 09, 2002 at 08:43:47AM +0100, Wolfgang Denk wrote:
>
> No.  You  should  not  spend  time  on  a  project  which  has   been
> discontinued. Just download the latest (top of tree) version from the
> U-Boot CVS server.

Wolfgang,

   Thank you for setting me straight.

   Reading the "U-Boot Porting Guide", it looks like time to order in
plenty of pizza.

Regards,
Erik


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

boot loader

[Thiago Farina]

Hi,

Does the kernel include a simple boot loader like FreeBSD does?

-- 
Thiago Farina

Re: boot loader

[Richard Weinberger]

On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Hi,
>
> Does the kernel include a simple boot loader like FreeBSD does?

Why don't you figure yourself?

-- 
Thanks,
//richard

Re: boot loader

[Thiago Farina]

On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina <tfransosi@gmail.com> wrote:
>> Hi,
>>
>> Does the kernel include a simple boot loader like FreeBSD does?
>
> Why don't you figure yourself?
>
I think it doesn't. I just wanted someone to confirm my thought.

-- 
Thiago Farina

Re: boot loader

[Ken Moffat]

On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote:
> On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> > On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> >> Hi,
> >>
> >> Does the kernel include a simple boot loader like FreeBSD does?
> >
> > Why don't you figure yourself?
> >
> I think it doesn't. I just wanted someone to confirm my thought.
> 
Does the FreeBSD kernel really include a boot loader ?  Surely the
loader is what reads the kernel into memory and then hands control
to it.

If you look at FreeBSD as a whole, it has a boot loader for
whichever architecture it was built for.  But linux is only the
kernel - different distros (in this context, android could be
regarded as a distro) and most importantly different
architectures or platforms all do different things - in my
fairly-limited experience I've used grub, lilo, uboot, yaboot -
there are many others.

But please remember that asking general questions not related to
kernel development on this list is generally regarded as off-topic.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.

Re: boot loader

[Geert Uytterhoeven]

On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Does the kernel include a simple boot loader like FreeBSD does?

No idea what FreeBSD does, but you can use the kernel as a boot loader
for something else with kexec.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: boot loader

[Pavel Machek]

On Tue 2015-04-28 12:12:26, Thiago Farina wrote:
> Hi,
> 
> Does the kernel include a simple boot loader like FreeBSD does?

Long time ago, Linux included ability to boot from floppy on PC. Not
any more, IIRC.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: boot loader

[Thiago Farina]

Hi Pavel,

On Mon, May 11, 2015 at 7:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2015-04-28 12:12:26, Thiago Farina wrote:
>> Hi,
>>
>> Does the kernel include a simple boot loader like FreeBSD does?
>
> Long time ago, Linux included ability to boot from floppy on PC. Not
> any more, IIRC.
Yeah. Maybe it was a right decision from Linus to isolate, focus and work
solely on kernel and not including everything else (like FreeBSD does)
that makes a usable system.

Regards,

-- 
Thiago Farina

Re: boot loader

[Enrico Weigelt, metux IT consult]

Am 12.05.2015 um 02:17 schrieb Thiago Farina:

> Yeah. Maybe it was a right decision from Linus to isolate, focus and work
> solely on kernel and not including everything else (like FreeBSD does)
> that makes a usable system.

Just a little sidenote:

Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting
opportunities (eg. using various services like filesystems, shells, etc
in the bootloader).

With modern bootloaders like Barebox, the need for that IMHO isn't
that huge anymore. OTOH, there're still several things, I'd wish to
have available in the bootloader (eg. iscsi- or bnlkdev support).

Anyone here, who uses a Linux kernel as bootloader / preboot
environment ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: boot loader

[Pavel Machek]

On Tue 2015-05-12 13:11:26, Enrico Weigelt, metux IT consult wrote:
> Am 12.05.2015 um 02:17 schrieb Thiago Farina:
> 
> >Yeah. Maybe it was a right decision from Linus to isolate, focus and work
> >solely on kernel and not including everything else (like FreeBSD does)
> >that makes a usable system.
> 
> Just a little sidenote:
> 
> Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting
> opportunities (eg. using various services like filesystems, shells, etc
> in the bootloader).
> 
> With modern bootloaders like Barebox, the need for that IMHO isn't
> that huge anymore. OTOH, there're still several things, I'd wish to
> have available in the bootloader (eg. iscsi- or bnlkdev support).
> 
> Anyone here, who uses a Linux kernel as bootloader / preboot
> environment ?

Yes. See kexec.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: boot loader

[Enrico Weigelt, metux IT consult]

Am 13.05.2015 um 09:02 schrieb Pavel Machek:

>> Anyone here, who uses a Linux kernel as bootloader / preboot
>> environment ?
>
> Yes. See kexec.

Can you tell us a bit more about your setup ?
Which platforms/archs are you on ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: boot loader

[Pavel Machek]

On Wed 2015-05-13 09:53:09, Enrico Weigelt, metux IT consult wrote:
> Am 13.05.2015 um 09:02 schrieb Pavel Machek:
> 
> >>Anyone here, who uses a Linux kernel as bootloader / preboot
> >>environment ?
> >
> >Yes. See kexec.
> 
> Can you tell us a bit more about your setup ?
> Which platforms/archs are you on ?

It was very useful on sharp zaurus.
										Pavel
										
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: Executable delay

[James Bates]

Hi All,

I have had my first real poke around the kernel and it looks like I was
correct in saying that any task accessing the DOC drivers was put into an
incorrect state. The code that seemed to do the damage can be found in
drivers/mtd/devices/doc2000.c in the function _DoC_WaitReady().

The problem seems to be the call to cond_resched which is not in slightly
older kernel versions. To fix the bug I reverted this function back to the
code in version 2.4.10 of the kernel.

After making these changes it appears to work perfectly. My question now is.
Have I inadvertently broken something without knowing it.

Kind Regards,

James Bates

PS: My  _DoC_WaitReady is as follows:


/* DOC_WaitReady: Wait for RDY line to be asserted by the flash chip */
static int _DoC_WaitReady(struct DiskOnChip *doc)
{
	unsigned long docptr = doc->virtadr;
#ifndef CONFIG_MTD_DOCPROBE_SHORT_TIMEOUTS
	unsigned long timeo = jiffies + (HZ * 10);
#else
	unsigned long timeo = jiffies + 1;
#endif

	DEBUG(MTD_DEBUG_LEVEL3,
	      "_DoC_WaitReady called for out-of-line wait\n");

	/* Out-of-line routine to wait for chip response */
	while (!(ReadDOC(docptr, CDSNControl) & CDSN_CTRL_FR_B)) {
		if (time_after(jiffies, timeo)) {
			DEBUG(MTD_DEBUG_LEVEL2, "_DoC_WaitReady timed out.\n");
			return -EIO;
		}
// This is the "new" code from version 2.4.23
//		udelay(1);
//		cond_resched();
// Revert back to old task state management in 2.4.10
		if (current->need_resched) {
			set_current_state(TASK_UNINTERRUPTIBLE);
			schedule_timeout(1);
		}
		else
			udelay(1);
// End of 2.4.10 code
	}

	return 0;
}


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Boot Loader

[Kevin A. Sapp]

Hello,

For my end target I have to boot across a shared memory
interface by placing the executable into RAM.  This is
part of a multi processor system where the Linux board
is a cPCI slave.  The Linux board will not have a flash
or a network connection.  I is held in reset by the master
until the s/w is loaded and then released.  This is an 8275
target.  The "Master" is a Solaris Workstation or a PC
style Linux box or card.

Any suggestions on how to do this ?
Have to fill in my own board info in a bd_t struct,
pass it in R3, if I use and initrd it's start and end ptrs
go into R4, R5 and the cmd line params will
be hard coded and inserted into R6,R7...
I will be using a RAM disk for the root file system.

Instead of compressing and creating uImage for das u-boot,
I create a binary(?) image and just shove it into RAM at
0?  Ensure the Reset vec is set to my initialization code
that will be part of the download...

Any ideas would be appreciated.

Thank you
Kevin


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Boot Loader

[Wolfgang Denk]

Dear Kevin,

in message <3FE6DCB3.109@catapult.com> you wrote:
>
> For my end target I have to boot across a shared memory
> interface by placing the executable into RAM.  This is
> part of a multi processor system where the Linux board
> is a cPCI slave.  The Linux board will not have a flash
> or a network connection.  I is held in reset by the master
> until the s/w is loaded and then released.  This is an 8275

This has been done before. See for example the  "PN62"  configuration
in U-Boot.

> Any suggestions on how to do this ?

Use U-Boot...

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It all seemed, he thought, to be rather a lot of  trouble  to  go  to
just sharpen a razor blade.  - Terry Pratchett, _The Light Fantastic_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: boot loader

[Westerman, Mark]

Could you name the policy 
bootloader_t

This way we could include grub to

Mark

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tislabs.com]
> Sent: Monday, April 22, 2002 6:49 AM
> To: Russell Coker
> Cc: SE Linux
> Subject: Re: boot loader
> 
> 
> 
> On Sat, 20 Apr 2002, Russell Coker wrote:
> 
> > I am creating a policy for lilo.
> >
> > I have defined it's type as follows:
> > type lilo_t, domain, privlog, privmem, boot_loader;
> >
> > privmem is because lilo needs to read from /dev/mem to get 
> BIOS data about
> > boot devices.  I have defined "boot_loader" as a type 
> attribute for anything
> > that needs to write to raw hard drive devices to install a 
> boot loader (grub
> > etc would need that too).  Then I added boot_loader in 
> assert.te as being
> > allowed to write to fixed_disk_device_t.
> >
> > What do you think?
> 
> This sounds fine.  Once lilo has been moved into its own 
> domain, you might
> try removing direct access to fixed_disk_device_t from sysadm_t
> (the admin_domain macro).
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 
> 
> --
> You have received this message because you are subscribed to 
> the selinux list.
> If you no longer wish to subscribe, send mail to 
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

boot loader

[Russell Coker]

I am creating a policy for lilo.

I have defined it's type as follows:
type lilo_t, domain, privlog, privmem, boot_loader;

privmem is because lilo needs to read from /dev/mem to get BIOS data about 
boot devices.  I have defined "boot_loader" as a type attribute for anything 
that needs to write to raw hard drive devices to install a boot loader (grub 
etc would need that too).  Then I added boot_loader in assert.te as being 
allowed to write to fixed_disk_device_t.

What do you think?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Ivan Pulleyn]

I don't know how granular these policies can get (I'm just a lurker on
this list), but it would be cool if you could restrict boot_loader to
access only the first couple disk blocks where lilo writes to, and
privmem to only the less than 1MB region where BIOS values are.

Ivan...


On Sat, 20 Apr 2002, Russell Coker wrote:

> I am creating a policy for lilo.
> 
> I have defined it's type as follows:
> type lilo_t, domain, privlog, privmem, boot_loader;
> 
> privmem is because lilo needs to read from /dev/mem to get BIOS data about 
> boot devices.  I have defined "boot_loader" as a type attribute for anything 
> that needs to write to raw hard drive devices to install a boot loader (grub 
> etc would need that too).  Then I added boot_loader in assert.te as being 
> allowed to write to fixed_disk_device_t.
> 
> What do you think?
> 
> -- 
> If you send email to me or to a mailing list that I use which has >4 lines
> of legalistic junk at the end then you are specifically authorizing me to do
> whatever I wish with the message and all other messages from your domain, by
> posting the message you agree that your long legalistic sig is void.
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

On Sat, 20 Apr 2002 17:24, Ivan Pulleyn wrote:
> I don't know how granular these policies can get (I'm just a lurker on
> this list), but it would be cool if you could restrict boot_loader to
> access only the first couple disk blocks where lilo writes to, and
> privmem to only the less than 1MB region where BIOS values are.

They aren't that granular.

Probably the best way to achieve what you suggest would be to change the 
device drivers to have a separate device node for the first 512 bytes of the 
disk.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Stephen Smalley]

On Sat, 20 Apr 2002, Russell Coker wrote:

> I am creating a policy for lilo.
>
> I have defined it's type as follows:
> type lilo_t, domain, privlog, privmem, boot_loader;
>
> privmem is because lilo needs to read from /dev/mem to get BIOS data about
> boot devices.  I have defined "boot_loader" as a type attribute for anything
> that needs to write to raw hard drive devices to install a boot loader (grub
> etc would need that too).  Then I added boot_loader in assert.te as being
> allowed to write to fixed_disk_device_t.
>
> What do you think?

This sounds fine.  Once lilo has been moved into its own domain, you might
try removing direct access to fixed_disk_device_t from sysadm_t
(the admin_domain macro).

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Mon, 22 Apr 2002 13:48, Stephen Smalley wrote:
> On Sat, 20 Apr 2002, Russell Coker wrote:
> > I am creating a policy for lilo.
> >
> > I have defined it's type as follows:
> > type lilo_t, domain, privlog, privmem, boot_loader;
> >
> > privmem is because lilo needs to read from /dev/mem to get BIOS data
> > about boot devices.  I have defined "boot_loader" as a type attribute for
> > anything that needs to write to raw hard drive devices to install a boot
> > loader (grub etc would need that too).  Then I added boot_loader in
> > assert.te as being allowed to write to fixed_disk_device_t.
> >
> > What do you think?
>
> This sounds fine.  Once lilo has been moved into its own domain, you might
> try removing direct access to fixed_disk_device_t from sysadm_t
> (the admin_domain macro).

Removing the direct access sounds like a good idea.

Also I like Mark's suggestion, which means there's no need for boot_loader.

I've attached my new te file, and following is the lilo file_contexts entries:
/etc/lilo.conf                  system_u:object_r:etc_bootloader_t
/sbin/lilo.*                    system_u:object_r:bootloader_exec_t

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

[-- Attachment #2: bootloader.te --]
[-- Type: text/plain, Size: 1685 bytes --]

#
# Author:  Russell Coker <russell@coker.com.au>
#

#################################
#
# Rules for the bootloader_t domain.
#
# bootloader_exec_t is the type of the bootloader executable.
#
type bootloader_t, domain, privlog, privmem;
type bootloader_exec_t, file_type, sysadmfile, exec_type;
type bootloader_tmp_t, file_type, sysadmfile, tmpfile;
type etc_bootloader_t, file_type, sysadmfile;

role sysadm_r types bootloader_t;
role system_r types bootloader_t;

domain_auto_trans(sysadm_t, bootloader_exec_t, bootloader_t)

file_type_auto_trans(bootloader_t, tmp_t, bootloader_tmp_t)

allow bootloader_t { etc_t }:dir r_dir_perms;
uses_shlib(bootloader_t)

allow bootloader_t { fixed_disk_device_t removable_device_t }:blk_file rw_file_perms;
allow bootloader_t etc_bootloader_t:file r_file_perms;

can_exec(bootloader_t, { bootloader_exec_t bin_t })
allow bootloader_t { bin_t sbin_t }:dir r_dir_perms;
auditdeny bootloader_t sysadm_home_t:dir ~r_dir_perms;

allow bootloader_t boot_t:dir rw_dir_perms;
allow bootloader_t boot_t:{ file lnk_file } create_file_perms;

allow bootloader_t self:capability { sys_rawio sys_admin };
# allow bootloader to get attributes of any device node
allow bootloader_t { devfs_t file_type }:dir_file_class_set getattr;
auditdeny bootloader_t devpts_t:dir ~create_dir_perms;

allow bootloader_t self:process { fork sigchld };

allow bootloader_t fs_t:filesystem getattr;

allow bootloader_t proc_t:dir r_dir_perms;
allow bootloader_t proc_t:file r_file_perms;
allow bootloader_t etc_runtime_t:file r_file_perms;

allow bootloader_t devtty_t:chr_file rw_file_perms;

# for reading BIOS data
allow bootloader_t memory_device_t:chr_file r_file_perms;

Re: boot loader

[Stephen Smalley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 598 bytes --]


On Mon, 22 Apr 2002, Russell Coker wrote:

> I've attached my new te file, and following is the lilo file_contexts entries:
> /etc/lilo.conf                  system_u:object_r:etc_bootloader_t
> /sbin/lilo.*                    system_u:object_r:bootloader_exec_t

Thanks.  I had to add a few permissions (search access to /dev, use
descriptors created by newrole, write to the administrator's terminal) to
bootloader.te.  The first attached patch shows the changes.  The second
attached patch shows the changes to assert.te and admin_macros.te.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com



[-- Attachment #2: Type: TEXT/PLAIN, Size: 890 bytes --]

--- bootloader.te.old	Mon Apr 22 16:32:37 2002
+++ bootloader.te	Mon Apr 22 16:25:59 2002
@@ -17,10 +17,11 @@
 role system_r types bootloader_t;
 
 domain_auto_trans(sysadm_t, bootloader_exec_t, bootloader_t)
+allow bootloader_t newrole_t:fd use;
 
 file_type_auto_trans(bootloader_t, tmp_t, bootloader_tmp_t)
 
-allow bootloader_t { etc_t }:dir r_dir_perms;
+allow bootloader_t { etc_t device_t }:dir r_dir_perms;
 uses_shlib(bootloader_t)
 
 allow bootloader_t { fixed_disk_device_t removable_device_t }:blk_file rw_file_perms;
@@ -47,6 +48,8 @@
 allow bootloader_t etc_runtime_t:file r_file_perms;
 
 allow bootloader_t devtty_t:chr_file rw_file_perms;
+allow bootloader_t sysadm_tty_device_t:chr_file rw_file_perms;
+allow bootloader_t sysadm_devpts_t:chr_file rw_file_perms;
 
 # for reading BIOS data
 allow bootloader_t memory_device_t:chr_file r_file_perms;

[-- Attachment #3: Type: TEXT/PLAIN, Size: 1618 bytes --]

Index: policy/assert.te
===================================================================
RCS file: /cvs/lsm/selinux/policy/assert.te,v
retrieving revision 1.13
diff -u -r1.13 assert.te
--- policy/assert.te	2002/03/26 17:45:36	1.13
+++ policy/assert.te	2002/04/22 20:31:57
@@ -45,10 +45,9 @@
 neverallow ~admin { lib_t bin_t sbin_t }:file { write append unlink rename };
 
 #
-# Verify that only the administrator domain and the
-# file system administration domain have access to the raw disk devices.
+# Verify that only certain domains have access to the raw disk devices.
 #
-neverallow ~{ admin fsadm_t mount_t } fixed_disk_device_t:devfile_class_set { read write append };
+neverallow ~{ bootloader_t fsadm_t mount_t } fixed_disk_device_t:devfile_class_set { read write append };
 
 #
 # Verify that only the X server and klogd have access to memory devices.
Index: policy/macros/admin_macros.te
===================================================================
RCS file: /cvs/lsm/selinux/policy/macros/admin_macros.te,v
retrieving revision 1.5
diff -u -r1.5 admin_macros.te
--- policy/macros/admin_macros.te	2002/03/26 19:32:12	1.5
+++ policy/macros/admin_macros.te	2002/04/22 20:31:57
@@ -32,10 +32,6 @@
 allow $1_t sysadmfile:notdevfile_class_set create_file_perms;
 allow $1_t sysadmfile:dir create_dir_perms;
 
-# Use /sbin/lilo to update the boot loader.
-# XXX FIXME!  Move lilo into separate domain.
-allow $1_t fixed_disk_device_t:devfile_class_set rw_file_perms;
-
 # Access removable devices.
 allow $1_t removable_device_t:devfile_class_set rw_file_perms;
 

Re: boot loader

[Russell Coker]

On Mon, 22 Apr 2002 22:39, you wrote:
> On Mon, 22 Apr 2002, Russell Coker wrote:
> > I've attached my new te file, and following is the lilo file_contexts
> > entries: /etc/lilo.conf                 
> > system_u:object_r:etc_bootloader_t /sbin/lilo.*                   
> > system_u:object_r:bootloader_exec_t
>
> Thanks.  I had to add a few permissions (search access to /dev, use
> descriptors created by newrole, write to the administrator's terminal) to
> bootloader.te.  The first attached patch shows the changes.  The second
> attached patch shows the changes to assert.te and admin_macros.te.

Thanks.

Also I added devfs_t to the following line:
allow bootloader_t { etc_t device_t devfs_t }:dir r_dir_perms;


-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Stephen Smalley]

On Tue, 23 Apr 2002, Russell Coker wrote:

> Also I added devfs_t to the following line:
> allow bootloader_t { etc_t device_t devfs_t }:dir r_dir_perms;

There is one other potential issue.  If an administrator directly edits
/etc/lilo.conf, it will revert to etc_t (and become inaccessible to lilo
unless it is then relabeled by the administrator).  Is there any strong
reason to maintain a separate type on this file?  It is problematic to
keep it in a separate type from other /etc files, since it may be directly
modified by the administrator and it doesn't live in its own separate
subdirectory.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

On Tue, 23 Apr 2002 00:27, Stephen Smalley wrote:
> > Also I added devfs_t to the following line:
> > allow bootloader_t { etc_t device_t devfs_t }:dir r_dir_perms;
>
> There is one other potential issue.  If an administrator directly edits
> /etc/lilo.conf, it will revert to etc_t

Unless the administrator edits the file with vi (and not vim or at least not 
vim with the backup feature turned on).  If you use nvi or vim without 
backups then the same file will be used, hard links won't be broken, SIDs 
won't change, etc.

> (and become inaccessible to lilo
> unless it is then relabeled by the administrator).  Is there any strong
> reason to maintain a separate type on this file?  It is problematic to
> keep it in a separate type from other /etc files, since it may be directly
> modified by the administrator and it doesn't live in its own separate
> subdirectory.

/etc/lilo.conf will (on any properly configured system) contain a boot 
password for the system, which is the best way of taking over a system 
entirely without disassembling the hardware.  I think that this deserves a 
different type to world-readable files such as /etc/passwd!

I think that the situation is similar for other boot loaders.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Tom]

On Tue, Apr 23, 2002 at 12:45:03AM +0200, Russell Coker wrote:
> /etc/lilo.conf will (on any properly configured system) contain a boot 
> password for the system, which is the best way of taking over a system 
> entirely without disassembling the hardware.  I think that this deserves a 
> different type to world-readable files such as /etc/passwd!
> 
> I think that the situation is similar for other boot loaders.

Physical access to the hardware always means you have lost (an
encrypted filesystem being the exception). Moreover, a lot of properly
configured systems do NOT have a boot password. If they are located in
a physical secure location, then coming up again after a crash or power
failure is more important than the off-chance that someone breaks into
the hosting center just to reboot and take over your machine.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

On Tue, 23 Apr 2002 07:43, Tom wrote:
> On Tue, Apr 23, 2002 at 12:45:03AM +0200, Russell Coker wrote:
> > /etc/lilo.conf will (on any properly configured system) contain a boot
> > password for the system, which is the best way of taking over a system
> > entirely without disassembling the hardware.  I think that this deserves
> > a different type to world-readable files such as /etc/passwd!
> >
> > I think that the situation is similar for other boot loaders.
>
> Physical access to the hardware always means you have lost (an

Ability to disassemble the machine always means you have lost.  Ability to 
access the keyboard, mouse, and (non-bootable) floppy drive should not cause 
a problem.

Think of terminals in Internet Cafe's and University computer labs.

> encrypted filesystem being the exception).

An encrypted file system is not a magic bullet.  How does the machine with 
the encrypted file system get it's unlock password?

> Moreover, a lot of properly
> configured systems do NOT have a boot password. If they are located in
> a physical secure location, then coming up again after a crash or power
> failure is more important than the off-chance that someone breaks into
> the hosting center just to reboot and take over your machine.

Hosting centers that I am familiar with do not have enough security cameras, 
and the locks on cabinet doors are easily pickable.  Someone who has 
authorised access to one company's equipment (authorisation being arranged by 
unencrypted and unsigned email over a public network) can do whatever they 
like to other machines.

But that's beside the point.  The fact that some people choose to not use a 
particular security method does not mean that I will choose to not support it.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Tom]

On Tue, Apr 23, 2002 at 01:55:19PM +0200, Russell Coker wrote:
> > Physical access to the hardware always means you have lost (an
> 
> Ability to disassemble the machine always means you have lost.  Ability to 
> access the keyboard, mouse, and (non-bootable) floppy drive should not cause 
> a problem.
> 
> Think of terminals in Internet Cafe's and University computer labs.

But how does a boot-password offer any protection in these settings?


> > encrypted filesystem being the exception).
> 
> An encrypted file system is not a magic bullet.  How does the machine with 
> the encrypted file system get it's unlock password?

The same way that it gets the boot password. :)


> Hosting centers that I am familiar with do not have enough security cameras, 
> and the locks on cabinet doors are easily pickable.  Someone who has 
> authorised access to one company's equipment (authorisation being arranged by 
> unencrypted and unsigned email over a public network) can do whatever they 
> like to other machines.

No security-aware hosting center will let run people around
unsupervised unless every customer has a steel-cage of his own.


> But that's beside the point.  The fact that some people choose to not use a 
> particular security method does not mean that I will choose to not support 
> it.

I agree. The point was that lilo.conf may or may not be especially
sensitive, depending on the setup. It may be, but similiar points may
be made for many other files (/etc/ppp/*.secrets, snmp config files,
quite a lot of things actually).

See my other posting - where the "line of authority" runs is a specific
question. On some systems, root=god will still (largely) be true with
SELinux installed, on other systems even two of the three admins may
not be authorized to access lilo.conf.

Difficult to generalize.

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

On Tue, 23 Apr 2002 14:20, Tom wrote:
> > Think of terminals in Internet Cafe's and University computer labs.
>
> But how does a boot-password offer any protection in these settings?

Simple, if you don't have a password then anyone can enter
"linux init=/bin/bash" at the lilo prompt and take over the machine entirely!

> > > encrypted filesystem being the exception).
> >
> > An encrypted file system is not a magic bullet.  How does the machine
> > with the encrypted file system get it's unlock password?
>
> The same way that it gets the boot password. :)

No.  To boot with the default parameters you don't need a password.  You only 
need a password for maintenance mode.

> > Hosting centers that I am familiar with do not have enough security
> > cameras, and the locks on cabinet doors are easily pickable.  Someone who
> > has authorised access to one company's equipment (authorisation being
> > arranged by unencrypted and unsigned email over a public network) can do
> > whatever they like to other machines.
>
> No security-aware hosting center will let run people around
> unsupervised unless every customer has a steel-cage of his own.

There aren't many security aware hosting centers.

There was one time I accidentally locked my security pass and keys inside the 
hosting room, they let me in without even verifying that there were indeed 
keys and a pass inside the room!  Then the cage in that room was always kept 
unlocked because the key was lost, and a window was open because the 
air-conditioning system was over-loaded.  ;)

> > But that's beside the point.  The fact that some people choose to not use
> > a particular security method does not mean that I will choose to not
> > support it.
>
> I agree. The point was that lilo.conf may or may not be especially
> sensitive, depending on the setup. It may be, but similiar points may
> be made for many other files (/etc/ppp/*.secrets, snmp config files,
> quite a lot of things actually).

So we provide a different type for it and let the users decide who gets 
access to that type.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Tom]

On Tue, Apr 23, 2002 at 02:44:06PM +0200, Russell Coker wrote:
> Simple, if you don't have a password then anyone can enter
> "linux init=/bin/bash" at the lilo prompt and take over the machine entirely!

dumb me. I thought disabling the prompt (as you would do in a cafe or
university) takes care of that. A quick glance into the lilo doc shows
that it doesn't.


> No.  To boot with the default parameters you don't need a password.  You only 
> need a password for maintenance mode.

right again.


> > No security-aware hosting center will let run people around
> > unsupervised unless every customer has a steel-cage of his own.
> 
> There aren't many security aware hosting centers.

then why spend much time on securing the system when any dumbass can
just walk in and take control of it? most servers have easy access to
stuff like hard disks. on a system you care about, you'll almost always
run raid, so your evil neighbour may even be able to steal/swap a drive
without you ever noticing, then take home his "copy" and do with it
whatever he wants (like building up an almost identical system and
swapping that in next time he's over).


> > I agree. The point was that lilo.conf may or may not be especially
> > sensitive, depending on the setup. It may be, but similiar points may
> > be made for many other files (/etc/ppp/*.secrets, snmp config files,
> > quite a lot of things actually).
> 
> So we provide a different type for it and let the users decide who gets 
> access to that type.

the point I was trying to make is whether we really want to provide
different types for almost everything inside /etc. if the answer is
yes, I'll shut up, just wanted to point out that lilo won't be the last
program to warrant that kind of attention.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Russell Coker]

On Tue, 23 Apr 2002 17:36, Tom wrote:
> On Tue, Apr 23, 2002 at 02:44:06PM +0200, Russell Coker wrote:
> > Simple, if you don't have a password then anyone can enter
> > "linux init=/bin/bash" at the lilo prompt and take over the machine
> > entirely!
>
> dumb me. I thought disabling the prompt (as you would do in a cafe or
> university) takes care of that. A quick glance into the lilo doc shows
> that it doesn't.

Also you definately don't want to totally disable it.  You want to allow 
authorised people to perform maintenance on the machines without taking them 
apart (with machines that have no other boot device than a hard drive it's 
mandatory to allow "linux init=/bin/bash" for emergencies).

> > > No security-aware hosting center will let run people around
> > > unsupervised unless every customer has a steel-cage of his own.
> >
> > There aren't many security aware hosting centers.
>
> then why spend much time on securing the system when any dumbass can
> just walk in and take control of it? most servers have easy access to
> stuff like hard disks. on a system you care about, you'll almost always
> run raid, so your evil neighbour may even be able to steal/swap a drive
> without you ever noticing, then take home his "copy" and do with it
> whatever he wants (like building up an almost identical system and
> swapping that in next time he's over).

1)  You do the best you can.

2)  Walking into a hosting center with a set of lock picks and a fake ID 
takes more guts than most attackers have.

3)  Not all hosting environments are insecure.

> > > I agree. The point was that lilo.conf may or may not be especially
> > > sensitive, depending on the setup. It may be, but similiar points may
> > > be made for many other files (/etc/ppp/*.secrets, snmp config files,
> > > quite a lot of things actually).
> >
> > So we provide a different type for it and let the users decide who gets
> > access to that type.
>
> the point I was trying to make is whether we really want to provide
> different types for almost everything inside /etc. if the answer is
> yes, I'll shut up, just wanted to point out that lilo won't be the last
> program to warrant that kind of attention.

Actually there's many things that are currently in different types which 
don't need it IMHO.  Such as resolv.conf.  Probably most daemon config files 
could be etc_t except where the daemon re-writes it's own config.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Stephen Smalley]

On Tue, 23 Apr 2002, Russell Coker wrote:

> Actually there's many things that are currently in different types which
> don't need it IMHO.  Such as resolv.conf.  Probably most daemon config files
> could be etc_t except where the daemon re-writes it's own config.

resolv.conf has a separate type to support the dhcpc and pump domains.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot loader

[Tom]

On Mon, Apr 22, 2002 at 06:27:54PM -0400, Stephen Smalley wrote:
> There is one other potential issue.  If an administrator directly edits
> /etc/lilo.conf, it will revert to etc_t (and become inaccessible to lilo
> unless it is then relabeled by the administrator).  Is there any strong
> reason to maintain a separate type on this file?  It is problematic to
> keep it in a separate type from other /etc files, since it may be directly
> modified by the administrator and it doesn't live in its own separate
> subdirectory.

It may be more tricky even. I'm thinking about split administrator access 
here. Say you have one network and one system admin. Network admin needs 
to access stuff in /etc (such as interface configs, maybe some or all 
network daemons, depending on where authorities are split) while system 
admin needs access to other /etc files (cron and startup files, among 
others).


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

boot loader

[Cort Dougan]

I haven't seen any candidate bootloaders so I'm starting with the current
arch/ppc/boot/

I did some cleanups today and committed them to cvs.  I'll put a tar file
up at linuxppc.cs.nmt.edu/pub/linuxppc/kernel-source shortly.  Please
take a look at that code and let me know the problems you have with it.
We'll build from there.



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: boot loader

[Gabriel Paubert]

On Sat, 6 Mar 1999, Cort Dougan wrote:

> 
> I haven't seen any candidate bootloaders so I'm starting with the current
> arch/ppc/boot/

Sorry about that. I did not have much time lately.

> 
> I did some cleanups today and committed them to cvs.  I'll put a tar file

Which cvs ? 

	Gabriel. 


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: boot loader

[Cort Dougan]

I understand. 

}Sorry about that. I did not have much time lately.

VGER.  Until bitkeeper is ready (a couple weeks it looks like) I'll be
putting things on vger and creating tarballs at linuxppc.cs.nmt.edu.

}> I did some cleanups today and committed them to cvs.  I'll put a tar file
}
}Which cvs ? 


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]