linux-kernel - Re: [PATCH next v3 5/8] printk: ringbuffer: clear initial reserved fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200901143306.GQ4928@alley>
Date:   Tue, 1 Sep 2020 16:33:06 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Paul McKenney <paulmck@...nel.org>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH next v3 5/8] printk: ringbuffer: clear initial reserved
 fields

On Mon 2020-08-31 03:16:55, John Ogness wrote:
> prb_reserve() will set some meta data values and leave others
> uninitialized (or rather, containing the values of the previous
> wrap). Simplify the API by always clearing out all the fields.
> Only the sequence number is filled in. The caller is now
> responsible for filling in the rest of the meta data fields.
> In particular, for correctly filling in text and dict lengths.
> 
> Signed-off-by: John Ogness <john.ogness@...utronix.de>
>
> ---
>  kernel/printk/printk.c            |  7 ++++++-
>  kernel/printk/printk_ringbuffer.c | 29 +++++++++++++++++++----------
>  2 files changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index ad8d1dfe5fbe..7e7d596c8878 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -520,8 +520,11 @@ static int log_store(u32 caller_id, int facility, int level,
>  	memcpy(&r.text_buf[0], text, text_len);
>  	if (trunc_msg_len)
>  		memcpy(&r.text_buf[text_len], trunc_msg, trunc_msg_len);
> -	if (r.dict_buf)
> +	r.info->text_len = text_len + trunc_msg_len;
> +	if (r.dict_buf) {
>  		memcpy(&r.dict_buf[0], dict, dict_len);
> +		r.info->dict_len = dict_len;
> +	}
>  	r.info->facility = facility;
>  	r.info->level = level & 7;
>  	r.info->flags = flags & 0x1f;
> @@ -1078,9 +1081,11 @@ static unsigned int __init add_to_rb(struct printk_ringbuffer *rb,
>  		return 0;
>  
>  	memcpy(&dest_r.text_buf[0], &r->text_buf[0], dest_r.text_buf_size);
> +	dest_r.info->text_len = r->info->text_len;

It looks a bit non-consistent that memcpy() copies text_buf_size but valid data
are defined by text_len.

I would prefer to be on the safe size and copy only text_len.

I could imagine some later optimization that will make buf_size bigger
by alignment or something like that. The reason might be preparation
for continuous lines or so. Then the size of the original buffer and
the destination one might differ.

It is unrelated to this patch. I would solve it by a preparation
or followup one.


>  	if (dest_r.dict_buf) {

>  		memcpy(&dest_r.dict_buf[0], &r->dict_buf[0],
>  		       dest_r.dict_buf_size);
> +		dest_r.info->dict_len = r->info->dict_len;

Same here.

>  	}
>  	dest_r.info->facility = r->info->facility;
>  	dest_r.info->level = r->info->level;
> diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c
> index d66718e74aae..da54d4fadf96 100644
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kernel/printk/printk_ringbuffer.c
> @@ -1159,6 +1162,18 @@ bool prb_reserve(struct prb_reserved_entry *e, struct printk_ringbuffer *rb,
>  
>  	d = to_desc(desc_ring, id);
>  
> +	/*
> +	 * Clear all @info fields except for @seq, which is used to determine
> +	 * the new sequence number. The writer must fill in new values.
> +	 */
> +	d->info.ts_nsec = 0;
> +	d->info.text_len = 0;
> +	d->info.dict_len = 0;
> +	d->info.facility = 0;
> +	d->info.flags = 0;
> +	d->info.level = 0;
> +	d->info.caller_id = 0;

This will be easy to miss when a new field is added in the future.

I would prefer to store @seq into temporary variable and clear
the entire structure by memset(). The new sequence number is
calculated few lines below anyway.


Otherwise, it looks good to me.

Best Regards,
Petr