[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1210272337550.22424@wniryva.cad.erqung.pbz>
Date: Sun, 28 Oct 2012 01:46:50 +0530 (IST)
From: P J P <ppandit@...hat.com>
To: Kees Cook <keescook@...omium.org>
cc: Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Josh Triplett <josh@...htriplett.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
linux-fsdevel@...r.kernel.org, halfdog <me@...fdog.net>
Subject: Re: [PATCH] exec: do not leave bprm->interp on stack
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| Al showed a list of them earlier in the thread.
Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
Do people still use - a.out - format? (considering ELF has been the default
standard for so many years)
| I don't have any on the various distros I checked.
Same here, my F17 machine has no entries for binfmt-xxxx modules, in fact I
don't even have the /etc/modprobe.d/aliases.conf file.
Documentation/binfmt_misc.txt talks about executing Java, Python, DOSEMU and
Windows programs which could be supported by loadable modules.
| The problem I see here is that we only want to do module loading in the "no
| match" case. But that means that either we need to restart with the original
| bprm, or we need to keep bprm changes off the stack. Leading with a module
| load is going to wreck performance.
I beg to *slightly* differ here. I agree we currently have a small overhead
of find_module() -> request_module() only when binfmt_xxxx module is already
loaded, partly because find_module can not resolve aliases.
I guess this small overhead is worth it if it helps to make things less
confusing and easy to follow. Besides this overhead does not exist for regular
executables ELFs and scripts alike.
If the required module is missing, a call to request_module() will anyway
happen and its cost remains the same whether it happens before or after the
"match".
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists