not be copied (using something like
memcpy). Readable code should not depend on the weird behavior of strncpy
when it hits the length limit. Better to avoid the anti-pattern entirely.
Signed-off-by: Kees Cook
---
This is a follow-up to the anti-pattern being fixed in iscsi-target,
which was
.
>
> Note that I don't export the constant, since we will do even a better
> thing soon: we will switch console logging to a new write_buf API, which
> will eliminate the need for the additional buffer; and so we won't need
> the constant.
>
> Reported-by: Dan Carpente
On Mon, Jul 9, 2012 at 4:45 PM, Anton Vorontsov
wrote:
> Just a few patches left from the series that used to add configurable
> ECC size for pstore/ram backend. Most patches were merged into -next,
> and this is just a resend of the leftovers.
Feel free to add my:
Acked-by: Kees Cook
informative. Instead, print
> ecc_size and buffer_size;
>
> - No need for buffer_size argument in persistent_ram_init_ecc(),
> we can address prz->buffer_size directly.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
fe
> at all times.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Mon, Jun 18, 2012 at 7:15 PM, Anton Vorontsov
wrote:
> persistent_ram_new() returns ERR_PTR() value on errors, so during
> freeing of the przs we should check for both NULL and IS_ERR() entries,
> otherwise bad things will happen.
>
> Signed-off-by: Anton Vorontsov
Acke
d-by: Colin Cross
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
(it should
> be just <= 0), but 0 feels more correct.
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Sat, May 26, 2012 at 6:20 AM, Anton Vorontsov
wrote:
> We're about to add support for other message types, so let's rename
> some variables to not be confused later.
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel ma
unsigned int part, size_t size, struct pstore_info
> *psi);
> + int (*write_buf)(enum pstore_type_id type,
> + enum kmsg_dump_reason reason, u64 *id,
> + unsigned int part, const char *buf, size_t size,
> + struct pst
On Tue, May 22, 2012 at 12:04 PM, Greg Kroah-Hartman
wrote:
> On Tue, May 22, 2012 at 11:33:33AM -0700, Kees Cook wrote:
>> On Tue, May 22, 2012 at 11:19 AM, Greg Kroah-Hartman
>> wrote:
>> > On Tue, May 22, 2012 at 07:17:17AM -0700, Anton Vorontsov wrote:
>> >
was in -next (via -mm) that now landed in
-staging make it sanely into 3.5? Specifically the two patches at the
top of:
http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/ramoops
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
__
00; -1 means runtime updates are disabled)");
> + "(default is -1, which means runtime updates are disabled; "
> + "enabling this option is not safe)");
Perhaps "enabling this option may lead to further corruption on
Oopses" or
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> There is no behavioural change, the default value is still 60 seconds.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing l
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> The console log size is configurable via ramoops.console_size
> module option, and the log itself is available via
> /console-ramoops file.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chr
(it should
> be just <= 0), but 0 feels more correct.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
ation detail: we now use a paddr pointer, this will
> be used for allocating persistent ram zones for other message
> types.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> So far it is the same as max_count, but this will change when
> we'll add support for other message types (e.g. console, mce,
> tracing).
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Coo
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Otherwise, unlinked file will reappear on the next boot.
>
> Reported-by: Kees Cook
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
d
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> A handy function that we will use outside of ram_core soon. But
> so far just factor it out and start using it in post_init().
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome
ving it wasn't an intentional change, so let's
> restore it.
>
> For this we have to make persistent_ram_save_old() safe for calling
> multiple times, and also extern it.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
static?
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
c_on_oops=0, and plenty of failure paths will
just kill "current" instead of bringing the entire system down. I
would much rather allow for the possibility to get oopses when they
happen than to have to wait a full reboot cycle to "notice" them.
-Ke
: Anton Vorontsov
Acked-by: Kees Cook
-Kees
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
tsov
Acked-by: Kees Cook
-Kees
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Thu, May 17, 2012 at 1:40 AM, Anton Vorontsov
wrote:
> This is all straightforward: we just use the last region for
> console logging. If there's just one region, we fall-back to
> the old behaviour: just a oops/dumps logging.
>
> Signed-off-by: Anton Vorontsov
Acked-b
ve).
> cxt->count = (cxt->count + 1) % cxt->max_count;
>
> @@ -167,14 +172,12 @@ static int ramoops_pstore_write(enum pstore_type_id
> type,
> static int ramoops_pstore_erase(enum pstore_type_id type, u64 id,
> struct pstore_info *psi)
&g
nserted -> driver tried to write a reserved bits ->
> SoC hanged. In that case we don't get any messages in the pstore.
>
> Therefore, let's add a runtime logging support: PSTORE_TYPE_CONSOLE.
>
> Signed-off-by: Anton Vorontsov
Acked-
he size of psinfo->buf needs to be the length argument to strncpy,
not the size of "s". If "s" isn't NULL terminated, then the min of c
and buf's size should be used. And if this should be NULL terminated
in buf, that needs to be added manually since strncpy won't do it if
it hits the max length argument.
-Kees
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
; + if (!cxt->cprz)
> + return -ENOMEM;
> + persistent_ram_write(cxt->cprz, cxt->pstore.buf, size);
> + }
> +
> if (type != PSTORE_TYPE_DMESG)
> return -EINVAL;
Doesn't this mean that type
d still
> work).
>
> Signed-off-by: Anton Vorontsov
> Acked-by: Marco Stornelli
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Tue, May 15, 2012 at 11:14 PM, Anton Vorontsov
wrote:
> Hello Kees,
>
> On Mon, May 14, 2012 at 03:21:17PM -0700, Kees Cook wrote:
> [...]
>> > - buf = cxt->virt_addr + (id * cxt->record_size);
>> > - memset(buf, '\0', cxt->recor
On Fri, May 11, 2012 at 5:18 PM, Anton Vorontsov
wrote:
> This is now straightforward: just introduce a module parameter and pass
> the needed value to persistent_ram_new().
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
> ---
> fs/pstore/ram.c | 12 +---
ister(&cxt->pstore);
> if (err) {
> pr_err("registering with pstore failed\n");
> - goto fail_iounmap;
> + goto fail_pstore;
This should be fail_buf.
> }
>
> /*
> @@ -280,15 +289,17 @@ static int __init ramoops_probe(struct platform_device
> *pdev)
>
> return 0;
>
> -fail_iounmap:
> - iounmap(cxt->virt_addr);
> -fail_mem_region:
> - release_mem_region(cxt->phys_addr, cxt->size);
> -fail_buf:
> +fail_pstore:
No reason to rename this from "fail_buf".
> kfree(cxt->pstore.buf);
> fail_clear:
> cxt->pstore.bufsize = 0;
> cxt->max_count = 0;
> +fail_przs:
> + for (i = 0; cxt->przs[i]; i++)
> + persistent_ram_free(cxt->przs[i]);
This can lead to a BUG, since persistent_ram_free() doesn't handle
NULL arguments.
> + kfree(cxt->przs);
> +fail_prz:
> + kfree(cxt->pstore.buf);
This target (fail_prz) should be removed, and the kfree is redundant
to fail_buf above.
> fail_out:
> return err;
> }
> --
> 1.7.9.2
>
-Kees
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
optionally] ECC-protected persistent ram regions.
>
> A bit of Makefile, Kconfig and header files adjustments were needed
> because of the move.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
> include/linux/pstore_ram.h | 86 -
This change includes the f
__RAMOOPS_H
> +#define __RAMOOPS_H
This define should probably change just to avoid confusion.
-Kees
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Hi Greg,
On Wed, Oct 06, 2010 at 03:51:04PM -0700, Greg KH wrote:
> Nice catch, but I don't think that the dev pointer can ever be NULL
> here.
Yeah, I didn't think so either, but figured it was best to fix it anyway.
-Kees
--
Kees Cook
Ubun
Found via http://coccinelle.lip6.fr/rules/mini_null_ref.cocci
Signed-off-by: Kees Cook
---
drivers/staging/tm6000/tm6000-alsa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
b/drivers/staging/tm6000/tm6000-alsa.c
index 087137d
38 matches
Mail list logo
