On Thu, May 19, 2022 at 12:08:26PM +0900, Damien Le Moal wrote:
> On 5/18/22 00:34, Theodore Ts'o wrote:
> > On Tue, May 17, 2022 at 10:10:48AM +0200, Christoph Hellwig wrote:
> >> I'm a little surprised about all this activity.
> >>
> >> I though the conclusion at LSF/MM was that for Linux itself
The verity glue for LoadPin is only needed when CONFIG_SECURITY_LOADPIN_VERITY
is set, use this option for conditional compilation instead of the combo of
CONFIG_DM_VERITY and CONFIG_SECURITY_LOADPIN.
Signed-off-by: Matthias Kaehlcke
Acked-by: Kees Cook
---
Changes in v5:
- added 'Acked-by' tag
Extend LoadPin to allow loading of kernel files from trusted dm-verity [1]
devices.
This change adds the concept of trusted verity devices to LoadPin. LoadPin
maintains a list of root digests of verity devices it considers trusted.
Userspace can populate this list through an ioctl on the new LoadP
LoadPin limits loading of kernel modules, firmware and certain
other files to a 'pinned' file system (typically a read-only
rootfs). To provide more flexibility LoadPin is being extended
to also allow loading these files from trusted dm-verity
devices. For that purpose LoadPin can be provided with
As of now LoadPin restricts loading of kernel files to a single pinned
filesystem, typically the rootfs. This works for many systems, however it
can result in a bloated rootfs (and OTA updates) on platforms where
multiple boards with different hardware configurations use the same rootfs
image. Espe
On Tue, May 17, 2022 at 11:34:54AM -0400, Theodore Ts'o wrote:
> On Tue, May 17, 2022 at 10:10:48AM +0200, Christoph Hellwig wrote:
> > I'm a little surprised about all this activity.
> >
> > I though the conclusion at LSF/MM was that for Linux itself there
> > is very little benefit in supporting
On Wed, May 18, 2022 at 03:52:21PM -0400, Mike Snitzer wrote:
> On Tue, May 17 2022 at 7:34P -0400,
> Matthias Kaehlcke wrote:
>
> > LoadPin limits loading of kernel modules, firmware and certain
> > other files to a 'pinned' file system (typically a read-only
> > rootfs). To provide more flexib
On Wed, May 18, 2022 at 04:03:44PM -0400, Mike Snitzer wrote:
> On Wed, May 18 2022 at 11:13P -0400,
> Matthias Kaehlcke wrote:
>
> > Hi Milan,
> >
> > On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote:
> > > On 18/05/2022 01:34, Matthias Kaehlcke wrote:
> > > > LoadPin limits loading o
On Wed, May 18 2022 at 11:13P -0400,
Matthias Kaehlcke wrote:
> Hi Milan,
>
> On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote:
> > On 18/05/2022 01:34, Matthias Kaehlcke wrote:
> > > LoadPin limits loading of kernel modules, firmware and certain
> > > other files to a 'pinned' file sy
On Tue, May 17 2022 at 7:34P -0400,
Matthias Kaehlcke wrote:
> LoadPin limits loading of kernel modules, firmware and certain
> other files to a 'pinned' file system (typically a read-only
> rootfs). To provide more flexibility LoadPin is being extended
> to also allow loading these files from t
On Wed, May 18 2022 at 3:23P -0400,
Kees Cook wrote:
> On Tue, May 17, 2022 at 04:34:54PM -0700, Matthias Kaehlcke wrote:
> > As of now LoadPin restricts loading of kernel files to a single pinned
> > filesystem, typically the rootfs. This works for many systems, however it
> > can result in a b
On Tue, May 17, 2022 at 04:34:54PM -0700, Matthias Kaehlcke wrote:
> As of now LoadPin restricts loading of kernel files to a single pinned
> filesystem, typically the rootfs. This works for many systems, however it
> can result in a bloated rootfs (and OTA updates) on platforms where
> multiple bo
Hi Milan,
On Wed, May 18, 2022 at 09:57:43AM +0200, Milan Broz wrote:
> On 18/05/2022 01:34, Matthias Kaehlcke wrote:
> > LoadPin limits loading of kernel modules, firmware and certain
> > other files to a 'pinned' file system (typically a read-only
> > rootfs). To provide more flexibility LoadPin
kp/linux/commits/Matthias-Kaehlcke/LoadPin-Enable-loading-from-trusted-dm-verity-devices/20220518-073635
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> for-next
> config: m68k-allmodconfig
> (https://download.01.org/0day-ci/archive/20220
when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Matthias-Kaehlcke/LoadPin-Enable-loading-from-trusted-dm-verity-devices/20220518-073635
base:
https://git.kernel.org/pub
On Wed, May 18, 2022 at 11:40:22AM +0200, Pankaj Raghav wrote:
> On 2022-05-17 14:30, David Sterba wrote:
> > On Mon, May 16, 2022 at 06:54:10PM +0200, Pankaj Raghav wrote:
> >> @@ -1108,14 +1101,14 @@ int btrfs_reset_device_zone(struct btrfs_device
> >> *device, u64 physical,
> >> int btrfs_ensu
On 2022-05-17 14:30, David Sterba wrote:
> On Mon, May 16, 2022 at 06:54:10PM +0200, Pankaj Raghav wrote:
>> Add helpers to calculate alignment, round up and round down
>> for zoned devices. These helpers encapsulates the necessary handling for
>> power_of_2 and non-power_of_2 zone sizes. Optimized
On 2022-05-17 14:42, David Sterba wrote:
> On Mon, May 16, 2022 at 06:54:11PM +0200, Pankaj Raghav wrote:
>> Superblocks for zoned devices are fixed as 2 zones at 0, 512GB and 4TB.
>> These are fixed at these locations so that recovery tools can reliably
>> retrieve the superblocks even if one of t
note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Matthias-Kaehlcke/LoadPin-Enable-loading-from-trusted-dm-verity-devices/20220518-073635
base:
https://git.kern
On Tue, May 17, 2022 at 11:18:34AM +0200, Javier González wrote:
> Does the above help you reconsidering your interest in supporting this
> in NVMe?
Very little. It just seems like a really bad idea.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-deve
On 18/05/2022 01:34, Matthias Kaehlcke wrote:
LoadPin limits loading of kernel modules, firmware and certain
other files to a 'pinned' file system (typically a read-only
rootfs). To provide more flexibility LoadPin is being extended
to also allow loading these files from trusted dm-verity
devices
On 17.05.2022 10:10, Christoph Hellwig wrote:
I'm a little surprised about all this activity.
I though the conclusion at LSF/MM was that for Linux itself there
is very little benefit in supporting this scheme. It will massively
fragment the supported based of devices and applications, while onl
Hi Kirill,
I saw your "[PATCH 0/4] dm: Introduce dm-qcow2 driver to attach QCOW2
files as block device" patch series:
https://lore.kernel.org/linux-kernel/ykme5zs2cpxun...@infradead.org/T/
There has been recent work in vDPA (VIRTIO Data Path Acceleration) to
achieve similar functionality. The qemu
23 matches
Mail list logo
