Date: Fri, 1 Oct 2010 04:34:34 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: freebsd-stable@freebsd.org Subject: Re: boot0cfg problems Message-ID: <20101001113434.GA43360@icarus.home.lan> In-Reply-To: <E1P1dfO-000BRI-MZ@kabab.cs.huji.ac.il> References: <E1P1a0v-0009QQ-Rt@kabab.cs.huji.ac.il> <20101001090143.GA40450@icarus.home.lan> <E1P1dfO-000BRI-MZ@kabab.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 01, 2010 at 01:20:42PM +0200, Daniel Braniss wrote:
> > On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > > partialy worked, it would modify the data in boot but not the mbr, for
> > > which 'gpart -s set active -in ...' modified the mbr. Now
> > > # boot0cfg -s1 -v /dev/mfid0
> > > boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
> > > but:
> > > # boot0cfg -v /dev/mfid0
> > > # flag start chs type end chs offset size
> > > 1 0x80 0: 1: 1 0xa5 1023:212:63 63 41943006
> > > 2 0x00 1023:255:63 0xa5 1023:169:63 41943069 41943006
> > > 3 0x00 1023:255:63 0xa5 1023:126:63 83886075 41943006
> > > 4 0x00 1023:255:63 0xa5 1023:201:63 125829081 1046478825
> > >
> > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23)
> > > options=packet,update,nosetdrv
> > > volume serial ID 9090-9090
> > > default_selection=F2 (Slice 2)
> >
> > Can you try doing "sysctl kern.geom.debugflags=16" first?
> >
> this is not realy foot-shooting :-), but
> - the error msg is gone,
> - the slice info is updated,
> - but the active bit in the mbr is not! - some bioses rely on it.
> looking at changes done to boot0cfg.c there is now an err(...) call which
> does an exit, before the boot is updated. I changed it to a warn(...) and the
> old
> behaviour is back.
> BTW,
> a- gpart command should have been: gpart set -a active -i n ...
> b- this works with kern.geom.debugflags=0.
Bit 4 (hence 0x10, or 16 decimal) in kern.geom.debugflags is described
as:
0x10 (allow foot shooting)
Allow writing to Rank 1 providers. This would, for example,
allow the super-user to overwrite the MBR on the root disk or
write random sectors elsewhere to a mounted disk. The implica‐
tions are obvious.
I read this as: "you can't modify the MBR of a root disk unless bit 4 of
this sysctl is set". Sector 0 holds the MBR, and boot0cfg modifies the
MBR. So can you explain what you mean by "this really isn't
foot-shooting?" I mean, even the NOTE section of the boot0cfg(8) man
page documents what I'm trying to say.
Anyway, if the MBR did get updated without kern.geom.debugflags having
bit 4 set, then wouldn't this indicate there's a bug in GEOM's "sector
0" protection?
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101001113434.GA43360>