linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Vitaly Chikunov <vt@altlinux.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity@vger.kernel.org
Subject: Re: [PATCH] ima-evm-utils: Namespace some too generic function names
Date: Thu, 25 Jul 2019 07:48:01 -0400	[thread overview]
Message-ID: <1564055281.4245.108.camel@linux.ibm.com> (raw)
In-Reply-To: <20190725015329.q6cu7vxtzjpfve4m@altlinux.org>

On Thu, 2019-07-25 at 04:53 +0300, Vitaly Chikunov wrote:
> Mimi,
> 
> On Wed, Jul 24, 2019 at 07:24:20PM -0400, Mimi Zohar wrote:
> > On Wed, 2019-07-24 at 23:42 +0300, Vitaly Chikunov wrote:
> > > Prefix `dump', `do_dump', and `params' with `ima_' to avoid colliding
> > > with other global symbols.
> > 
> > The package is named ima-evm-utils, the tool is named evmctl, and now
> > we're prefixing the global symbols with "ima".  Some of the functions,
> > like dump(), are used by both "ima" and "evm".  Aiming for some sort
> > of consistency, maybe it should be prefixed with "ima_evm", not just
> > "ima_"? 
> 
> Just ima_ is OK with me. EVM could be thought as IMA extension.

At least in the kernel, I've tried really hard to keep them as two
independent subsystems.  Does it make sense to use EVM without IMA,
probably not.  The EVM design allows for other subsystems, not only
IMA, to verify the file metdata integrity.  In fact, I heard about
some plans, relatively recently, to do so.

> Or we can use evm_ like in evmctl. Or imaevm_ (without underscore, like
> in libimaevm or imaevm.h).

There's already a lot of confusion as to what is "IMA".  Not only can
IMA be configured to store measurements, but can also be configured to
verify file signatures/hashes and audit file hashes.  Not that anyone
is looking at the naming details in this code, but I don't think we
should add to the confusion.  Could we use "imaevm_" as you suggested?

struct libimaevm_params {
        int verbose;
        int x509;
        const char *hash_algo;
        const char *keyfile;
        const char *keypass;
};

extern struct libimaevm_params ima_params;

imaevm_params?

> 
> > dump() should never have been named just "dump".  It should have at
> > least been named "hexdump".
> >  
> > > `params' is prefixed with a #define trick to avoid change in half
> > > hundred places.
> > 
> > Perhaps separate this change from the other change?
> 
> I agree to Bruno E. O. Meneguele it's better to actually rename `params'
> like other functions instead of redefining. Then all renames can go in
> one commit?

Sure.

"get_hash_algo()" can't be made static as it is being called from
hash_ima().  Could you also include renaming "get_hash_algo()" as
well?

Thanks!

Mimi


      reply	other threads:[~2019-07-25 11:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 20:42 [PATCH] ima-evm-utils: Namespace some too generic function names Vitaly Chikunov
2019-07-24 21:46 ` Bruno E. O. Meneguele
2019-07-24 23:24 ` Mimi Zohar
2019-07-25  1:53   ` Vitaly Chikunov
2019-07-25 11:48     ` Mimi Zohar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1564055281.4245.108.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=vt@altlinux.org \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).