> This applies equally to the kernel command line, and given that we
> cannot authenticate it, we should whitelist params that we know to be
> safe, and filter out all others. A similar concern exists for the
> device tree on ARM/arm64, and we already disable the DTB loader in the
> UEFI stub if se
On 16 November 2016 at 23:27, One Thousand Gnomes
wrote:
> Whether it's a good idea aside
>
> You need to filter or lock down kernel module options because a lot of
> modules let you set the I/O port or similar (eg mmio) which means you can
> hack the entire machine with say the 8250 driver just b
Whether it's a good idea aside
You need to filter or lock down kernel module options because a lot of
modules let you set the I/O port or similar (eg mmio) which means you can
hack the entire machine with say the 8250 driver just by using it with an
mmio of the right location to patch the secure s
On Wed, Nov 16, 2016 at 3:47 PM, David Howells wrote:
>
> These patches provide a facility by which a variety of avenues by which
> userspace can feasibly modify the running kernel image can be locked down.
> These include:
>
Bit surprised to see this. Not that I am opposed to the patches
themse
These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:
(*) No unsigned modules and no modules for which can't validate the
signature.
(*) No use of ioperm(), iopl() and no writing to
5 matches
Mail list logo
