| Message ID | 20200504203829.6330-1-prsriva@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for using reserved memory for ima buffer pass | expand |
Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: > IMA during kexec(kexec file load) verifies the kernel signature and measures > the signature of the kernel. The signature in the logs can be used to verfiy the > authenticity of the kernel. The logs don not get carried over kexec and thus > remote attesation cannot verify the signature of the running kernel. > > Introduce an ABI to carry forward the ima logs over kexec. > Memory reserved via device tree reservation can be used to store and read > via the of_* functions. This flow needs to work for: 1) Pure DT 2) DT + EFI memory map 3) ACPI + EFI memory map ... and if this is just for transiently passing the log, I don't think that a reserved memory region is the right thing to use, since they're supposed to be more permanent. This sounds analogous to passing the initrd, and should probably use properties under the chosen node (which can be used for all three boot flows above). For reference, how big is the IMA log likely to be? Does it need physically contiguous space? Thanks, Mark. > > Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting > address, followed by the IMA log contents. > > Tested on: > arm64 with Uboot > > Prakhar Srivastava (2): > Add a layer of abstraction to use the memory reserved by device tree > for ima buffer pass. > Add support for ima buffer pass using reserved memory for arm64 kexec. > Update the arch sepcific code path in kexec file load to store the > ima buffer in the reserved memory. The same reserved memory is read > on kexec or cold boot. > > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/ima.h | 22 ++++ > arch/arm64/include/asm/kexec.h | 5 + > arch/arm64/kernel/Makefile | 1 + > arch/arm64/kernel/ima_kexec.c | 64 ++++++++++ > arch/arm64/kernel/machine_kexec_file.c | 1 + > arch/powerpc/include/asm/ima.h | 3 +- > arch/powerpc/kexec/ima.c | 14 ++- > drivers/of/Kconfig | 6 + > drivers/of/Makefile | 1 + > drivers/of/of_ima.c | 165 +++++++++++++++++++++++++ > include/linux/of.h | 34 +++++ > security/integrity/ima/ima_kexec.c | 15 ++- > 13 files changed, 325 insertions(+), 7 deletions(-) > create mode 100644 arch/arm64/include/asm/ima.h > create mode 100644 arch/arm64/kernel/ima_kexec.c > create mode 100644 drivers/of/of_ima.c > > -- > 2.25.1 >
Hi Mark, This patch set currently only address the Pure DT implementation. EFI and ACPI implementations will be posted in subsequent patchsets. The logs are intended to be carried over the kexec and once read the logs are no longer needed and in prior conversation with James( https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/) the apporach of using a chosen node doesn't support the case. The DT entries make the reservation permanent and thus doesnt need kernel segments to be used for this, however using a chosen-node with reserved memory only changes the node information but memory still is reserved via reserved-memory section. On 5/5/20 2:59 AM, Mark Rutland wrote: > Hi Prakhar, > > On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: >> IMA during kexec(kexec file load) verifies the kernel signature and measures >> the signature of the kernel. The signature in the logs can be used to verfiy the >> authenticity of the kernel. The logs don not get carried over kexec and thus >> remote attesation cannot verify the signature of the running kernel. >> >> Introduce an ABI to carry forward the ima logs over kexec. >> Memory reserved via device tree reservation can be used to store and read >> via the of_* functions. > > This flow needs to work for: > > 1) Pure DT > 2) DT + EFI memory map > 3) ACPI + EFI memory map > > ... and if this is just for transiently passing the log, I don't think > that a reserved memory region is the right thing to use, since they're > supposed to be more permanent. > > This sounds analogous to passing the initrd, and should probably use > properties under the chosen node (which can be used for all three boot > flows above). > > For reference, how big is the IMA log likely to be? Does it need > physically contiguous space? It purely depends on the policy used and the modules/files that are accessed for my local testing over a kexec session the log in about 30KB. Current implementation expects enough contiguous memory to allocated to carry forward the logs. If the log size exceeds the reserved memory the call will fail. Thanks, Prakhar Srivastava > > Thanks, > Mark. > >> >> Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting >> address, followed by the IMA log contents. >> >> Tested on: >> arm64 with Uboot >> >> Prakhar Srivastava (2): >> Add a layer of abstraction to use the memory reserved by device tree >> for ima buffer pass. >> Add support for ima buffer pass using reserved memory for arm64 kexec. >> Update the arch sepcific code path in kexec file load to store the >> ima buffer in the reserved memory. The same reserved memory is read >> on kexec or cold boot. >> >> arch/arm64/Kconfig | 1 + >> arch/arm64/include/asm/ima.h | 22 ++++ >> arch/arm64/include/asm/kexec.h | 5 + >> arch/arm64/kernel/Makefile | 1 + >> arch/arm64/kernel/ima_kexec.c | 64 ++++++++++ >> arch/arm64/kernel/machine_kexec_file.c | 1 + >> arch/powerpc/include/asm/ima.h | 3 +- >> arch/powerpc/kexec/ima.c | 14 ++- >> drivers/of/Kconfig | 6 + >> drivers/of/Makefile | 1 + >> drivers/of/of_ima.c | 165 +++++++++++++++++++++++++ >> include/linux/of.h | 34 +++++ >> security/integrity/ima/ima_kexec.c | 15 ++- >> 13 files changed, 325 insertions(+), 7 deletions(-) >> create mode 100644 arch/arm64/include/asm/ima.h >> create mode 100644 arch/arm64/kernel/ima_kexec.c >> create mode 100644 drivers/of/of_ima.c >> >> -- >> 2.25.1 >>
On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: > Hi Mark, Please don't top post. > This patch set currently only address the Pure DT implementation. > EFI and ACPI implementations will be posted in subsequent patchsets. > > The logs are intended to be carried over the kexec and once read the > logs are no longer needed and in prior conversation with James( > https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/) > the apporach of using a chosen node doesn't > support the case. > > The DT entries make the reservation permanent and thus doesnt need kernel > segments to be used for this, however using a chosen-node with > reserved memory only changes the node information but memory still is > reserved via reserved-memory section. I think Mark's point was whether it needs to be permanent. We don't hardcode the initrd address for example. > On 5/5/20 2:59 AM, Mark Rutland wrote: > > Hi Prakhar, > > > > On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: > > > IMA during kexec(kexec file load) verifies the kernel signature and measures What's IMA? > > > the signature of the kernel. The signature in the logs can be used to verfiy the > > > authenticity of the kernel. The logs don not get carried over kexec and thus > > > remote attesation cannot verify the signature of the running kernel. > > > > > > Introduce an ABI to carry forward the ima logs over kexec. > > > Memory reserved via device tree reservation can be used to store and read > > > via the of_* functions. > > > > This flow needs to work for: > > > > 1) Pure DT > > 2) DT + EFI memory map > > 3) ACPI + EFI memory map > > > > ... and if this is just for transiently passing the log, I don't think > > that a reserved memory region is the right thing to use, since they're > > supposed to be more permanent. > > > > This sounds analogous to passing the initrd, and should probably use > > properties under the chosen node (which can be used for all three boot > > flows above). > > > > For reference, how big is the IMA log likely to be? Does it need > > physically contiguous space? > > It purely depends on the policy used and the modules/files that are accessed > for my local testing over a kexec session the log in > about 30KB. > > Current implementation expects enough contiguous memory to allocated to > carry forward the logs. If the log size exceeds the reserved memory the > call will fail. > > Thanks, > Prakhar Srivastava > > > > Thanks, > > Mark. > > > > > > > > Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting > > > address, followed by the IMA log contents. > > > > > > Tested on: > > > arm64 with Uboot > > > > > > Prakhar Srivastava (2): > > > Add a layer of abstraction to use the memory reserved by device tree > > > for ima buffer pass. > > > Add support for ima buffer pass using reserved memory for arm64 kexec. > > > Update the arch sepcific code path in kexec file load to store the > > > ima buffer in the reserved memory. The same reserved memory is read > > > on kexec or cold boot. > > > > > > arch/arm64/Kconfig | 1 + > > > arch/arm64/include/asm/ima.h | 22 ++++ > > > arch/arm64/include/asm/kexec.h | 5 + > > > arch/arm64/kernel/Makefile | 1 + > > > arch/arm64/kernel/ima_kexec.c | 64 ++++++++++ > > > arch/arm64/kernel/machine_kexec_file.c | 1 + > > > arch/powerpc/include/asm/ima.h | 3 +- > > > arch/powerpc/kexec/ima.c | 14 ++- > > > drivers/of/Kconfig | 6 + > > > drivers/of/Makefile | 1 + > > > drivers/of/of_ima.c | 165 +++++++++++++++++++++++++ > > > include/linux/of.h | 34 +++++ > > > security/integrity/ima/ima_kexec.c | 15 ++- > > > 13 files changed, 325 insertions(+), 7 deletions(-) > > > create mode 100644 arch/arm64/include/asm/ima.h > > > create mode 100644 arch/arm64/kernel/ima_kexec.c > > > create mode 100644 drivers/of/of_ima.c > > > > > > -- > > > 2.25.1 > > >
On 5/12/20 4:05 PM, Rob Herring wrote: > On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: >> Hi Mark, > > Please don't top post. > >> This patch set currently only address the Pure DT implementation. >> EFI and ACPI implementations will be posted in subsequent patchsets. >> >> The logs are intended to be carried over the kexec and once read the >> logs are no longer needed and in prior conversation with James( >> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/) >> the apporach of using a chosen node doesn't >> support the case. >> >> The DT entries make the reservation permanent and thus doesnt need kernel >> segments to be used for this, however using a chosen-node with >> reserved memory only changes the node information but memory still is >> reserved via reserved-memory section. > > I think Mark's point was whether it needs to be permanent. We don't > hardcode the initrd address for example. > Thankyou for clarifying my misunderstanding, i am modelling this keeping to the TPM log implementation that uses a reserved memory. I will rev up the version with chosen-node support. That will make the memory reservation free after use. >> On 5/5/20 2:59 AM, Mark Rutland wrote: >>> Hi Prakhar, >>> >>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: >>>> IMA during kexec(kexec file load) verifies the kernel signature and measures > > What's IMAIMA is a LSM attempting to detect if files have been accidentally or maliciously altered, both remotely and locally, it can also be used to appraise a file's measurement against a "good" value stored as an extended attribute, and enforce local file integrity. IMA also validates and measures the signers of the kernel and initrd during kexec. The measurements are extended to PCR 10(configurable) and the logs stored in memory, however once kexec'd the logs are lost. Kexec is used as secondary boot loader in may use cases and loosing the signer creates a security hole. This patch is an implementation to carry over the logs and making it possible to remotely validate the signers of the kernel and initrd. Such a support exits only in powerpc. This patch makes the carry over of logs architecture independent and puts the complexity in a driver. Thanks, Prakhar > >>>> the signature of the kernel. The signature in the logs can be used to verfiy the >>>> authenticity of the kernel. The logs don not get carried over kexec and thus >>>> remote attesation cannot verify the signature of the running kernel. >>>> >>>> Introduce an ABI to carry forward the ima logs over kexec. >>>> Memory reserved via device tree reservation can be used to store and read >>>> via the of_* functions. >>> >>> This flow needs to work for: >>> >>> 1) Pure DT >>> 2) DT + EFI memory map >>> 3) ACPI + EFI memory map >>> >>> ... and if this is just for transiently passing the log, I don't think >>> that a reserved memory region is the right thing to use, since they're >>> supposed to be more permanent. >>> >>> This sounds analogous to passing the initrd, and should probably use >>> properties under the chosen node (which can be used for all three boot >>> flows above). >>> >>> For reference, how big is the IMA log likely to be? Does it need >>> physically contiguous space? >> >> It purely depends on the policy used and the modules/files that are accessed >> for my local testing over a kexec session the log in >> about 30KB. >> >> Current implementation expects enough contiguous memory to allocated to >> carry forward the logs. If the log size exceeds the reserved memory the >> call will fail. >> >> Thanks, >> Prakhar Srivastava >>> >>> Thanks, >>> Mark. >>> >>>> >>>> Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting >>>> address, followed by the IMA log contents. >>>> >>>> Tested on: >>>> arm64 with Uboot >>>> >>>> Prakhar Srivastava (2): >>>> Add a layer of abstraction to use the memory reserved by device tree >>>> for ima buffer pass. >>>> Add support for ima buffer pass using reserved memory for arm64 kexec. >>>> Update the arch sepcific code path in kexec file load to store the >>>> ima buffer in the reserved memory. The same reserved memory is read >>>> on kexec or cold boot. >>>> >>>> arch/arm64/Kconfig | 1 + >>>> arch/arm64/include/asm/ima.h | 22 ++++ >>>> arch/arm64/include/asm/kexec.h | 5 + >>>> arch/arm64/kernel/Makefile | 1 + >>>> arch/arm64/kernel/ima_kexec.c | 64 ++++++++++ >>>> arch/arm64/kernel/machine_kexec_file.c | 1 + >>>> arch/powerpc/include/asm/ima.h | 3 +- >>>> arch/powerpc/kexec/ima.c | 14 ++- >>>> drivers/of/Kconfig | 6 + >>>> drivers/of/Makefile | 1 + >>>> drivers/of/of_ima.c | 165 +++++++++++++++++++++++++ >>>> include/linux/of.h | 34 +++++ >>>> security/integrity/ima/ima_kexec.c | 15 ++- >>>> 13 files changed, 325 insertions(+), 7 deletions(-) >>>> create mode 100644 arch/arm64/include/asm/ima.h >>>> create mode 100644 arch/arm64/kernel/ima_kexec.c >>>> create mode 100644 drivers/of/of_ima.c >>>> >>>> -- >>>> 2.25.1 >>>>
Hello Prakhar, Prakhar Srivastava <prsriva@linux.microsoft.com> writes: > On 5/12/20 4:05 PM, Rob Herring wrote: >> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: >>> Hi Mark, >> >> Please don't top post. >> >>> This patch set currently only address the Pure DT implementation. >>> EFI and ACPI implementations will be posted in subsequent patchsets. >>> >>> The logs are intended to be carried over the kexec and once read the >>> logs are no longer needed and in prior conversation with James( >>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/) >>> the apporach of using a chosen node doesn't >>> support the case. >>> >>> The DT entries make the reservation permanent and thus doesnt need kernel >>> segments to be used for this, however using a chosen-node with >>> reserved memory only changes the node information but memory still is >>> reserved via reserved-memory section. >> >> I think Mark's point was whether it needs to be permanent. We don't >> hardcode the initrd address for example. >> > Thankyou for clarifying my misunderstanding, i am modelling this keeping to the > TPM log implementation that uses a reserved memory. I will rev up the version > with chosen-node support. > That will make the memory reservation free after use. Nice. Do you intend to use the same property that powerpc uses (linux,ima-kexec-buffer)? >>> On 5/5/20 2:59 AM, Mark Rutland wrote: >>>> Hi Prakhar, >>>> >>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: >>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures >> >> What's IMAIMA is a LSM attempting to detect if files have been accidentally or > maliciously altered, both remotely and locally, it can also be used > to appraise a file's measurement against a "good" value stored as an extended > attribute, and enforce local file integrity. > > IMA also validates and measures the signers of the kernel and initrd > during kexec. The measurements are extended to PCR 10(configurable) and the logs > stored in memory, however once kexec'd the logs are lost. Kexec is used as > secondary boot loader in may use cases and loosing the signer > creates a security hole. > > This patch is an implementation to carry over the logs and making it > possible to remotely validate the signers of the kernel and initrd. Such a > support exits only in powerpc. > This patch makes the carry over of logs architecture independent and puts the > complexity in a driver. If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually powerpc-specific. It could be moved to an arch-independent directory and used by any other architecture which supports device trees. I think that's the simplest way forward. And to be honest I'm still trying to understand why you didn't take that approach. Did you try it and hit some obstacle or noticed a disadvantage for your use case? -- Thiago Jung Bauermann IBM Linux Technology Center
On 5/22/20 9:08 PM, Thiago Jung Bauermann wrote: > > Hello Prakhar, > > Prakhar Srivastava <prsriva@linux.microsoft.com> writes: > >> On 5/12/20 4:05 PM, Rob Herring wrote: >>> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: >>>> Hi Mark, >>> >>> Please don't top post. >>> >>>> This patch set currently only address the Pure DT implementation. >>>> EFI and ACPI implementations will be posted in subsequent patchsets. >>>> >>>> The logs are intended to be carried over the kexec and once read the >>>> logs are no longer needed and in prior conversation with James( >>>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/) >>>> the apporach of using a chosen node doesn't >>>> support the case. >>>> >>>> The DT entries make the reservation permanent and thus doesnt need kernel >>>> segments to be used for this, however using a chosen-node with >>>> reserved memory only changes the node information but memory still is >>>> reserved via reserved-memory section. >>> >>> I think Mark's point was whether it needs to be permanent. We don't >>> hardcode the initrd address for example. >>> >> Thankyou for clarifying my misunderstanding, i am modelling this keeping to the >> TPM log implementation that uses a reserved memory. I will rev up the version >> with chosen-node support. >> That will make the memory reservation free after use. > > Nice. Do you intend to use the same property that powerpc uses > (linux,ima-kexec-buffer)? > I was naming it ima-buffer, but naming is not a huge concern. I will use linux,ima-kexec-buffer. >>>> On 5/5/20 2:59 AM, Mark Rutland wrote: >>>>> Hi Prakhar, >>>>> >>>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: >>>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures >>> >>> What's IMAIMA is a LSM attempting to detect if files have been accidentally or >> maliciously altered, both remotely and locally, it can also be used >> to appraise a file's measurement against a "good" value stored as an extended >> attribute, and enforce local file integrity. >> >> IMA also validates and measures the signers of the kernel and initrd >> during kexec. The measurements are extended to PCR 10(configurable) and the logs >> stored in memory, however once kexec'd the logs are lost. Kexec is used as >> secondary boot loader in may use cases and loosing the signer >> creates a security hole. >> >> This patch is an implementation to carry over the logs and making it >> possible to remotely validate the signers of the kernel and initrd. Such a >> support exits only in powerpc. >> This patch makes the carry over of logs architecture independent and puts the >> complexity in a driver. > > If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually > powerpc-specific. It could be moved to an arch-independent directory and > used by any other architecture which supports device trees. > > I think that's the simplest way forward. And to be honest I'm still > trying to understand why you didn't take that approach. Did you try it > and hit some obstacle or noticed a disadvantage for your use case? > The approach i have in this patch set is to provide an abstraction layer that can be called from any architecture. However taking a deeper look only the setup dtb is probably architecture specific, only because the architecture specific kexec sets up the device tree. I can also move the code up in security/ima. However i do have some concerns with layering. I am hoping you can provide me with some guidance in this aspect, i will send you the patch i am working on to get some early feedback. Thanks, Prakhar Srivastava > -- > Thiago Jung Bauermann > IBM Linux Technology Center >
IMA during kexec(kexec file load) verifies the kernel signature and measures the signature of the kernel. The signature in the logs can be used to verfiy the authenticity of the kernel. The logs don not get carried over kexec and thus remote attesation cannot verify the signature of the running kernel. Introduce an ABI to carry forward the ima logs over kexec. Memory reserved via device tree reservation can be used to store and read via the of_* functions. Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting address, followed by the IMA log contents. Tested on: arm64 with Uboot Prakhar Srivastava (2): Add a layer of abstraction to use the memory reserved by device tree for ima buffer pass. Add support for ima buffer pass using reserved memory for arm64 kexec. Update the arch sepcific code path in kexec file load to store the ima buffer in the reserved memory. The same reserved memory is read on kexec or cold boot. arch/arm64/Kconfig | 1 + arch/arm64/include/asm/ima.h | 22 ++++ arch/arm64/include/asm/kexec.h | 5 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/ima_kexec.c | 64 ++++++++++ arch/arm64/kernel/machine_kexec_file.c | 1 + arch/powerpc/include/asm/ima.h | 3 +- arch/powerpc/kexec/ima.c | 14 ++- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/of_ima.c | 165 +++++++++++++++++++++++++ include/linux/of.h | 34 +++++ security/integrity/ima/ima_kexec.c | 15 ++- 13 files changed, 325 insertions(+), 7 deletions(-) create mode 100644 arch/arm64/include/asm/ima.h create mode 100644 arch/arm64/kernel/ima_kexec.c create mode 100644 drivers/of/of_ima.c