From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f195.google.com ([209.85.216.195]:35377 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755942AbeCHTEf (ORCPT ); Thu, 8 Mar 2018 14:04:35 -0500 Received: by mail-qt0-f195.google.com with SMTP id z14so7972993qti.2 for ; Thu, 08 Mar 2018 11:04:34 -0800 (PST) Date: Thu, 8 Mar 2018 12:04:31 -0700 From: Tycho Andersen To: Mimi Zohar Cc: Andy Shevchenko , Dmitry Kasatkin , linux-integrity@vger.kernel.org, Linux Kernel Mailing List , kernel-hardening@lists.openwall.com Subject: Re: [PATCH] ima: drop vla in ima_audit_measurement() Message-ID: <20180308190431.5fstqsjmbpquzqii@smitten> References: <20180308171456.2597-1-tycho@tycho.ws> <20180308183721.mnsrmhekyfo2dbso@smitten> <1520535030.3605.64.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <1520535030.3605.64.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Thu, Mar 08, 2018 at 01:50:30PM -0500, Mimi Zohar wrote: > On Thu, 2018-03-08 at 11:37 -0700, Tycho Andersen wrote: > > On Thu, Mar 08, 2018 at 07:47:37PM +0200, Andy Shevchenko wrote: > > > On Thu, Mar 8, 2018 at 7:14 PM, Tycho Andersen wrote: > > > > In keeping with the directive to get rid of VLAs [1], let's drop the VLA > > > > from ima_audit_measurement(). We need to adjust the return type of > > > > ima_audit_measurement, because now this function can fail if an allocation > > > > fails. > > > > > > > > > > > > > + algo_hash_len = hash_len + strlen(algo_name) + 2; > > > > + algo_hash = kzalloc(algo_hash_len, GFP_KERNEL); > > > > > > > - snprintf(algo_hash, sizeof(algo_hash), "%s:%s", algo_name, hash); > > > > + snprintf(algo_hash, algo_hash_len, "%s:%s", algo_name, hash); > > > > > > kasprintf() ? > > > > Sure, in fact I think we could just do: > > > > - snprintf(algo_hash, algo_hash_len, "%s:%s", algo_name, hash); > > - audit_log_untrustedstring(ab, algo_hash); > > + audit_log_untrustedstring(ab, algo_name); > > + audit_log_format(ab, ":"); > > + audit_log_untrustedstring(ab, hash); > > > > and get rid of the allocation entirely. I'll test and make sure it > > works and then re-send. > > The hash algorithm name is an enumeration that comes from the kernel. > It's defined in crypto/hash_info.c: hash_algo_name. Why do we need > to use audit_log_untrustedstring()? Yes, I suppose we don't need it for the hash either, since we're generating that and we know it's just hex digits and not any audit control characters or "s or anything. It looks like we could get rid of the other allocation too by just using audit_log_n_hex, but that uses hex_byte_pack_upper, vs. the hex_byte_pack that's currently in use in this function. Is that too much of a breakage? Tycho