read only

read only

[Paonia Ezrine]

I am looking to use the DOC or similar with lrp. Is there a way to set the
device to read only mode so that no one can hack with it. I dont mean a
software setting but a hardware one. Also which DOC or similar would
people project for this application. Porlby need 2-20 megs.

Re: read only

[David Woodhouse]

paonia@home.welcomehome.org said:
> I am looking to use the DOC or similar with lrp. Is there a way to set
> the device to read only mode so that no one can hack with it. I dont
> mean a software setting but a hardware one. Also which DOC or similar
> would people project for this application. Porlby need 2-20 megs. 

Not in hardware AFAIK - at least not simply by cutting control lines - 
you'd have to have some intelligence in between your system bus and the 
DiskOnChip. (logic: when the host writes to location 0x1004 in the device, 
you ensure that bit 3 (WP) is _always_ set - mask it in if the host didn't 
set it.)

However, it's quite feasible to cut out the write capability in the device
driver, so that an attacker would have to load his own driver for it if he 
wanted to write to it. That would probably be enough for your purposes.

I've been intending to do that for a while now anyway - as it would mean I
could mark the write support as experimental.

In fact, read-only support is all I'd really want people to use the MTD 
DiskOnChip driver for right now.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: read only

[Paonia Ezrine]

> 
> paonia@home.welcomehome.org said:
> > I am looking to use the DOC or similar with lrp. Is there a way to set
> > the device to read only mode so that no one can hack with it. I dont
> > mean a software setting but a hardware one. Also which DOC or similar
> > would people project for this application. Porlby need 2-20 megs. 
> 
> Not in hardware AFAIK - at least not simply by cutting control lines - 
> you'd have to have some intelligence in between your system bus and the 
> DiskOnChip. (logic: when the host writes to location 0x1004 in the device, 
> you ensure that bit 3 (WP) is _always_ set - mask it in if the host didn't 
> set it.)
> 
> However, it's quite feasible to cut out the write capability in the device
> driver, so that an attacker would have to load his own driver for it if he 
> wanted to write to it. That would probably be enough for your purposes.
> 
> I've been intending to do that for a while now anyway - as it would mean I
> could mark the write support as experimental.
> 
> In fact, read-only support is all I'd really want people to use the MTD 
> DiskOnChip driver for right now.
> 
> --
> dwmw2
> 
> 
I am not sure how I would update the image then. And also garentee that
noone else can. 
Thanks
Paonia



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: read only

[David Woodhouse]

paonia@home.welcomehome.org said:
> I am not sure how I would update the image then. And also garentee
> that noone else can. 

Presumably, when you wanted to update the image, you'd boot a different 
kernel - one which has full read/write support. You can't _guarantee_ that 
your attacker won't reboot the system onto the same kernel, but it's 
certainly far less likely, and far more detectable.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: read only

[Trevor Woolven]

Paonia Ezrine wrote:
> 
> >
> > paonia@home.welcomehome.org said:
> > > I am looking to use the DOC or similar with lrp. Is there a way to set
> > > the device to read only mode so that no one can hack with it. I dont
> > > mean a software setting but a hardware one. Also which DOC or similar
> > > would people project for this application. Porlby need 2-20 megs.
> >
> > Not in hardware AFAIK - at least not simply by cutting control lines -
> > you'd have to have some intelligence in between your system bus and the
> > DiskOnChip. (logic: when the host writes to location 0x1004 in the device,
> > you ensure that bit 3 (WP) is _always_ set - mask it in if the host didn't
> > set it.)
> >
> > However, it's quite feasible to cut out the write capability in the device
> > driver, so that an attacker would have to load his own driver for it if he
> > wanted to write to it. That would probably be enough for your purposes.
> >
> > I've been intending to do that for a while now anyway - as it would mean I
> > could mark the write support as experimental.
> >
> > In fact, read-only support is all I'd really want people to use the MTD
> > DiskOnChip driver for right now.
> >
> > --
> > dwmw2
> >
> >
> I am not sure how I would update the image then. And also garentee that
> noone else can.
> Thanks
> Paonia
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
Just a couple of thoughts: 
a)	you could use two kernels, one with write support, one without and
default boot the 
	read-only one via LILO/GRUB etc. Then you could select the one with
write support on 
	boot-up when you need to. A bit wasteful on disk space and ultimatly
not very secure but it 
	would do what you want.
b)	Break the write support out into a kernel loadable module and load it
as and when required.

BTW: Should the TODO list contain 'develop the driver as a KLM'?

Best regards

Trevor.
-- 
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: read only

[David Woodhouse]

trevw@zentropix.com said:
> b)	Break the write support out into a kernel loadable module and load
> it as and when required.

This would be quite difficult to do, and is probably less secure than the 
'separate kernel' option - at least with a separate kernel, your attacker 
would have to reboot, which is far more likely to be noticed than loading a 
module.

> BTW: Should the TODO list contain 'develop the driver as a KLM'? 

I do all development as modules. Making it work compiled into the kernel is 
usually an afterthought. If anything, the TODO list should contain 'make it 
work when statically-linked'. Especially on 2.2 where the init procedure is 
far more complex than 2.3.

I've now got my original testbed machine back, which has an IDE controller 
supported by 2.2, so I'll be developing on 2.2 for a while.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

read only

[Dvir Oren]

Paonia Ezrine writes ("read only"):

> people project for this application. Porlby need 2-20 megs.

The problem with DoC and flashes in general is that their sizes
grow in time.  I doubt you'll be able to get a 2Mb flash today.
We're having trouble finding 16Mb flashes.

BTW:  I was wondering what sizes of DoC are people on the list using?


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Read Only

[Tiago Giovanaz da Silva]

Hello all!
How to I make for two people not to obtain to use the same archive at
the same time?
For example, with samba, two users can't write in the same file at the
same time.

Thank's
     Tiago


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Read Only

[Trond Myklebust]

ty den 19.10.2004 Klokka 22:43 (-0300) skreiv Tiago Giovanaz da Silva:
> Hello all!
> How to I make for two people not to obtain to use the same archive at
> the same time?
> For example, with samba, two users can't write in the same file at the
> same time.

Short answer: You can't

long answer: Use of advisory POSIX locks (man fcntl) or lock files (see
the NFS FAQ) will do what you want _if_ all the programs that access the
same file use the same locking scheme (that's why they are called
"advisory locks" as opposed to "mandatory locks").

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs