Date: Wed, 16 Jan 2013 21:11:15 -0800 From: Charles DeBardeleben <cfd@cfdhome.com> To: freebsd-arch@freebsd.org Subject: Re: LLVM Image Activator Message-ID: <1358399475.2860.56.camel@nat.cfdhome.com> In-Reply-To: <20130114185646.GB15933@lor.one-eyed-alien.net> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <CAJOYFBAZ-XQ1vash3H%2B0wA8GCoMS59eARMnA3y%2BsaPwMJqL0aQ@mail.gmail.com> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> <50F2F97B.5030306@freebsd.org> <20130113202435.GN1410@funkthat.com> <20130114185646.GB15933@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Just adding my $0.02 to the architectural concept of the use of magic numbers. I believe that the whole concept if using any form of the data content of a file to decide what should should interpret the data is flawed. I believe that this information is properly stored as meta-data of the file, which for UNIX would probably most naturally be part of the inode. I think that main reason we rely on "magic" for this is an over reaction of original UNIX authors to not having been granted permission to set this part of meta-data in their past. Now, given the long history of using magic numbers this way, I doubt that they will go away. However, there currently is still very little use of magic numbers in the base kernel. I have to wonder if it may be a better idea to think about a general mechanism to have the meta-data of a file have an explicit "interpreter" or perhaps even a more general "access method" vector rather than begin the process of importing libmagic into the kernel. -Charles On Mon, 2013-01-14 at 12:56 -0600, Brooks Davis wrote: > On Sun, Jan 13, 2013 at 12:24:35PM -0800, John-Mark Gurney wrote: > > Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800= : > > > On 01/13/13 09:13, Konstantin Belousov wrote: > > > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > > > >> On 01/13/13 05:20, Konstantin Belousov wrote: > > > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > > > >>>> Hi Kostik, > > > >>>> > > > >>>> 2013/1/7 Konstantin Belousov <kostikbel@gmail.com>: > > > >>>>> I still do remember the buzz about the binary format 0xCAFEBABE= , which > > > >>>>> AFAIR gained image activator support on several OSes, to be gar= bage > > > >>>>> collected. > > > >>>> > > > >>>> Maybe it would then be a good idea then to add some kind of gene= ral > > > >>>> purpose remapping imgact? Example: > > > >>>> > > > >>>> /etc/imgacttab: > > > >>>> > > > >>>> cafebabe /usr/local/bin/java > > > >>>> cffaedfe /usr/local/bin/osx_emulator > > > >>>> 4243c0de /usr/bin/lli > > > >>>> > > > >>>> That way we still give people the freedom to play around with ma= pping > > > >>>> their own executable formats, but don't need to maintain a bunch= of > > > >>>> imgacts. > > > >>> > > > >>> A generic module that could be somewhat customized at runtime to = map > > > >>> offset+signature into the shebang path could be a possibility ind= eed. > > > >>> I strongly prefer to have it as module and not enabled by default= . > > > >>> > > > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in > > > >>> the response to the 50-lines hack. > > > >>> > > > >> > > > >> I think this is a good idea, since it both prevents a profusion of > > > >> similar activators and works nicely in jails and similar environme= nts. I > > > >> probably won't write it quickly, but it should not take more than = about > > > >> 50 lines, so I can't imagine it will be that bad. There are some > > > >> complications with this kind of design from the things in the XXX > > > >> comment in imgact_llvm.c about handling argv[0] that I need to thi= nk > > > >> some more about. > > > > Great. I do not believe in the 50 lines, but I am happy that you wa= nt > > > > to work this out. > > > >=20 > > > >> > > > >> Why are you opposed to having it there by default? I think it's ac= tually > > > >> quite important that it be there by default. Having it not "standa= rd" > > > >> would be fine, but it should at least be in GENERIC. There are min= imal > > > >> security risks since it just munges begin_argv and doesn't even lo= ad the > > > >> executable and it's little enough code that there should not be an= y > > > >> kernel bloat to speak of. If things like this aren't enabled by de= fault, > > > >> no one can depend on them being there, no one will use it, and the= point > > > >> is entirely lost. > > > > All image activators demonstrated a constant stream of security hol= es. > > > > Even our ELF activator, and I was guilty there too. > > > >=20 > > > > I definitely do not fight over the inclusion of the proposed activa= tor > > > > into GENERIC, but do insist on the config option + module. > > > >=20 > > >=20 > > > OK, that sounds like a plan then. I'll try to code up something > > > configurable in the next couple weeks, unless someone else beats me t= o it. > >=20 > > I'll point out that file already has the magic (pun intended) that we > > are looking for, though I do realize that the code might be a bit much > > to import.. >=20 > As someone who recently stuffed libmagic into a very constrained sandbox > environment, I can safely assert that you don't want to go there. The > code isn't written in a way that would make this easy and I definitely > wouldn't want it in the kernel. >=20 > -- Brooks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358399475.2860.56.camel>