From: "David F." <df7729@gmail.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: LockDown that allows read of /dev/mem ?
Date: Mon, 21 Jun 2021 08:29:44 -0700 [thread overview]
Message-ID: <CAGRSmLuoP79dkE5_NgF+wiuotsYc6sV=fk=qzBVcEsjq0by5CQ@mail.gmail.com> (raw)
In-Reply-To: <99e0ef5a-156f-c8e5-cfc3-7c50e5e15a98@metux.net>
Lockdown required by secure boot and shim signing (prevent acpi
patching), root because it's main use is a utility boot disk. If
lockdown could be forced when secure boot active but not when not
active, that be best, but I'm not seeing that option. The other
option maybe to modify open_port on mem.c to do the secure boot check.
However searching EFI_SECURE_BOOT doesn't exist in 5.10.x as in
efi_enabled(EFI_SECURE_BOOT) - It appears that is some other patch
that is not applied to the base, I do see struct boot_params has a
secure_boot field set, but can I access that from mem.c? If not, is
efi_get_secureboot() function available when /drivers/char/mem.c may
be used?
On Mon, Jun 21, 2021 at 3:27 AM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> On 20.06.21 01:55, David F. wrote:
>
> > I'm finding that LockDown Integrity prevents blocks things like mdadm,
> > Xvesa, and a couple of my specialized tools. There should be an
> > option to allow /dev/mem read access. Is there? There are no secrets
> > to the boot disk booted environment it's all root.
>
> Looks like conflict of goals. lockdown is used in scenarios where one
> really doesn't take any chance that code running w/ root privileges can
> do such things (there's a lot of security critical information one can
> learn from reading the raw memory).
>
> I wonder what your actual use case is.
>
> * why are you using lockdown and also running everything as root ?
> * why are you still using the old Xvesa instead of using KMS or
> framebuffer device ?
> * why does mdadm want to access /dev/mem ?
>
>
>
> --mtx
>
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> info@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2021-06-21 15:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-19 23:55 LockDown that allows read of /dev/mem ? David F.
2021-06-21 10:27 ` Enrico Weigelt, metux IT consult
2021-06-21 15:29 ` David F. [this message]
2021-07-02 7:42 ` Enrico Weigelt, metux IT consult
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGRSmLuoP79dkE5_NgF+wiuotsYc6sV=fk=qzBVcEsjq0by5CQ@mail.gmail.com' \
--to=df7729@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).