On 2022-09-26 16:18:18, Jeff Moyer wrote:
> Tyler Hicks writes:
>
> > The alignment constraint for namespace creation in a region was
> > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> > commit 2522afb86a8c ("libnvdimm/region: Intro
On 2022-08-30 00:45:05, Tyler Hicks wrote:
> The alignment constraint for namespace creation in a region was
> increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> commit 2522afb86a8c ("libnvdimm/region: Introduce an 'align'
> attribute"). The tho
te not being aligned to 16M.
Link:
https://lore.kernel.org/lkml/CA+CK2bDJ3hrWoE91L2wpAk+Yu0_=GtYw=4glddd7mxs321b...@mail.gmail.com
Fixes: 2522afb86a8c ("libnvdimm/region: Introduce an 'align' attribute")
Signed-off-by: Tyler Hicks
---
While testing with a recent kernel release (6.0
On 2021-02-26 15:00:23, Jeffrey Mitchell wrote:
> When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount()
> causes a kernel panic if the parsed options are valid. The easiest way to
> reproduce this is to call mount() from userspace with an existing
> eCryptfs mount's options and a
On 2021-03-30 17:44:27, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There is more to do in filesystems. Another set will follow.
>
> Lee Jones (31):
...
> fs:
On 2021-02-24 12:30:59, Sascha Hauer wrote:
> ecryptfs_decrypt_page() issues a warning "Error encrypting extent". This
> should be "Error decrypting extent" instead.
>
> Signed-off-by: Sascha Hauer
Thanks! This looks good. I'll add the following fixes line while
applying:
Fixes: 0216f7f79217
On 2021-03-20 13:45:51, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for kernel-doc comments.
> There are files in fs/encrypts which follows this syntax, but the content
> inside does not comply with kernel-doc.
> This causes unexpected warnings from kernel-doc.
>
> E.g.,
for ecryptfs_mount() instead
> fs/ecryptfs/main.c:645: warning: Function parameter or member 'vptr' not
> described in 'inode_info_init_once'
>
> Cc: Tyler Hicks
> Cc: Christian Brauner
> Cc: James Morris
> Cc: "Michael A. Halcrow"
> Cc: "Michael C. Thompson&q
arameter or member 'sb' not
> described in 'ecryptfs_decode_and_decrypt_filename'
> fs/ecryptfs/crypto.c:2006: warning: Excess function parameter
> 'ecryptfs_dir_dentry' description in 'ecryptfs_decode_and_decrypt_filename'
>
> Cc: Tyler Hicks
> Cc: Eric Biggers
> Cc:
On 2020-09-10 13:46:27, Bjorn Helgaas wrote:
> On Thu, Sep 10, 2020 at 08:21:06AM -0600, Rob Herring wrote:
> > On Wed, Sep 9, 2020 at 8:07 PM Bjorn Helgaas wrote:
> > >
> > > [+cc Mark, Florian, Rob, Scott]
> > >
> > > On Sat, Aug 01, 2020 at 09:25:49AM +0800, Xingxing Su wrote:
> > > > Do not
On 2021-03-30 16:32:10, Aneesh Kumar K.V wrote:
> Tyler Hicks writes:
>
> > The alignment constraint for namespace creation in a region was
> > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> > commit 2522afb86a8c ("libnvdimm/region: Intro
te not being aligned to 16M.
Fixes: 2522afb86a8c ("libnvdimm/region: Introduce an 'align' attribute")
Signed-off-by: Tyler Hicks
---
drivers/nvdimm/region_devs.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/nvdimm/
by accident, but other platforms update this value properly.
> So, fix it in ARM64 version of elfcorehdr_read() as well.
>
Fixes: e62aaeac426a ("arm64: kdump: provide /proc/vmcore file")
Reviewed-by: Tyler Hicks
Tyler
> Signed-off-by: Pavel Tatashin
> ---
> arch/arm64
70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Kees Cook
> Reviewed-by: Petr Mladek
> Reviewed-by: Bhupesh Sharma
Reviewed-by: Tyler Hicks
Tyler
> Acked-by: Baoquan He
> -
igned-off-by: Allen Pais
Reviewed-by: Tyler Hicks
Tyler
> ---
> drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c
> b/drivers/firmware/broadcom/tee_bnxt_fw.c
> index ed10da5313e8.
e_remove(struct platform_device *pdev)
> return 0;
> }
>
> +/* optee_shutdown - Device Removal Routine
> + * @pdev: platform device information struct
> + *
> + * platform_shutdown is called by the platform subsystem to alter
I cannot explain why '5.10.19 + these fixes' shows improvements over
5.4.88 for two of the three services but I suspect it is due to systemd
taking different code paths, units executing at different times,
unrelated kernel performance improvements, etc.
For all three patches,
Tested-by: Tyler Hicks
On 2021-02-25 17:38:25, Ondrej Mosnacek wrote:
> On Wed, Feb 24, 2021 at 3:43 PM Tyler Hicks
> wrote:
> > On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> > > On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> > > wrote:
> > > > On 2021-02-23 15:50:56, Tyl
On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> wrote:
> > On 2021-02-23 15:50:56, Tyler Hicks wrote:
> > > On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > > > I'm seeing a race during policy load while the &q
On 2021-02-23 15:50:56, Tyler Hicks wrote:
> On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > I'm seeing a race during policy load while the "regular" sidtab
> > conversion is happening and a live conversion starts to take place in
> > sidtab_context_to_sid().
>
On 2021-02-23 15:43:48, Tyler Hicks wrote:
> I'm seeing a race during policy load while the "regular" sidtab
> conversion is happening and a live conversion starts to take place in
> sidtab_context_to_sid().
>
> We have an initial policy that's loaded by systemd ~0.6s int
I'm seeing a race during policy load while the "regular" sidtab
conversion is happening and a live conversion starts to take place in
sidtab_context_to_sid().
We have an initial policy that's loaded by systemd ~0.6s into boot and
then another policy gets loaded ~2-3s into boot. That second policy
-by: Pavel Tatashin
> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear
> mapping")
Tested-by: Tyler Hicks
This fixes a memory hot plugging bug that I was seeing on 5.10, with the
introduction of 58284a901b42.
One comment below...
> ---
>
On 2021-02-05 12:01:55, Tyler Hicks wrote:
> On 2020-10-30 09:00:35, Mark Salyzyn wrote:
> > On 10/30/20 8:07 AM, Miklos Szeredi wrote:
> > > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn wrote:
> > > > Because of the overlayfs getxattr recursion, the incoming
On 2020-10-30 09:00:35, Mark Salyzyn wrote:
> On 10/30/20 8:07 AM, Miklos Szeredi wrote:
> > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn wrote:
> > > Because of the overlayfs getxattr recursion, the incoming inode fails
> > > to update the selinux sid resulting in avc denials being reported
> >
On 2020-12-24 21:22:33, Zheng Yongjun wrote:
> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
>
> Signed-off-by: Zheng Yongjun
This looks good to me. I've pushed the patch to the eCryptfs next
branch:
On 2020-11-27 10:11:23, Joe Perches wrote:
> On Fri, 2020-11-27 at 08:05 -0800, t...@redhat.com wrote:
> > Function like macros should have a semicolon.
> []
> > diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> []
> > @@ -1172,7 +1172,7 @@ decrypt_pki_encrypted_session_key(struct
>
On 2020-12-18 13:07:30, Jeffrey Mitchell wrote:
> On asynchronous base filesystems like NFS, eCryptFS leaves inodes for
> deleted files in the cache until unmounting. Change call in
> ecryptfs_do_unlink() from set_nlink() to drop_nlink() in order to reliably
> evict inodes from the cache even on
Hi Linus,
The following changes since commit 83d09ad4b950651a95d37697f1493c00d888d0db:
Merge tag 'for-linus' of git://github.com/openrisc/linux (2021-01-21 18:35:02
-0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git
On 2021-01-25 19:21:22, Pavel Tatashin wrote:
> I forgot to make changes to arch/arm64/Kconfig. The correct patch is
> below.
>
> ---
>
> From a2bc374320d7c7efd3c40644ad3d6d59a024b301 Mon Sep 17 00:00:00 2001
> From: Pavel Tatashin
> Date: Mon, 29 Jul 2019 21:24:25 -0400
> Subject: [PATCH v10
On 2021-01-25 14:25:38, Miklos Szeredi wrote:
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()&
; setups, but it does make sure existing setups don't regress.
>
> Reported-by: Eric W. Biederman
> Cc: Tyler Hicks
> Fixes: 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into vfs_setxattr()")
> Signed-off-by: Miklos Szeredi
> ---
> fs/ecryptfs/inode.c | 10
On 2021-01-20 08:52:27, Miklos Szeredi wrote:
> On Tue, Jan 19, 2021 at 10:11 PM Eric W. Biederman
> wrote:
> >
> > Miklos Szeredi writes:
> >
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take stacked
function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/kexec.h | 5 +
> kernel/kexec_file.c
ed resulting in memory leak.
>
> Free the memory allocated for the IMA measurement list in
> the error code paths in ima_add_kexec_buffer() function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot,
tail -1 |
> > cut -d' ' -f 6
> >
> > Note that the actual verification of SELinux policy would require loading
> > the expected policy into an identical kernel on a pristine/known-safe
> > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > th
On 2020-12-14 10:42:24, Tyler Hicks wrote:
> On 2020-12-11 06:01:54, Mimi Zohar wrote:
> > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > > Hi Sasha,
> > > >
> > > > On Wed, 2020-07-
On 2020-12-11 06:01:54, Mimi Zohar wrote:
> On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > Hi Sasha,
> > >
> > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > > > On Wed, Ju
unc CRITICAL_DATA, the data from all the
> supported kernel subsystems is measured.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 ++
> security/integrity/ima/ima_policy.c | 37 +
Tushar Sugandhi
This looks nice. Thanks for the changes!
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 +-
> security/integrity/ima/ima_policy.c | 29
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> dif
On 2020-12-11 17:17:22, Tushar Sugandhi wrote:
>
>
> On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
> > On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> > > A new IMA policy rule is needed for the IMA hook
> > > ima_measure_critical_data() and the
e actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggest
On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows
l
> integrity critical data.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 6 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_api.c | 2 +-
> security/integrity/ima/i
er to extend them without code duplication.
>
> Refactor the keyring specific measurement constructs to be generic and
> reusable in other measurement scenarios.
>
> Signed-off-by: Tushar Sugandhi
> Reviewed-by: Tyler Hicks
This looks good to me. Thanks!
Tyler
> --
buffer, which would be much smaller, instead of the buffer
> itself.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> security/integrity/ima/ima.h | 3 +-
> security/integrity/ima/ima_appraise.c| 2 +-
> security/int
On 2020-12-11 09:36:30, Tyler Hicks wrote:
> The calls to pr_err() in this aren't quite following the style of the
> other error SELinux error messages.
Sorry, I left out a word. I meant to say that the calls to pr_err() in
this *file* aren't quite following the right style. Please adju
On 2020-12-09 11:42:12, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian
>
> IMA measures files and buffer data such as keys, command line arguments
> passed to the kernel on kexec system call, etc. While these measurements
> enable monitoring and validating the integrity of the system, it
On 2020-11-29 08:17:38, Mimi Zohar wrote:
> Hi Sasha,
>
> On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote:
> > >Hi Sasha,
> > >
> > >On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote:
> > >> From: Maurizio Drocco
> > >>
> >
On 2020-12-10 17:21:19, Tushar Sugandhi wrote:
>
>
> On 2020-12-10 2:38 p.m., Tyler Hicks wrote:
> > On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> > > The original IMA buffer data measurement sizes were small (e.g. boot
> > > command line), but the new buffe
e kernel command line
> contains "ima_policy=critical_data".
>
> Update the documentation on kernel parameters to document
> the new critical data builtin policy.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/a
xtend the IMA hook ima_measure_critical_data() to support passing
> the data source label as an input parameter, so that the policy rule can
> be used to limit the measurements based on the label.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> in
On 2020-12-09 11:42:09, Tushar Sugandhi wrote:
> System administrators should be able to limit which kernel subsystems
> they want to measure the critical data for. To enable that, an IMA policy
> condition to choose specific kernel subsystems is needed. This policy
> condition would constrain the
On 2020-12-09 11:42:08, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows
On 2020-12-09 11:42:07, Tushar Sugandhi wrote:
> IMA provides capabilities to measure file data, and in-memory buffer
> data. However, various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity
nt patch is fine:
Reviewed-by: Tyler Hicks
> ---
> security/integrity/ima/ima.h| 6 ++--
> security/integrity/ima/ima_api.c| 6 ++--
> security/integrity/ima/ima_main.c | 6 ++--
> security/integrity/ima/ima_policy.c | 49 ++---
> 4
On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> The original IMA buffer data measurement sizes were small (e.g. boot
> command line), but the new buffer data measurement use cases have data
> sizes that are a lot larger. Just as IMA measures the file data hash,
> not the file data, IMA should
be changed to this:
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
If you agree, please adjust and resubmit with:
Reviewed-by: Tyler Hicks
Thank you!
Tyler
> Signed-off-by: Jann Horn
> ---
> kernel/seccomp.c | 4 ++--
> 1 file changed, 2 i
On 2020-11-05 09:28:38, Tyler Hicks wrote:
> On 2020-11-05 09:58:54, Will Deacon wrote:
> > On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wro
On 2020-11-05 09:58:54, Will Deacon wrote:
> On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > On 2020-09-21 14:15:55, Tyler
On 2020-11-04 12:08:12, Will Deacon wrote:
> On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> > > config option can be used to ext
On 2020-09-21 14:15:55, Tyler Hicks wrote:
> Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> config option can be used to extend the kernel command line parameters,
> specified by the bootloader, with additional command line parameters
> specified i
/linux-integrity/e1fdcccb-ca51-4aee-ac83-9cde995ea...@canonical.com/
Reported-by: Kai-Heng Feng
Reported-by: Kenneth R. Crudup
Reported-by: Mimi Zohar
Cc: Thiébaud Weksteen
Cc: Ard Biesheuvel
Signed-off-by: Tyler Hicks
---
drivers/char/tpm/eventlog/efi.c | 5 +
1 file changed, 5 insertions
On 2020-10-28 10:41:02, Tyler Hicks wrote:
> Mimic the pre-existing ACPI and Device Tree event log behavior by not
> creating the binary_bios_measurements file when the EFI TPM event log is
> empty.
>
> This fixes the following NULL pointer dereference that can occur when
> r
On 2020-10-28 11:30:11, Tyler Hicks wrote:
> So, we need help from Kai, Kenneth, or Mimi to verify my assumption that
> their firmware is providing an empty main event log and a populated
> final event log.
Hi Kai, Kenneth, and Mimi - could one or two of you please follow these
steps:
On 2020-10-26 13:49:59, Kai-Heng Feng wrote:
>
>
> > On Oct 21, 2020, at 13:48, Tyler Hicks wrote:
> >
> > On 2020-10-20 17:07:50, Mimi Zohar wrote:
> >> On Tue, 2020-09-29 at 13:52 -0400, Mimi Zohar wrote:
> >>> On Mon, 2020-09-28 at 22:16
On 2020-10-20 17:07:50, Mimi Zohar wrote:
> On Tue, 2020-09-29 at 13:52 -0400, Mimi Zohar wrote:
> > On Mon, 2020-09-28 at 22:16 +0800, Kai-Heng Feng wrote:
> > > Hi Jarkko,
> > >
> > > > On Sep 28, 2020, at 22:06, Jarkko Sakkinen
> > > > wrote:
> > > >
> > > > On Mon, Sep 28, 2020 at
Sorry for coming in so late, I've been on an extended vacation with
little connectivity.
On 2020-10-09 19:06:54, Jarkko Sakkinen wrote:
> On Thu, Oct 08, 2020 at 05:09:06PM +0800, Kai-Heng Feng wrote:
> > > I do not have yet any reasonable answer to this and my v5.10 PR is
> > > running late.
rings without
having to concatenate the strings in early init.
Signed-off-by: Tyler Hicks
---
arch/arm64/kernel/kaslr.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b181e0544b79..4c779a67c2a6 100644
---
and development kernel versions, where one
of the versions benefits from additional command line parameters,
such as debugging options.
2) Specifying additional command line parameters, for additional tuning
or debugging, when the bootloader does not offer an interactive mode.
Signed-off-by: Tyler
NE="nokaslr apparmor=0" and CONFIG_CMDLINE_FORCE=y
- The CONFIG_CMDLINE value is used and does not contain the
bootloader's command line
- AppArmor and KASLR are disabled
Tyler
Tyler Hicks (2):
arm64: kaslr: Refactor early init command line parsing
arm64: Extend the kernel comma
On 2020-08-24 14:44:55, Mimi Zohar wrote:
> Hi Tyler,
>
> On Tue, 2020-08-11 at 14:26 -0500, Tyler Hicks wrote:
> > v2:
> > - Always return an ERR_PTR from ima_alloc_rule_opt_list() (Nayna)
> > - Add Lakshmi's Reviewed-by to both patches
> > - Rebased on commit
authors don't assume that
these policy language constructs are supported.
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Suggested-by: Nayna Jain
Signed-off-by: Tyler Hicks
Reviewed-by
rsed at this time) and using "|" as an alternation delimiter is
becoming the norm in IMA policy.
This series is based on commit 311aa6aafea4 ("ima: move
APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime") in
next-integrity.
Tyler
Tyler Hicks (2):
ima: Pre-parse the l
rings was longer than what could
fit in the fixed size tbuf buffer in ima_policy_show().
Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks
Reviewed-by: Laksh
On 2020-08-06 11:34:43, Nayna wrote:
>
> On 7/27/20 10:08 AM, Tyler Hicks wrote:
> > The ima_keyrings buffer was used as a work buffer for strsep()-based
> > parsing of the "keyrings=" option of an IMA policy rule. This parsing
> > was re-performed eac
On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> > > On 8/4/2020 6:14 PM, Lakshmi Ramasubramanian wrote:
> > > > On 8/4/20 6:04 PM, Casey Schaufler wrote:
> >
On 2020-08-05 09:21:24, Lakshmi Ramasubramanian wrote:
> On 8/5/20 9:14 AM, Tyler Hicks wrote:
> > On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> > > On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > > > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> >
On 2020-08-05 10:27:43, Stephen Smalley wrote:
> On Wed, Aug 5, 2020 at 9:20 AM Mimi Zohar wrote:
> >
> > On Wed, 2020-08-05 at 09:03 -0400, Stephen Smalley wrote:
> > > On Wed, Aug 5, 2020 at 8:57 AM Mimi Zohar wrote:
> > > > On Wed, 2020-08-05 at 08:46 -0400, Stephen Smalley wrote:
> > > > >
On 2020-08-05 08:36:40, Casey Schaufler wrote:
> On 8/4/2020 6:14 PM, Lakshmi Ramasubramanian wrote:
> > On 8/4/20 6:04 PM, Casey Schaufler wrote:
> >> On 8/4/2020 5:43 PM, Lakshmi Ramasubramanian wrote:
> >>> Critical data structures of security modules are currently not measured.
> >>> Therefore
On 2020-07-30 11:02:50, Lakshmi Ramasubramanian wrote:
> On 7/29/20 8:47 PM, Lakshmi Ramasubramanian wrote:
>
> Hi Tyler,
>
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 080c53545ff0..86cba844f73c 100644
> > --- a/security/integrity/ima/Kconfig
> >
On 2020-07-30 08:15:34, Lakshmi Ramasubramanian wrote:
> On 7/30/20 8:02 AM, Tyler Hicks wrote:
>
> > > diff --git a/security/integrity/ima/ima_policy.c
> > > b/security/integrity/ima/ima_policy.c
> > > index 07f033634b27..a0f5c39d9084 100644
> > >
to measure LSM state and LSM policy
> respectively. Return the status of the measurement operation from these
> two IMA hooks.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 14 +
> se
On 2020-07-29 20:47:21, Lakshmi Ramasubramanian wrote:
> Critical data structures of security modules need to be measured to
> enable an attestation service to verify if the configuration and
> policies for the security modules have been setup correctly and
> that they haven't been tampered with
authors don't assume that
these policy language constructs are supported.
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Suggested-by: Nayna Jain
Signed-off-by: Tyler Hicks
---
security/
uot;|" as an alternation delimiter is
becoming the norm in IMA policy.
This series is based on commit 311aa6aafea4 ("ima: move
APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime") in
next-integrity.
Tyler
Tyler Hicks (2):
ima: Pre-parse the list of keyrings in a KEY_CHE
rings was longer than what could
fit in the fixed size tbuf buffer in ima_policy_show().
Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks
---
security/in
uct loop_device. Keep loop_ctl_mutex to protect global
> data such as loop_index_idr, loop_lookup, loop_add.
>
> Lock ordering: loop_ctl_mutex > lo_mutex.
>
> Signed-off-by: Pavel Tatashin
Thanks for the revision.
Reviewed-by: Tyler Hicks
Ty
On 2020-07-23 14:29:31, Pavel Tatashin wrote:
> Hi Tyler,
>
> Thank you for the review comments. My replies are inlined below.
>
> > > Scale it by introducing per-device lock: lo_mutex that proctests
> > > field in struct loop_device. Keep loop_ctl_mutex to protect global
> >
> > s/proctests
On 2020-07-17 16:53:22, Pavel Tatashin wrote:
> Currently, loop device has only one global lock:
> loop_ctl_mutex.
>
> This becomes hot in scenarios where many loop devices are used.
>
> Scale it by introducing per-device lock: lo_mutex that proctests
> field in struct loop_device. Keep
On 2020-07-17 14:19:03, Tyler Hicks wrote:
> On 2020-07-17 14:56:46, Nayna wrote:
> >
> > On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > > The KEY_CHECK function only supports the uid, pcr, and keyrings
> > > conditionals. Make this clear at policy load so that IMA
On 2020-07-17 15:20:22, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > Ask the LSM to free its audit rule rather than directly calling kfree().
>
> Is it to be called audit rule or filter rule ? Likewise in subject line.
The security hooks call this "audit r
On 2020-07-17 14:56:46, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > The KEY_CHECK function only supports the uid, pcr, and keyrings
> > conditionals. Make this clear at policy load so that IMA policy authors
> > don't assume that other conditionals are s
On 2020-07-17 13:40:22, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > The "appraise_flag" option is only appropriate for appraise actions
> > and its "blacklist" value is only appropriate when
> > CONFIG_IMA_APPRAISE_MODSIG is enabl
On 2020-07-17 18:35:03, Konsta Karsisto wrote:
> Hi,
>
> Found one glitch with this change, see below:
>
> On Thu, Jul 9, 2020 at 9:22 AM Tyler Hicks
> wrote:
> >
> > The args_p member is a simple string that is allocated by
> > ima_rule_init(). Shallow c
On 2020-07-17 00:31:33, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> > This series ultimately extends the supported IMA rule conditionals for
> > the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> > IMA languag
On 2020-07-16 14:14:50, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:19 -0500, Tyler Hicks wrote:
> > The "appraise_flag" option is only appropriate for appraise actions
> > and its "blacklist" value is only appropriate when
> > CONFIG_IMA_APPRAISE_MODSI
On 2020-04-15 09:25:41, deven.de...@linux.microsoft.com wrote:
> From: Deven Bowers
>
> Adds the policy parser and the policy loading to IPE, along with the
> related sysfs, securityfs entries, and audit events.
>
> Signed-off-by: Deven Bowers
> ---
...
> diff --git
On 2020-07-13 23:57:19, Jarkko Sakkinen wrote:
> On Fri, Jul 10, 2020 at 02:29:55PM -0500, Tyler Hicks wrote:
> > Require that the TCG_PCR_EVENT2.digests.count value strictly matches the
> > value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of the
> > TCG_PCCli
Rename IMA's internal audit rule functions from security_filter_rule_*()
to ima_filter_rule_*(). This avoids polluting the security_* namespace,
which is typically reserved for general security subsystem
infrastructure.
Signed-off-by: Tyler Hicks
Suggested-by: Casey Schaufler
---
* v2
1 - 100 of 557 matches
Mail list logo
