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