On Wed, Feb 24, 2021 at 10:00:53AM -0800, James Bottomley wrote:
> On Sat, 2021-02-20 at 01:32 +0000, Matthew Garrett wrote:
> > Under certain circumstances it might be desirable to enable the
> > creation of TPM-backed secrets that are only accessible to the
> > kern
On Mon, Feb 22, 2021 at 12:23:59PM +0200, Mike Rapoport wrote:
> On Mon, Feb 22, 2021 at 07:34:52AM +0000, Matthew Garrett wrote:
> > On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:
> >
> > > It is unsafe to allow saving of secretmem areas to the hi
On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:
> It is unsafe to allow saving of secretmem areas to the hibernation
> snapshot as they would be visible after the resume and this essentially
> will defeat the purpose of secret memory mappings.
Sorry for being a bit late to this -
On Sat, Feb 20, 2021 at 05:09:07AM +0200, Jarkko Sakkinen wrote:
> Something popped into mind: could we make PCR 23 reservation dynamic
> instead of a config option.
>
> E.g. if the user space uses it, then it's dirty and hibernate will
> fail. I really dislike the static compilation time
On Fri, Feb 19, 2021 at 06:20:13PM -0800, Randy Dunlap wrote:
> For all of the Kconfig* configuration files throughout the source tree,
> the indentation is somewhat different. Lines under a ``config`` definition
> are indented with one tab, while help text is indented an additional two
>
On Sat, Feb 20, 2021 at 05:05:36AM +0200, Jarkko Sakkinen wrote:
> On Sat, Feb 20, 2021 at 01:32:49AM +0000, Matthew Garrett wrote:
> > Performing any sort of state validation of a sealed TPM blob requires
> > being able to access the individual members in the response. Par
. In the long term we may want a more flexible policy around this,
such as including PCR 7.
Signed-off-by: Matthew Garrett
---
include/linux/tpm.h | 4 ++
kernel/power/tpm.c | 161 ++--
2 files changed, 160 insertions(+), 5 deletions(-)
diff --git a/include
an additional argument to the trusted key creation
options, allowing the user to provide the set of PCRs that should have
their values incorporated into the creation data.
Signed-off-by: Matthew Garrett
---
.../security/keys/trusted-encrypted.rst | 4 +++
include/keys/trusted-type.h
.
Signed-off-by: Matthew Garrett
---
include/linux/tpm.h | 1 +
kernel/power/tpm.c | 150 +++-
2 files changed, 148 insertions(+), 3 deletions(-)
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index e2075e2242a0..f6970986b097 100644
--- a/include
to decrypt the hash. By setting PCR 23 to a specific
value we can verify that the key used was generated by the kernel during
hibernation and prevent an attacker providing their own key.
Signed-off-by: Matthew Garrett
---
kernel/power/Kconfig | 15 ++
kernel/power/Makefile| 1 +
kernel
Calculate and store a cryptographically secure hash of the hibernation
image if SF_VERIFY_IMAGE is set in the hibernation flags. This allows
detection of a corrupt image, but has the disadvantage that it requires
the blocks be read in in linear order.
Signed-off-by: Matthew Garrett
---
kernel
Certain in-kernel operations using a trusted key (such as creation
certification) require knowledge of the handle it's loaded at. Keep
a copy of that in the payload.
Signed-off-by: Matthew Garrett
---
include/keys/trusted-type.h | 1 +
security/keys/trusted-keys/trusted_tpm2.c | 6
Lockdown in integrity mode aims to ensure that arbitrary code cannot end
up in ring 0 without owner approval. The combination of module signing
and secure boot gets most of the way there, but various other features
are disabled by lockdown in order to avoid more convoluted approaches
that would
Performing any sort of state validation of a sealed TPM blob requires
being able to access the individual members in the response. Parse the
blob sufficiently to be able to stash pointers to each member, along
with the length.
Signed-off-by: Matthew Garrett
---
include/keys/trusted-type.h
Add an internal command for resetting a PCR.
Signed-off-by: Matthew Garrett
---
drivers/char/tpm/tpm-interface.c | 28 +
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 34 ++
drivers/char/tpm/tpm2-cmd.c | 36
somehow obtains the sealed material, it
will be unable to unseal it since PCR 23 will never be in the
appropriate state.
Signed-off-by: Matthew Garrett
---
drivers/char/tpm/Kconfig | 10 +
drivers/char/tpm/tpm-dev-common.c | 8 +++
drivers/char/tpm/tpm.h| 21
On Sun, Nov 29, 2020 at 9:36 PM Kai-Heng Feng
wrote:
>
> We are seeing thermal shutdown on Intel based mobile workstations, the
> shutdown happens during the first trip handle in
> thermal_zone_device_register():
> kernel: thermal thermal_zone15: critical temperature reached (101 C),
> shutting
On Sun, Dec 13, 2020 at 12:39:26AM +0100, Daniel Lezcano wrote:
> On 12/12/2020 21:08, Matthew Garrett wrote:
> > Anything that provides a trip point that has no active notifications and
> > doesn't provide any information that tells the kernel to poll it.
>
> I'm not a
On Sat, Dec 12, 2020 at 10:11:31AM +0100, Daniel Lezcano wrote:
> On 12/12/2020 04:50, Matthew Garrett wrote:
> > Yes - what's the reason to do so?
>
> I'm cleaning up the thermal core code, so questioning every old ABI.
>
> > The code isn't specific to ACPI,
> >
On Fri, Dec 11, 2020 at 02:17:55PM +0100, Daniel Lezcano wrote:
> On 08/12/2020 16:30, Daniel Lezcano wrote:
> > The passive file in sysfs forces the usage of a passive trip point set
> > by the userspace when a broken BIOS does not provide the mitigation
> > temperature for such thermal zone. The
On Tue, Nov 17, 2020 at 1:21 PM Matthew Garrett wrote:
>
> On Tue, Nov 17, 2020 at 1:00 PM Mathieu Chouquet-Stringer
> wrote:
>
> > I'm late to the party but it seems allowing MSR_IA32_ENERGY_PERF_BIAS
> > has the downside of flagging the kernel as tainted without tellin
On Tue, Nov 17, 2020 at 1:00 PM Mathieu Chouquet-Stringer
wrote:
> I'm late to the party but it seems allowing MSR_IA32_ENERGY_PERF_BIAS
> has the downside of flagging the kernel as tainted without telling you
> why if you use something like x86_energy_perf_policy (from
>
thout any arguments needed.
I'm confused why it's being exposed as an LED device in that case -
there's an expectation that this is something that actually controls a
real LED, which means responding to state. Are you able to share the
acpidump of a machine with this device?
--
Matthew Garrett | mj...@srcf.ucam.org
tually being set here? You don't seem to be passing any
arguments.
> +static const struct acpi_device_id privacy_acpi_device_ids[] = {
> +{"PNP0C09", 0},
Oooh no please don't do this - you'll trigger autoloading on everything
that exposes a PNP0C09 device.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, Oct 15, 2020 at 2:44 PM Jerry Snitselaar wrote:
>
> There is a misconfiguration in the bios of the gpio pin used for the
> interrupt in the T490s. When interrupts are enabled in the tpm_tis
> driver code this results in an interrupt storm. This was initially
> reported when we attempted
On Tue, Sep 8, 2020 at 1:35 PM Andy Lutomirski wrote:
> Undervolting is a bit different. It’s a genuinely useful configuration that
> can affect system stability. In general, I think it should be allowed, and
> it should have a real driver in tree.
Agree that this should be a proper driver
On Tue, Aug 04, 2020 at 05:46:30AM +, Yuan, Perry wrote:
> It is not patch issue, the kernel config needs to add "CONFIG_ACPI_BATTERY=y"
In that case you probably want to add a dependency to ACPI_BATTERY in
the DELL_LAPTOP Kconfig.
--
Matthew Garrett | mj...@srcf.ucam.org
ably makes sense to make this something Dell
specific.
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Jul 14, 2020 at 9:04 AM Chris Down wrote:
> Either way, again, this isn't really the point. :-) The point is that there
> _are_ currently widespread cases involving poking MSRs from userspace, however
> sacrilegious or ugly (which I agree with!), and while people should be told
> about
eople who
really want to disable the code can do so.
--
Matthew Garrett | mj...@srcf.ucam.org
initely need to do something.
CONFIG_PCIEASPM is default y. I don't think there's huge value in
adding complexity to deal with it being disabled, given that the kernel
is then in a configuration that no vendor is testing against. There are
existing runtime mechanisms to disable it at runtime.
On Fri, May 29, 2020 at 03:21:35PM -0500, Bjorn Helgaas wrote:
> Yeah, that makes sense. I can't remember the details, but I'm pretty
> sure there's a reason why we ask for the whole set of things. Seems
> like it solved some problem. I think Matthew Garrett might have been
&
On Wed, May 6, 2020 at 6:33 AM Daniel Kiper wrote:
>
> On Tue, May 05, 2020 at 10:29:05AM -0700, Matthew Garrett wrote:
> > On Mon, May 4, 2020 at 4:25 PM Daniel Kiper wrote:
> > >
> > > Otherwise the kernel does not know its state and cannot enable various
>
On Mon, May 4, 2020 at 4:25 PM Daniel Kiper wrote:
>
> Otherwise the kernel does not know its state and cannot enable various
> security features depending on UEFI Secure Boot.
I think this needs more context. If the kernel is loaded via the EFI
boot stub, the kernel is aware of the UEFI secure
On Wed, Sep 25, 2019 at 7:54 AM Jiri Kosina wrote:
> Seems like this didn't happen (yet) ... are there any plans to either drop
> it for good, or merge it?
rc1 isn't out yet, so I'm just waiting to see what happens.
the CRNG and
documented their findings in
https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-basic .
--
Matthew Garrett | mj...@srcf.ucam.org
stem. So it doesn't matter how many clients you have calling
getrandom() in the boot process - either there'll be enough entropy
available to satisfy all of them, or there'll be too little to satisfy
any of them.
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Sep 17, 2019 at 06:20:02PM +0100, Matthew Garrett wrote:
> AES keys are used for a variety of long-lived purposes (eg, disk
> encryption).
And as an example of when we'd want to do that during early boot - swap
is frequently encrypted with a random key generated on each boot, but
On Tue, Sep 17, 2019 at 07:16:41PM +0200, Willy Tarreau wrote:
> On Tue, Sep 17, 2019 at 05:34:56PM +0100, Matthew Garrett wrote:
> > On Tue, Sep 17, 2019 at 09:27:44AM -0700, Linus Torvalds wrote:
> >
> > > Does anybody believe that 128 bits of randomness is a good bas
On Tue, Sep 17, 2019 at 09:27:44AM -0700, Linus Torvalds wrote:
> Does anybody believe that 128 bits of randomness is a good basis for a
> long-term secure key?
Yes, it's exactly what you'd expect for an AES 128 key, which is still
considered to be secure.
--
Matthew Garret
On 16 September 2019 18:41:36 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett
>wrote:
>>
>> Exactly the scenario where you want getrandom() to block, yes.
>
>It *would* block. Just not forever.
It's already not forever
o it on an idle machine that doesn't have entropy
Exactly the scenario where you want getrandom() to block, yes.
>in order to basically reproduce the current boot-time hang situation
>with the broken gdm, except with an actual "generate key".
>
>Then you have to ignore the big warning too.
The big warning that's only printed in dmesg?
--
Matthew Garrett | mj...@srcf.ucam.org
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographi
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographi
because it was convenient and
the kernel usually ended up generating enough entropy in the first
place. Given the ambiguity, I don't see an easy way to solve for the
latter without breaking the former - and that could have some *very* bad
outcomes.
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Sep 17, 2019 at 04:13:36AM +0500, Alexander E. Patrakov wrote:
> 17.09.2019 04:11, Matthew Garrett пишет:
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel"
>
> You can't. There are way too many dedicated server providers
On Mon, Sep 16, 2019 at 04:05:47PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett wrote:
> > Changing the default (even with kernel warnings) seems like
> > it risks people generating keys from an unseeded prng, and that seems
> > like a ba
On Wed, Sep 4, 2019 at 12:51 PM Matthew Garrett wrote:
> On Fri, Aug 30, 2019 at 9:28 AM David Howells wrote:
> > > +static int lock_kernel_down(const char *where, enum lockdown_reason
> > > level)
> >
> > Is the last parameter the reason or the level?
I accidentally typoed this #ifdef, so verification would always be
disabled.
Signed-off-by: Matthew Garrett
Reported-by: Philipp Rudo
---
arch/s390/kernel/kexec_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/kexec_elf.c b/arch/s390/kernel/kexec_elf.c
Constify some arrays and fix an #ifdef that I typoed.
No reason for these not to be const.
Signed-off-by: Matthew Garrett
Suggested-by: David Howells
---
security/lockdown/lockdown.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 0068cec77c05..8a10b43daf74
On Fri, Aug 30, 2019 at 9:31 AM David Howells wrote:
>
> Matthew Garrett wrote:
>
> > enum lockdown_reason {
> > LOCKDOWN_NONE,
> > + LOCKDOWN_MODULE_SIGNATURE,
> > LOCKDOWN_INTEGRITY_MAX,
> > LOCKDOWN_CONFIDENTIALITY_MAX,
>
On Fri, Aug 30, 2019 at 9:28 AM David Howells wrote:
>
> Matthew Garrett wrote:
>
> > +static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>
> const char *const maybe?
Seems reasonable.
> > +static enum lockdown_reason lockdow
current;
+#else
+ result = -EINVAL;
+#endif
+ break;
default:
error = -EINVAL;
break;
--
Matthew Garrett | mj...@srcf.ucam.org
d grant control to the TPM
driver.
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Aug 27, 2019 at 1:23 AM Seunghun Han wrote:
> If the regions allocated in the NVS region need to be handled by a
> driver, the callback mechanism is good for it. However, this case
> doesn't need it because the regions allocated in NVS are just I/O
> regions.
>
> In my opinion, if the
On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han wrote:
> To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> the reserved area so that AMD's fTPM regions could be assigned in it.
drivers/acpi/nvs.c saves and restores the contents of NVS regions, and
if other drivers use
On Tue, Aug 20, 2019 at 3:32 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Commit
>
> 9d1f8be5cf42 ("bpf: Restrict bpf when kernel lockdown is in confidentiality
> mode")
>
> is missing a Signed-off-by from its author.
I'm providing this under category (c) of the DCO.
On Tue, Aug 20, 2019 at 12:45 PM Bjorn Helgaas wrote:
> Since I've acked this and it's 11/29, I've been assuming you intend
> to merge the whole series together. But the fact that it's up to V40
> makes me wonder if you're waiting for me to merge this one. Just let
> me know either way.
James
securityfs), boot time (via a kernel parameter) or
build time (via a kconfig option). Based on initial code by David
Howells.
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Cc: David Howells
---
.../admin-guide/kernel-parameters.txt | 9 +
include/linux/security.h
From: Matthew Garrett
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: Kees
Tracefs may release more information about the kernel than desirable, so
restrict it when the kernel is locked down in confidentiality mode by
preventing open().
(Fixed by Ben Hutchings to avoid a null dereference in
default_file_open())
Signed-off-by: Matthew Garrett
Reviewed-by: Steven
From: David Howells
Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data. This is limited to lockdown
confidentiality mode and is still permitted in integrity mode.
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
modules.
Reported-by: Alexei Starovoitov
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Acked-by: Masami Hiramatsu
Reviewed-by: Kees Cook
Cc: Naveen N. Rao
Cc: Anil S Keshavamurthy
Cc: da...@davemloft.net
Cc: Masami Hiramatsu
Signed-off-by: James Morris
---
include/linux
off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Signed-off-by: James Morris
---
fs/proc/kcore.c | 5 +++--
security/lockdown/lockdown.c | 8 ++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
in
From: David Howells
The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space. This is
a runtime check rather than buildtime in order to allow configurations
where the same kernel may be run in both locked down or
From: David Howells
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
private keys in kernel memory to be leaked. Disable them if the kernel
has been locked down in confidentiality mode.
Suggested-by: Alexei Starovoitov
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
lockdowns. Modified by Matthew Garrett to remove the IMA
integration, which will be replaced by integrating with the IMA
architecture policy patches.]
Signed-off-by: Jiri Bohac
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
cc: ke...@lists.infradead.org
---
kernel/kexec_file.c | 2
From: David Howells
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
Suggested-by: Alan Cox
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).
Signed-off-by: David Howells
cc: Andy Shevchenko
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
cc: Matthew Garrett
cc: Thomas Gleixner
Cc: Greg KH
Cc: Rafael J. Wysocki
-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Cc: r...@rjwysocki.net
Cc: pa...@ucw.cz
cc: linux...@vger.kernel.org
Signed-off-by: James Morris
---
include/linux/security.h | 1 +
kernel/power/hibernate.c | 3 ++-
security/lockdown/lockdown.c | 1 +
3 files changed
From: David Howells
Disallow the use of certain perf facilities that might allow userspace to
access kernel data.
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Signed-off-by: James Morris
-by: Matthew Garrett
Acked-by: Mimi Zohar
Cc: Dmitry Kasatkin
Cc: linux-integr...@vger.kernel.org
Signed-off-by: James Morris
---
include/linux/ima.h | 9 ++
kernel/kexec_file.c | 10 +-
security/integrity/ima/ima.h| 2 ++
security/integrity/ima
.
Reported-by: Greg Kroah-Hartman
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
Signed-off-by: James Morris
---
drivers/tty/serial/serial_core.c | 5 +
include/linux/security.h | 1 +
security
From: David Howells
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Signed-off-by: James Morris
---
drivers/pcmcia/cistpl.c
uld disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.
Signed-off-by: Linn Crosetto
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
in the kernel proper if lockdown is not enabled. If lockdown is
enabled and an RSDP is provided on the command line, this will only be
used when parsing SRAT (which shouldn't permit kernel code execution)
and will be ignored in the rest of the kernel.
(Modified by Matthew Garrett in order to handle
From: Matthew Garrett
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.
This also implicitly locks
From: Matthew Garrett
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Kees Cook
Reviewed-by: Thomas
From: Matthew Garrett
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax
are initialised in link order and cannot be overridden via
boot parameters, and cannot make use of kmalloc() (since the allocator
isn't initialised yet).
(Fixed by Stephen Rothwell to include a stub to fix builds when
!CONFIG_SECURITY)
Signed-off-by: Matthew Garrett
Acked-by: Kees Cook
Acked
(EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
return the error we got.
Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.
[Modified by Matthew Garrett to remove the IMA integration
From: Matthew Garrett
The kexec_load() syscall permits the loading and execution of arbitrary
code in ring 0, which is something that lock-down is meant to prevent. It
makes sense to disable kexec_load() in this situation.
This does not affect kexec_file_load() syscall which can check
From: Matthew Garrett
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been
Add a mechanism to allow LSMs to make a policy decision around whether
kernel functionality that would allow tampering with or examining the
runtime state of the kernel should be permitted.
Signed-off-by: Matthew Garrett
Acked-by: Kees Cook
Acked-by: Casey Schaufler
---
include/linux
After chatting with James in person, I'm resending the full set with the
fixes merged in in order to avoid any bisect issues. There should be no
functional changes other than avoiding build failures with some configs,
and fixing the oops in tracefs.
On Wed, Aug 14, 2019 at 10:46 AM Borislav Petkov wrote:
> Yeah, ok, I see what you're doing there. AFAICT, you do that in
>
> setup_arch->acpi_boot_table_init-> ... -> acpi_os_get_root_pointer()
Right.
> I hope nothing needs it earlier because then we'll have to restructure
> again...
Passing
On Wed, Aug 14, 2019 at 12:25 AM Borislav Petkov wrote:
> #if defined(CONFIG_RANDOMIZE_BASE) && defined(CONFIG_MEMORY_HOTREMOVE)
>
> false and thus not available to early code anymore.
We explicitly don't want to pay attention to the acpi_rsdp kernel
parameter in early boot except for the case
On Fri, Aug 9, 2019 at 11:08 PM James Morris wrote:
> Please verify and test, as I had to make a few minor fixups for my v5.2
> base.
Thanks James - there's a few small fixups required, would you like
those as separate patches or should I just send you a fixed copy of
the original patchset?
On Mon, Aug 12, 2019 at 8:29 AM Steven Rostedt wrote:
> From what I understand, Matthew's "lockdown" work is to prevent the
> system from doing anything to see what is happening in the kernel. This
> includes tracefs. This looks like it is working as designed.
Oopsing the kernel isn't working
(EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
return the error we got.
Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.
[Modified by Matthew Garrett to remove the IMA integration
From: David Howells
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
Suggested-by: Alan Cox
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
On Thu, Aug 8, 2019 at 3:01 AM Jessica Yu wrote:
> If you're confident that a hard dependency is not the right approach,
> then perhaps we could add a comment in the Kconfig (You could take a
> look at the comment under MODULE_SIG_ALL in init/Kconfig for an
> example)? If someone is configuring
in the kernel proper if lockdown is not enabled. If lockdown is
enabled and an RSDP is provided on the command line, this will only be
used when parsing SRAT (which shouldn't permit kernel code execution)
and will be ignored in the rest of the kernel.
(Modified by Matthew Garrett in order to handle
From: Matthew Garrett
The kexec_load() syscall permits the loading and execution of arbitrary
code in ring 0, which is something that lock-down is meant to prevent. It
makes sense to disable kexec_load() in this situation.
This does not affect kexec_file_load() syscall which can check
From: David Howells
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
---
drivers/pcmcia/cistpl.c | 5 +
include/linux
-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Cc: r...@rjwysocki.net
Cc: pa...@ucw.cz
cc: linux...@vger.kernel.org
---
include/linux/security.h | 1 +
kernel/power/hibernate.c | 3 ++-
security/lockdown/lockdown.c | 1 +
3 files changed, 4 insertions(+), 1 deletion
From: Matthew Garrett
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax
From: Matthew Garrett
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: Kees
. KEXEC_SIG_FORCE disallows images without a valid signature.
Signed-off-by: Jiri Bohac
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Jiri Bohac
Reviewed-by: Dave Young
cc: ke...@lists.infradead.org
---
arch/x86/Kconfig | 20 +
crypto
1 - 100 of 3200 matches
Mail list logo
