rs_control *rs, int len, int errs,
> - int eras, int trials, struct bcstat *stat,
> + int *eras, int trials, struct bcstat *stat,
> struct wspace *ws)
> {
> int nroots = rs->codec->nroots;
> @@ -420,8 +423,11 @@ static int exercise_rs_bc(struct rs_control *rs, struct
> wspace *ws,
> eras = 0;
>
> cutoff = nroots <= len - errs ? nroots : len - errs;
> - for (; eras <= cutoff; eras++)
> - test_bc(rs, len, errs, eras, trials, &stat, ws);
> + for (; eras <= cutoff; eras++) {
> + int no_eras = eras;
> +
> + test_bc(rs, len, errs, &no_eras, trials, &stat, ws);
> + }
> }
>
> if (v >= V_CSUMMARY) {
> --
> 2.25.1
>
Otherwise, yeah, cool. Looks good.
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
process (as the root device or otherwise).
> >
> > Signed-off-by: Will Drewry
> > Signed-off-by: Kees Cook
> > [rework to use dm_ioctl calls]
> > Signed-off-by: Enric Balletbo i Serra
> > [refactored for upstream]
> > Signed-off-by: Helen Koike
>
> Ca
nd the ones that doesn't
> change any block device when the dm is create as read-only. For example,
> mirror and cache targets are not allowed. The rationale behind this is
> that if the user makes a mistake, choosing the wrong device to be the
> mirror or the cache can corrupt d
| 1 +
> init/do_mounts.c| 1 +
> init/do_mounts.h| 10 +
> init/do_mounts_dm.c | 448
>
> 10 files changed, 584 insertions(+), 8 delet
init/do_mounts_dm.c | 459
>
> 9 files changed, 596 insertions(+)
> create mode 100644 Documentation/device-mapper/dm-boot.txt
> create mode 100644 init/do_mounts_dm.c
>
> --
> 2.9.3
>
--
Kees Cook
Pixel Security
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
: linux-bca...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/md/bcache/stats.c | 8 +++-
drivers/md/dm-delay.c | 6 +++---
drivers/md/dm-integrity.c | 6 +++---
drivers/md/dm-raid1.c | 8 +++-
drivers/md/md.c | 9 -
5 files changed
On Mon, Oct 16, 2017 at 7:12 PM, Shaohua Li wrote:
> On Mon, Oct 16, 2017 at 05:01:48PM -0700, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>&
On Mon, Oct 16, 2017 at 8:06 PM, Michael Lyle wrote:
> On 10/16/2017 05:01 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> to pass the tim
ngs are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!
It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happil
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This
inal series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
>
-through
All switch/case blocks must end in one of:
break;
fallthrough;
continue;
goto ;
return [expression];
[3] https://cwe.mitre.org/data/definitions/484.html
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Cc: dm-devel@redhat.com
Signed-off-by: Kees Cook
---
drivers/md/dm-integrity.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 40f8116c8e44..59deea0dd305 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md
On Wed, Oct 13, 2021 at 07:10:15AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Wed, Oct 13, 2021 at 07:10:22AM +0200, Christoph Hellwig wrote:
> No need to convert from bdev to inode and back.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Oct 13, 2021 at 07:10:16AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Wed, Oct 13, 2021 at 07:10:23AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
the series needing:
bdev_nr_sectors(...bdev) << SECTOR_SHIFT
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Oct 13, 2021 at 07:10:14AM +0200, Christoph Hellwig wrote:
> Use the equivalent block layer helper instead.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
; }
>
> - devsize = mapping->host->i_size >> PAGE_SHIFT;
> + devsize = bdev_nr_sectors(sb->s_bdev) >> (PAGE_SHIFT - SECTOR_SHIFT);
I find this less readable than "bytes >> PAGE_SHIFT". I'd suggest this
use a new bdev_nr_bytes()
On Wed, Oct 13, 2021 at 07:10:26AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Wed, Oct 13, 2021 at 07:10:27AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Wed, Oct 13, 2021 at 07:10:28AM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
+}
> +
> int bdev_disk_changed(struct gendisk *disk, bool invalidate);
> void blk_drop_partitions(struct gendisk *disk);
>
> --
> 2.30.2
>
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
;& ext4_blocks_count(es) > blocks_count) {
> ext4_msg(sb, KERN_WARNING, "bad geometry: block count %llu "
> "exceeds size of device (%llu blocks)",
> --
> 2.30.2
>
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
/* check blocks count against device size */
> - blocks_count = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> + blocks_count = sb_bdev_nr_blocks(sb);
Wait, my bad. Yes, this is fine. It's going through two helpers. :)
Reviewed-by:
On Wed, Oct 13, 2021 at 07:10:39AM +0200, Christoph Hellwig wrote:
> Use the sb_bdev_nr_blocks helper instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman
BUG_ON(blocksize != sb->s_blocksize);
> - vol->nr_blocks = i_size_read(sb->s_bdev->bd_inode) >>
> - sb->s_blocksize_bits;
> + vol->nr_blocks = sb_bdev_nr_blocks(sb);
> ntfs_debug("Change
On Wed, Oct 13, 2021 at 07:10:41AM +0200, Christoph Hellwig wrote:
> Use the sb_bdev_nr_blocks helper instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman
On Wed, Oct 13, 2021 at 07:10:42AM +0200, Christoph Hellwig wrote:
> Use the sb_bdev_nr_blocks helper instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman
owlevel.c | 5 ++---
> fs/udf/super.c |9 +++--
> include/linux/genhd.h |6 ++
> 56 files changed, 100 insertions(+), 117 deletions(-)
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
.
> >
> > No strong opinion here but I do agree with you that bdev_size() is a bad
> > choice for sure. It is bound to cause bugs down the line when people
> > forget what unit it is in.
>
> I don't really mind bdev_size since it's analogous to i_size, but
> bdev_nr_bytes seems good to me.
I much prefer bdev_nr_bytes(), as "size" has no units.
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Fri, Oct 15, 2021 at 03:26:14PM +0200, Christoph Hellwig wrote:
> Ensure these are always available for inlines in the various block layer
> headers.
>
> Signed-off-by: Christoph Hellwig
Awesome, yes. Thanks!
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing l
On Fri, Oct 15, 2021 at 03:26:20PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
gt;bd_inode.
>
> Matthew already pointed out the return type for bdev_nr_bytes() but also your
> commit message has a typo: "Add a helpe" -> "Add a helper".
Right. With these fixed, I'm a fan. :)
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
--
dm-devel mailin
On Fri, Oct 15, 2021 at 03:26:21PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Chaitanya Kulkarni
Is this basically an open-coded non-sb version of sb_bdev_nr_blocks()?
Reviewed-b
On Fri, Oct 15, 2021 at 03:26:22PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:26PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:30PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:31PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:32PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:33PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:34PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Thanks for the bdev_by_bytes() helper; this is more readable now. :)
Acked-by: Kees Cook
--
Kees Cook
--
dm-devel mailin
On Fri, Oct 15, 2021 at 03:26:35PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size and remove two
> cargo culted checks that can't be false.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mail
On Fri, Oct 15, 2021 at 03:26:36PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
On Fri, Oct 15, 2021 at 03:26:37PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
ut
> eventually.
>
> Signed-off-by: Christoph Hellwig
You can adjust this changelog to remove the note about SECTOR_SHIFT
now. :)
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Fri, Oct 15, 2021 at 03:26:25PM +0200, Christoph Hellwig wrote:
> Use the proper helper to read the block device size.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/li
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.
Add struct_group() to mark region of struct journal_sector that should be
initialized to zero.
Signed-off-by: Kees Cook
---
drivers
Cc: dm-devel@redhat.com
Signed-off-by: Kees Cook
---
drivers/md/dm-integrity.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 6319deccbe09..163c94ca4e5c 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md
ed
roothashes come from? I assume some chain of trust exists. Is the list
maybe already stored on the rootfs?
It'd be nice if there was some way to pass the trust chain to LoadPin
more directly.
-Kees
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, Apr 18, 2022 at 03:43:27PM -0700, Matthias Kaehlcke wrote:
> Hi Kees,
>
> On Mon, Apr 18, 2022 at 03:14:14PM -0700, Kees Cook wrote:
> > [oops, resending to actual CC list]
> >
> > On Mon, Apr 18, 2022 at 02:15:56PM -0700, Matthias Kaehlcke wrote:
> >
t's specifically about dm devices).
- have LoadPin grow a securityfs node, maybe something like
/sys/kernel/security/loadpin/dm-verify and do the ioctl there (seems
reasonable given that it's specifically about LoadPin, but is perhaps
more overhead to built the securityfs).
--
Kees Cook
n/loadpin.c | 184 ++-
>> 3 files changed, 218 insertions(+), 1 deletion(-)
>> create mode 100644 include/uapi/linux/loadpin.h
>
>I would certainly need some Reviewed-by:s from security and/or loadpin
>experts if I were to pick this patch up.
Alternatively, since it's mostly touching loadpin, I can carry it in my tree,
as long as you've Acked the dm bits. :)
>Did you see the issues the kernel test robot emailed about?
>
>You'd do well to fix those issues up when submitting another revision
>of this patchset.
Agreed.
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
nclude/linux/dm-verity-loadpin.h
>new file mode 100644
>index ..12a86911d05a
>--- /dev/null
>+++ b/include/linux/dm-verity-loadpin.h
>@@ -0,0 +1,27 @@
>+/* SPDX-License-Identifier: GPL-2.0 */
>+
>+#ifndef __LINUX_DM_VERITY_LOADPIN_H
>+#define __LINUX_DM_VERITY_
pr_err("LoadPin: could not create securityfs dir: %d\n",
>+ PTR_ERR(loadpin_dir));
>+ return PTR_ERR(loadpin_dir);
>+ }
>+
>+ dentry = securityfs_create_file("dm-verity", 0600, loadpin_dir,
>+ (void *)LOADPIN_DM_VERITY,
>&loadpin_dm_verity_ops);
>+ if (IS_ERR(dentry)) {
>+ pr_err("LoadPin: could not create securityfs entry 'dm-verity':
>%d\n",
>+ PTR_ERR(dentry));
>+ return PTR_ERR(dentry);
>+ }
>+
>+ return 0;
>+}
>+
>+fs_initcall(init_loadpin_securityfs);
>+
>+#endif /* CONFIG_SECURITY_LOADPIN_VERITY */
>+
> /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> module_param(enforce, int, 0);
> MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
Otherwise looks good! The only other thing I can think of is pondering more
about more carefully failing closed. E.g. instead of just throwing away all the
other hashes on a file load failure, maybe lock out future attempts to set it
too? I'm not sure this is actually useful, though. :P it shouldn't be possible
to corrupt the file, etc. But in the universe where things like DirtyCOW
happens, I've gotten even more paranoid. ;)
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Supporting that arrangement, though, may be overkill --
I would expect a 1:1 mapping as you suggest.
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, May 16, 2022 at 11:17:44AM -0700, Matthias Kaehlcke wrote:
> On Fri, May 13, 2022 at 03:36:26PM -0700, Kees Cook wrote:
> >
> >
> > On May 4, 2022 12:54:18 PM PDT, Matthias Kaehlcke wrote:
> > >Extend LoadPin to allow loading of kernel files from trus
get some
Acks from the dm folks, I can carry this with other loadpin changes in
my tree. Though I'm fine with this going via the dm tree, too:
Acked-by: Kees Cook
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
UAPI_DEF_METHOD_NEEDS_FN(create_cq)),
which must also be assuming it's a header. So probably better to just
drop the driver_data field? I don't see anything using it (that I can
find) besides as a sanity-check that the field exists and is at the end
of the struct.
--
Kees Cook
t; []
changes (when they are not erroneously being used within other
structures) is valid for all compilers. Flexible arrays are C99; it's
been 23 years. :)
But, yes, where we DO break stuff we need to workaround it, etc.
--
Kees Cook
; > verity device has a trusted root digest.
> >
> > [1]
> > https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/dlcservice/docs/developer.md
> > [2]
> > https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html
>
> Hi Kees,
>
> Please pick this series up, thanks.
Thanks for the Acks! I'll get this into -next shortly.
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
verity helpers for LoadPin
https://git.kernel.org/kees/c/b6c1c5745ccc
[2/3] LoadPin: Enable loading from trusted dm-verity devices
https://git.kernel.org/kees/c/3f805f8cc23b
[3/3] dm: verity-loadpin: Use CONFIG_SECURITY_LOADPIN_VERITY for conditional
compilation
https://git.ke
directly instead of using the defunct wrapper.
>
>
Applied to for-next/hardening, thanks!
[1/1] dm: verity-loadpin: Drop use of dm_table_get_num_targets()
https://git.kernel.org/kees/c/27603a606fda
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
, restarting the system or triggering a
> panic.
>
>
> [...]
Applied to for-next/hardening, thanks!
[1/1] dm: verity-loadpin: Only trust verity targets with enforcement
https://git.kernel.org/kees/c/2e1875c05267
--
Kees Cook
--
dm-devel mailing list
dm-devel@redhat.com
ht
On Thu, Sep 08, 2022 at 11:25:36AM -0400, Mike Snitzer wrote:
> On Wed, Sep 07 2022 at 6:34P -0400,
> Kees Cook wrote:
>
> > On Wed, 7 Sep 2022 13:30:58 -0700, Matthias Kaehlcke wrote:
> > > Verity targets can be configured to ignore corrupted data blocks.
> > &g
iterate over the stripes twice, once to emit their names, and the
> second time to emit status (i.e. trade memory for time). Since the number
> of stripes is probably low, this is hopefully not that expensive.
>
> Signed-off-by: Tycho Andersen
> CC: Alasdair Kergon
> CC: Mi
es" tag that Linus merged after the block changes:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
>>>> tags/for-4.17/dm-changes
>>>>
>>>> # ./check tests/generic/347
>>>> FSTYP -- ext4
>>
o finish all async __init code before freeing the memory */
async_synchronize_full();
--
Kees Cook
Pixel Security
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
: Kees Cook
---
drivers/md/dm-raid1.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index 580c49cc8079..5903e492bb34 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -23,6 +23,8 @@
#define MAX_RECOVERY 1
On Tue, Apr 10, 2018 at 9:43 PM, Kees Cook wrote:
> On the quest to remove all VLAs from the kernel[1], this avoids VLAs
> in dm-raid1.c by just using the maximum size for the stack arrays.
> The nr_mirrors value was already capped at 9, so this makes it a trivial
> adjustment to the
This adjusts the allocator calls to use the 2-factor argument style, as
already done treewide for better defense against allocator overflows.
Additionally adjusts style nit to avoid assignments in test expressions.
Signed-off-by: Kees Cook
---
drivers/md/dm-writecache.c | 16 ++--
1
On Mon, Jun 18, 2018 at 2:12 PM, Mikulas Patocka wrote:
>
>
> On Mon, 18 Jun 2018, Kees Cook wrote:
>
>> This adjusts the allocator calls to use the 2-factor argument style, as
>> already done treewide for better defense against allocator overflows.
>> Additiona
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new SHASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
bounds on stack usage.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
In the quest to remove all stack VLA usage from the kernel[1], this
uses the newly defined max digest size macro. Also adds a sanity-check
at use-time.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/md/dm
In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
crypto/xcbc.c | 5 -
1 file changed, 4
In the quest to remove all stack VLA usage from the kernel[1], this
caps the skcipher request size similar to other limits and adds a sanity
check at registration.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
crypto/shash.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index ab6902c6dae7..1bb58209330a 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -73,13
://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
crypto/algapi.c| 5 -
include/linux/crypto.h | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index c0755cf4f53f
In the quest to remove all stack VLA usage from the kernel[1], this
introduces max size macros for ahash, as already done for shash, and
adjust the crypto user to max state size.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees
pendent patches (new crypto #defines
being used).
Thanks!
-Kees
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Kees Cook (11):
crypto: shash: Remove VLA usage
dm integrity: Remove VLA usage
crypto: ahash: Remove VLA usage
dm verity
In the quest to remove all stack VLA usage from the kernel[1], this caps
the ahash request size similar to the other limits and adds a sanity
check at registration.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
was just exposing the existing max stack size, so there
is nothing new here; now that it is not hidden in a VLA, the compiler
can see how large it might get.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
include/crypto/cbc.h | 2 +-
1 file changed, 1 insertion(+), 1
://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
crypto/shash.c| 6 +++---
include/crypto/hash.h | 6 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index 5d732c6bb4b2..ab6902c6dae7
On Wed, Jun 20, 2018 at 12:30 PM, Christophe Leroy
wrote:
>
>
> On 06/20/2018 07:03 PM, Kees Cook wrote:
>>
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the VLAs in SHASH_DESC_ON_STACK (via crypto_shash_descsize())
>> by using
On Wed, Jun 20, 2018 at 12:44 PM, Arnd Bergmann wrote:
> On Wed, Jun 20, 2018 at 9:04 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> caps the skcipher request size similar to other limits and adds a sanity
>>
On Wed, Jun 20, 2018 at 1:39 PM, Christophe LEROY
wrote:
>
>
> Le 20/06/2018 à 22:36, Kees Cook a écrit :
>>
>> On Wed, Jun 20, 2018 at 12:30 PM, Christophe Leroy
>> wrote:
>>>
>>>
>>>
>>> On 06/20/2018 07:03 PM, Kees Cook wrote:
>
On Wed, Jun 20, 2018 at 4:33 PM, Eric Biggers wrote:
> On Wed, Jun 20, 2018 at 12:04:01PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> uses the newly defined max digest size macro. Also adds a sanity-check
>> at use-time
On Wed, Jun 20, 2018 at 4:40 PM, Eric Biggers wrote:
> On Wed, Jun 20, 2018 at 12:04:02PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> exposes the existing upper bound on crypto block sizes for VLA removal,
>> and intro
On Wed, Jun 20, 2018 at 4:46 PM, Eric Biggers wrote:
> On Wed, Jun 20, 2018 at 12:04:04PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this uses
>> the maximum blocksize and adds a sanity check.
>>
>> [1]
>> htt
On Wed, Jun 20, 2018 at 4:57 PM, Eric Biggers wrote:
> On Wed, Jun 20, 2018 at 12:04:06PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this uses
>> the newly defined max alignment to perform unaligned hashing to avoid
>> VLAs,
On Wed, Jun 20, 2018 at 7:30 PM, Herbert Xu wrote:
> On Wed, Jun 20, 2018 at 12:04:01PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> uses the newly defined max digest size macro. Also adds a sanity-check
>> at use-time
://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signed-off-by: Kees Cook
---
crypto/shash.c| 6 +++---
include/crypto/hash.h | 6 +-
2 files changed, 8 insertions(+), 4 deletion
...@mail.gmail.com
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signed-off-by: Kees Cook
---
include/crypto/internal/skcipher.h | 1 +
include/crypto/skcipher.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/crypto/internal/skc
kernel.org
Signed-off-by: Kees Cook
---
crypto/algapi.c | 7 ++-
include/crypto/algapi.h | 4 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index c0755cf4f53f..496fc51bf215 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -5
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signed-off-by: Kees Cook
---
include/crypto/cbc.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/crypto/cbc.h b/include/crypto/cbc.h
index f5b8bfc22e6d..47db0aac2ab9 100644
--- a/include/crypto/c
ches (new crypto #defines
being used).
Thanks!
-Kees
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Kees Cook (11):
crypto: xcbc: Remove VLA usage
crypto: cbc: Remove VLA usage
crypto: shash: Remove VLA usage
dm integrity: Remove VLA usag
1 - 100 of 250 matches
Mail list logo