Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

[Lukas Wunner]

On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote:
> > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > > * Add the EFI Firmware Volume Protocol to include/linux/efi.h:
> > >   
> > > https://www.intel.com/content/dam/doc/reference-guide/efi-firmware-file-volume-specification.pdf
> > > 
> > > * Amend arch/x86/boot/compressed/eboot.c to read the files with the
> > >   GUIDs you're interested in into memory and pass the files to the
> > >   kernel as setup_data payloads.
> 
> To be honest, I'm a bit skeptical about the firmware volume approach.
> Tools like UEFITool[0] and uefi-firmware-parser[1] have existed for
> years, still don't seem to reliably parse firmware images I see in the
> wild, and have a fairly regular need for fixes.  These are tools
> maintained by smart people who are making a real effort, and it still
> looks pretty hard to do a good job that applies across a lot of
> platforms.
> 
> So I'd rather use Hans's existing patches, at least for now, and if
> someone is interested in hacking on making an efi firmware volume parser
> for the kernel, switch them to that when such a thing is ready.

Hello?  As I've written in the above-quoted e-mail the kernel should
read the files using EFI_FIRMWARE_VOLUME_PROTOCOL.ReadFile().

*Not* by parsing the firmware volume!

Parsing the firmware volume is only necessary to find out the GUIDs
of the files you're looking for.  You only do that *once*.

I habitually extract Apple's EFI Firmware Volumes and found the
existing tools always did a sufficiently good job to get the
information I need (such as UEFIExtract, which I've linked to,
and which is part of the UEFITool suite, which you've linked to
once more).


On Wed, Apr 04, 2018 at 10:25:05PM +0200, Hans de Goede wrote:
> Lukas, thank you for your suggestions on this, but I doubt that these
> devices use the Firmware Volume stuff.

If they're using EFI, they're using a Firmware Volume and you should
be able to use the Firmware Volume Protocol to read files from it.

If that protocol wasn't supported, the existing EFI drivers wouldn't
be able to function as they couldn't load files from the volume.


> What you are describing sounds like significantly more work then
> the vendor just embedding the firmware as a char firmware[] in their
> EFI mouse driver.

In such cases, read the EFI mouse driver from the firmware volume and
extract the firmware from the offset you've pre-determined.  That's
never going to change since the devices never receive updates, as
you're saying.  So basically you'll have a struct with GUID, offset,
length, and the name under which the firmware is made available to
Linux drivers.


> That combined with Peter's worries about difficulties parsing the
> Firmware Volume stuff, makes me believe that it is best to just
> stick with my current approach as Peter suggests.

I don't know why you insist on a hackish solution (your own words)
even though a cleaner solution is suggested, but fortunately it's
not for me to decide what goes in and what doesn't. ;-)

Thanks,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

[AKASHI Takahiro]

On Mon, Apr 02, 2018 at 10:53:32AM +0900, AKASHI Takahiro wrote:
> James,
> 
> My apologies for slow response. I had a long weekend.
> 
> On Tue, Mar 27, 2018 at 02:32:49PM +0100, James Morse wrote:
> > Hi Akashi,
> > 
> > On 27/03/18 11:16, AKASHI Takahiro wrote:
> > > On Tue, Mar 20, 2018 at 01:18:34AM +0530, Bhupesh Sharma wrote:
> > >> On 03/14/2018 01:59 PM, AKASHI Takahiro wrote:
> > >>> Currently, there is a inconsistent view between (A) and the mainline's:
> > >>> see (A-1) and (B-1). If this is really a matter, I can fix it.
> > >>> Kexec-tools can be easily modified to accept both formats, though.
> > 
> > Ooer, what needs changing in kexec-tools? What happens if someone doesn't 
> > update
> > userspace at the same time?
> 
> Basically, changes that I made on /proc/iomem in my new format D were:
> 1. to move NOMAP region entries, formerly named "reserved" and now named
>"reserved (no map)", under System RAM
> 2. to add new entries for firmware-reserved regions as "reserved" also
>under System RAM
> 
> On the other hand, current kexec-tools, in particular kexec command,
> only scan top-level "System RAM" entries as well as "reserved" entries.
> 
> So if someone doesn't update kexec-tools, secondary kernel may potentially
> crash during boot time either because
> a. new kernel (or initrd/dtb) may have been allocated on a NOMAP region
>which are not suitable for usable memory, or
> b. new kernel (or initrd/dtb) may have been allocated on a reserved region
>whose contents can be overwritten.
> 
> While we see (b) even today, (a) is a backward compatibility issue.
> 
> Note: we have a different story for kdump (alignment error), and I will
> take a different approach to fixing kdump case.
> 
> > Is there a format which doesn't require a user-space change, (and shouldn't 
> > we
> > pick that one?)
> 
> The only solution that I can imagine for now to prevent (a) and (b)
> at the same time without any user-space change is
> 2+. to add new entries for firmware-reserved regions as "reserved",
> in addition to the current NOMAP regions, at top level
> 
> (format E)
> 4000-5858 : System RAM
>   4008-40f1 : Kernel code
>   4104-411e9fff : Kernel data
>   5440-583f : Crash kernel
> 5859-585e : reserved
> 484f-586f : System RAM 
> 5870-5871 : reserved
> 5872-58b5 : reserved (no map)
> 58b6-58b0 : System RAM
> 58b61000-58b61fff : reserved
> 5862-59a7b117 : System RAM
> 59a7b118-59a7b667 : reserved
> 59a7b668-5be3 : System RAM
> 5be4-5bec : reserved (no map)
> 5bed-5bed : System RAM
> 5bee-5bff : reserved (no map)
> 5ec0-5edf : reserved
> 5ee0-5fff ; System RAM
> 80-ff : PCI Bus :00
> 
> This does not only look quite noisy but also ignores the fact that
> reserved regions are part of System RAM (or memblock.memory). 
> 
> Or to maximize the compatibility, we may adopt format B:
> 
> (format B)
> 4000-5871 : System RAM
>   4008-40f1 : Kernel code
>   4104-411e9fff : Kernel data
>   5440-583f : Crash kernel
>   5859-585e : reserved
>   5870-5871 : reserved
> 5872-58b5 : reserved (no map)
> 58b6-5be3 : System RAM
>   58b61000-58b61fff : reserved
>   59a7b118-59a7b667 : reserved
> 5be4-5bec : reserved (no map)
> 5bed-5bed : System RAM
> 5bee-5bff : reserved (no map)
> 5c00-5fff : System RAM
>   5ec0-5edf : reserved
> 80-ff : PCI Bus :00
> 
> but, in this case, we need some change on kexec-tools to fix (b).
> 
> > >>> 2. How should we determine which regions be exported in /proc/iomem?
> > >>>
> > >>>  a. Trust all the memblock_reserve'd regions as my previous patch [3] 
> > >>> does.
> > >>>
> > >>> As I said, it's a kind of "overkill." Some of regions, say fdt, are
> > >>> not required to be preserved across kexec.
> > >>
> > >>
> > >> I think we should preserve all the memblock_reserve'd regions. So +1 on 
> > >> this
> > >> approach from my side. I believe it might help avoid issues we have seen 
> > >> in
> > >> the past with 'kexec-tools' _incorrectly_ determining which regions to 
> > >> pick
> > >> from the '/proc/iomem'.
> > > 
> > > As I said in my reply to Ard's comment, I now know *overkill* is not a big
> > > issue and I will go for this approach.
> > 
> > /sys/kernel/debug/memblock/reserved has all kinds of weird stuff in it,
> > including some smaller-than-a-page reservations that appear to come from the
> > percpu allocator.
> > 
> > I agree it will make the implementation simpler, and reserving 'too much' 
> > isn't
> > an issue.
> 
> Are you suggesting that we should use /sys/kernel/debug/memblock/reserved
> without modifying current /proc/iomem?
> (Note that, even in this approach, we need an user-space change.)
> 
> Hmm, overall, this approach will be preferable to format B/E.

What is nice in this approach is that 

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[joeyli]

Hi David, 

On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote:
> Andy Lutomirski  wrote:
> 
> > Since this thread has devolved horribly, I'm going to propose a solution.
> > 
> > 1. Split the "lockdown" state into three levels:  (please don't
> > bikeshed about the names right now.)
> > 
> > LOCKDOWN_NONE: normal behavior
> > 
> > LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to
> > kernel memory
> > 
> > LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY: kernel tries to keep root from
> > reading or writing kernel memory.
> 
> In theory, it's good idea, but in practice it's not as easy to implement as I
> think you think.
> 
> Let me list here the things that currently get restricted by lockdown:
> 
[...snip]
>  (5) Kexec.
>

About IMA with kernel module signing and kexec(not on x86_64 yet)...

Because IMA can be used to verify the integrity of kernel module or even
the image for kexec. I think that the
IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY must be enabled at runtime
when kernel is locked-down.

Because the root can enroll master key to keyring then IMA trusts the ima key
derived from master key. It causes that the arbitrary signed module can be 
loaded
when the root compromised.

Thanks
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[joeyli]

On Wed, Apr 04, 2018 at 11:19:27PM +0100, David Howells wrote:
> Jann Horn  wrote:
> 
> > > Uh, no.  bpf, for example, can be used to modify kernel memory.
> > 
> > I'm pretty sure bpf isn't supposed to be able to modify arbitrary
> > kernel memory. AFAIU if you can use BPF to write to arbitrary kernel
> > memory, that's a bug; with CAP_SYS_ADMIN, you can read from userspace,
> > write to userspace, and read from kernelspace, but you shouldn't be
> > able to write to kernelspace.
> 
> Ah - you may be right.  I seem to have misremembered what Joey Lee wrote in
> his patch description.
>

Sorry for it's my fault to misunderstood the behavoir of bpf with
CAP_SYS_ADMIN.

Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[joeyli]

Hi Andy,

On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote:
> Since this thread has devolved horribly, I'm going to propose a solution.
...
> 6. There's a way to *decrease* the lockdown level below the configured
> value.  (This ability itself may be gated by a config option.)
> Choices include a UEFI protected variable, an authenticated flag
> passed by the bootloader, and even just some special flag in the boot
> handoff protocol.  It would be really quite useful for a user to be
> able to ask their bootloader to reduce the lockdown level for the
> purpose of a particular boot for debugging.  I read the docs on

The "mokutil --disable-validation" done a similar bahvior as above.
Just it lets kernel to ignore the secure boot. 

> mokutil --disable-validation, and it's quite messy.  Let's have a way
> to do this that is mostly independent of the particular firmware in
> use.
>

Why the disabl-validation is messy?   
The mokutil is shim specific but not dependent on particular firmware. 
 
> I can imagine a grub option that decreases lockdown level along with a
> rule that grub will *not* load that option from its config, for
> example.
>

The root can modify the grub config to decrease lockdown level in next
boot without physcial accessing. The mokutil's interactive UI is used
to deal with user to confirm the physcial accessing.

Thanks
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Peter Dolding]

On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett  wrote:
> On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding  wrote:
>> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett  wrote:
>
>> > There are four cases:
>> >
>> > Verified Boot off, lockdown off: Status quo in distro and mainline
> kernels
>> > Verified Boot off, lockdown on: Perception of security improvement
> that's
>> > trivially circumvented (and so bad)
>> > Verified Boot on, lockdown off: Perception of security improvement
> that's
>> > trivially circumvented (and so bad), status quo in mainline kernels
>> > Verified Boot on, lockdown on: Security improvement, status quo in
> distro
>> > kernels
>> >
>> > Of these four options, only two make sense. The most common
> implementation
>> > of Verified Boot on x86 platforms is UEFI Secure Boot,
>
>> Stop right there.   Verified boot does not have to be UEFI secureboot.
>>You could be using a uboot verified boot or
>> https://www.coreboot.org/git-docs/Intel/vboot.html  google vboot.
>> Neither of these provide flags to kernel to say they have been
>> performed.
>
> They can be modified to set the appropriate bit in the bootparams - the
> reason we can't do that in the UEFI case is that Linux can be built as a
> UEFI binary that the firmware execute directly, and so the firmware has no
> way to set that flag.
>
With some of your embedded hardware boot loaders you have exactly the
same problem.   Where you cannot set bootparams instead have to hard
set everything in the kernel image.  This is why there is a option to
embedded initramfs image inside kernel image because some of them will
only load 1 file.

So not using UEFI  you run into the exact same problem.   So lockdown
on or off need to be a kernel build option setting default.   This
could be 3 options Always on, Always off and "Automatic based on boot
verification system status".

https://linux.die.net/man/8/efibootmgr

Also I have a problem here in non broken UEFI implementations -@ |
--append-binary-args that is very simple set the command line passed
into UEFI binary loaded by the firmware with the Linux kernel this
comes bootparams.   Yes using --append-binary-args can be a pain it is
used to tell the Linux kernel where to find the / drive.   So turning
lockdown off by bootparams is down right possible with working UEFI.
There is a lot of EFI out there that does not work properly.

>> Now Verified Boot on, lockdown off.   Insanely this can be required in
>> diagnostic on some embedded platform because EFI secureboot does not
>> have a off switch.These are platforms where they don't boot if
>> they don't have a PK and KEK set installed.  Yes some of these is jtag
>> the PK and KEK set in.
>
>> The fact that this Verified Boot on, lockdown off causes trouble
>> points to a clear problem.   User owns the hardware they should have
>> the right to defeat secureboot if they wish to.
>
> Which is why Shim allows you to disable validation if you prove physical
> user presence.

Good idea until you have a motherboard where the PS2 ports have failed
and does not support usb keyboard so you have no keyboard until after
the kernel has booted so no way to prove physical presence.   Or are
working on something embedded that has no physical user presence
interface in the boot stages these embedded devices can also be UEFI
with secureboot.  Not everything running UEFI has keyboard,
screenanything that you can prove physical user presence with
sometimes you have to pure depend on the signing key.

If I am a person who has made my own PK and has my own KEK in UEFI
system I should have the right to sign kernel with lockdown off by
default.   I may need this for diagnostics on hardware without user
interface and I may need this because the hardware is broken and I
have set PK and KEK set by direct firmware  flash access possibly by
jtag or possibly before critical port on motherboard died.

Of course I am not saying that Microsoft and others cannot have rules
that say if using their KEK that you cannot do this.   But if the
machine is my hardware and I have set my own PK and KEK set I do know
what I am doing and I should be allowed to compromise security if I
wish its my hardware.   I should not have to custom hack to do it.
Of course I am not saying that the setting in Linux kernel
configuration system cannot have a big warning that you should not do
this unless you have no other valid option and I am not saying that
the kernel should not log/report if it see what appears to be a
questionable configuration like dmesg "SECURITY ISSUE:  UEFI
secureboot detected enabled kernel built with lockdown disabled system
at risk of comprise".  Something audit tools could check logs for. .

So a kernel booting secureboot with lockdown disabled in kernel
configuration is perfectly fine to log a message that this is the
case.   Always forcing lockdown on because you see UEFI secureboot
will cause issues.

Broken 

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[Matthew Garrett]

On Wed, Apr 4, 2018 at 4:25 PM James Morris  wrote:
> It's surely reasonable to allow an already secure-booted system to be
> debugged without needing to be rebooted.

alt-sysrq-x from a physical console will do that.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding  wrote:

> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
disabled.

> Stop being narrow minded you don't need secure boot to protect
> bootloader or kernel the classic is only boot from read only media.

And if you use another protected path you can set the appropriate bootparam
flag or pass the appropriate kernel command line argument and gain the same
functionality.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Peter Dolding]

> If you don't have secure boot then an attacker with root can modify your
> bootloader or kernel, and on next boot lockdown can be silently disabled.

Stop being narrow minded you don't need secure boot to protect
bootloader or kernel the classic is only boot from read only media.

Another is network boot using https can coreboot firmware.   This
checks the certificate  of the https server against selected CA before
downloading anything and as long as the firmware is set read only in
hardware the attack has absolutely nothing to work on.

In fact the network boot form https server is more secure than UEFI
secureboot due to highly limited parties who can alter/provide the
approved boot loader/kernel image.

Having root user rights does not override physical security.The
fact there are other ways of doing bootloader and kernel security
other than UEFI secureboot that are in lots of cases more secure than
UEFI secureboot due to using more limited keys is the absolute reason
why lockdown is required without UEFI secureboot.

It would make sense to extend kexec to support UEFI secureboot
verification  and also kexec to have frameworks to support other
security options like https server storage of all kernel images.
Please note kexec supporting UEFI secureboot verification should also
support booting non UEFI secureboot but verified by some other method
and having own PK/KEK set for kexec and this would be when the Linux
kernel is placed in firmware and used instead of EFI firmware..

Please note there are many UEFI firmwares that with secureboot off
allow setting up secure https bootting where you are not in fact
validating the boot loader or kernel but validating the source you get
them from.

There are three different ways to achieve a protected boot process.
1) validate the boot files.(this is like UEFI secure boot and many
other methods)
2) validate source the boot files.  Yes this can be apply key check to
image if image is not signed don't boot from it and the image contain
boot loader and kernel then not bother validating the boot loader and
kernel image/parts individually same with https.
3) make boot files read only.

All three achieve the same level of security.   If you are using any
of the three lockdown option may provide some benefit.

Yes https network boot effectively does 2 and 3 so making having a
very limit threat against the boot process.

Remember there is more 1 way to skin a cat just like there is more
than 1 way to make a secure system.   Currently being too narrow in
methods for doing protected booting.


Peter Dolding.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[James Morris]

On Wed, 4 Apr 2018, David Howells wrote:

> > 6. There's a way to *decrease* the lockdown level below the configured
> > value.  (This ability itself may be gated by a config option.)
> > Choices include a UEFI protected variable,
> 
> By turning secure boot off, maybe?

It's surely reasonable to allow an already secure-booted system to be 
debugged without needing to be rebooted.



- James
-- 
James Morris


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[David Howells]

Jann Horn  wrote:

> > Uh, no.  bpf, for example, can be used to modify kernel memory.
> 
> I'm pretty sure bpf isn't supposed to be able to modify arbitrary
> kernel memory. AFAIU if you can use BPF to write to arbitrary kernel
> memory, that's a bug; with CAP_SYS_ADMIN, you can read from userspace,
> write to userspace, and read from kernelspace, but you shouldn't be
> able to write to kernelspace.

Ah - you may be right.  I seem to have misremembered what Joey Lee wrote in
his patch description.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

[Hans de Goede]

HI,

On 04-04-18 19:18, Peter Jones wrote:

On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:

On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:

On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:

I asked Peter Jones for suggestions how to extract this during boot and
he suggested seeing if there was a copy of the firmware in the
EFI_BOOT_SERVICES_CODE memory segment, which it turns out there is.

My patch to add support for this contains a table of device-model (dmi
strings), firmware header (first 64 bits), length and crc32 and then if
we boot on a device-model which is in the table the code scans the
EFI_BOOT_SERVICES_CODE for the prefix, if found checks the crc and
caches the firmware for later use by request-firmware.

So I just do a brute-force search for the firmware, this really is hack,
nothing standard about it I'm afraid. But it works on 4 different x86
tablets I have and makes the touchscreen work OOTB on them, so I believe
it is a worthwhile hack to have.


The EFI Firmware Volume contains a kind of filesystem with files
identified by GUIDs.  Those files include EFI drivers, ACPI tables,
DMI data and so on.  It is actually quite common for vendors to
also include device firmware on the Firmware Volume.  Apple is doing
this to ship firmware updates e.g. for the GMUX controller found on
dual GPU MacBook Pros.  If they want to update the controller's
firmware, they include it in a BIOS update, and an EFI driver checks
on boot if the firmware update for the controller is necessary and
if so, flashes it.

The firmware files you're looking for are almost certainly included
on the Firmware Volume as individual files.


What Hans implemented seems to have been for a specific x86 hack, best if we
confirm if indeed they are present on the Firmware Volume.


To be honest, I'm a bit skeptical about the firmware volume approach.
Tools like UEFITool[0] and uefi-firmware-parser[1] have existed for
years, still don't seem to reliably parse firmware images I see in the
wild, and have a fairly regular need for fixes.  These are tools
maintained by smart people who are making a real effort, and it still
looks pretty hard to do a good job that applies across a lot of
platforms.

So I'd rather use Hans's existing patches, at least for now, and if
someone is interested in hacking on making an efi firmware volume parser
for the kernel, switch them to that when such a thing is ready.

[0] g...@github.com:LongSoft/UEFITool.git
[1] g...@github.com:theopolis/uefi-firmware-parser.git


Rather than scraping
the EFI memory for firmware, I think it would be cleaner and more
elegant if you just retrieve the files you're interested in from
the Firmware Volume.

We're doing something similar with Apple EFI properties, see
58c5475aba67 and c9cc3aaa0281.

Basically what you need to do to implement this approach is:

* Determine the GUIDs used by vendors for the files you're interested
   in.  Either dump the Firmware Volume or take an EFI update as
   shipped by the vendor, then feed it to UEFIExtract:
   https://github.com/LongSoft/UEFITool
   
* Add the EFI Firmware Volume Protocol to include/linux/efi.h:

   
https://www.intel.com/content/dam/doc/reference-guide/efi-firmware-file-volume-specification.pdf

* Amend arch/x86/boot/compressed/eboot.c to read the files with the
   GUIDs you're interested in into memory and pass the files to the
   kernel as setup_data payloads.

* Once the kernel has booted, make the files you've retrieved
   available to device drivers as firmware blobs.


Happen to know if devices using Firmware Volumes also sign their firmware
and if hw checks the firmware at load time?


It varies on a per-device basis, of course.  Most new Intel machines as
of Haswell *should* be verifying their system firmware via Boot Guard,
which both checks an RSA signature and measures the firmware into the
TPM, but as with everything of this nature, there are certainly vendors
that screw it up. (I think AMD has something similar, but I'm really not
sure.)


Lukas, thank you for your suggestions on this, but I doubt that these
devices use the Firmware Volume stuff.

These are really cheap x86 Windows 10 tablets, everything about them is
simply hacked together by the manufacturer till it boots Windows10 and
then it is shipped to the customer without receiving any update
afterwards ever.

What you are describing sounds like significantly more work then
the vendor just embedding the firmware as a char firmware[] in their
EFI mouse driver.

That combined with Peter's worries about difficulties parsing the
Firmware Volume stuff, makes me believe that it is best to just
stick with my current approach as Peter suggests.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner  wrote:
> Now where the disagreement lies is the way how the uid/ring0 aspect is
tied
> to secure boot, which makes it impossible to be useful independent of
> Secure Boot.

It doesn't - you can pass a command line parameter that enables it, or your
bootloader can set the bootparams flag. I don't see a fundamental problem
with offering the opportunity to change it at runtime, other than that some
stuff that was previously initialised may have to be torn down. The reason
for having the UEFI boot stub *optionally* check the secure boot state
itself and make a policy decision (rather than having the signed bootloader
do so) is because the kernel can be launched directly by the firmware.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Thomas Gleixner]

On Wed, 4 Apr 2018, Peter Jones wrote:
> That is to say, as a result of the way malware has been written, our way
> of thinking about it is often that it's a way to build a boot loader for
> a malicious kernel, so that's how we wind up talking about it.  Are we
> concerned with malware stealing your data?  Yes, but Secure Boot is only
> indirectly about that.  It's primarily about denying the malware easy
> mechanisms to build a persistence mechanism.  The uid-0 != ring-0 aspect
> is useful independent of Secure Boot, but Secure Boot without it falls
> way short of accomplishing its goal.

I think we can all agree that

  The uid-0 != ring-0 aspect is useful independent of Secure Boot

There is probably resonable consensus about the second part of this
sentence as well:

   but Secure Boot without it falls way short of accomplishing its goal.

Now where the disagreement lies is the way how the uid/ring0 aspect is tied
to secure boot, which makes it impossible to be useful independent of
Secure Boot.

So the real question is, how can we make 'lockdown' usable and useful
without Secure Boot and at the same time not violate the constraints of
the Secure Boot scenario.

If we can agree on the above then I hope that we can focus on the technical
problems instead of arguing in circles.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] x86: Use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush()

[Sai Praneeth Prakhya]

From: Sai Praneeth 

When the platform supports PCID and if CONFIG_DEBUG_VM is enabled,
build_cr3_noflush() (called via switch_mm()) does a sanity check to see
if X86_FEATURE_PCID is set. Presently, build_cr3_noflush() uses
"this_cpu_has(X86_FEATURE_PCID)" to perform the check but this_cpu_has()
works only after SMP is initialized (i.e. per cpu cpu_info's should be
populated) and this happens to be very late in the boot process (during
rest_init).

As efi_runtime_services() are called during (early) kernel boot time
and run time, modify build_cr3_noflush() to use boot_cpu_has() all the
time. As suggested by Dave, this should be OK because all cpu's have
same capabilities anyways (for x86).

Without this change we see below warning during kernel boot.

WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/tlbflush.h:134
load_new_mm_cr3+0x114/0x170
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.16.0-02277-gbc16d4052f1a #1
Hardware name: System manufacturer System Product Name/Z170-K, BIOS 3301
02/08/2017
RIP: 0010:load_new_mm_cr3+0x114/0x170
RSP: :9b203e38 EFLAGS: 00010046
RAX:  RBX: 9b26f5a0 RCX: 
RDX:  RSI:  RDI: 9b20a000
RBP: 9b203e90 R08:  R09: 0f63eb29
R10: 9b203ea8 R11: c3292018 R12: 
R13: 9b2e1180 R14: 0001ee80 R15: 
FS:  () GS:968df6c0()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 968df6fff000 CR3: 0004261e6002 CR4: 000606b0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
switch_mm_irqs_off+0x267/0x590
switch_mm+0xe/0x20
efi_switch_mm+0x3e/0x50
efi_enter_virtual_mode+0x43f/0x4da
start_kernel+0x3bf/0x458
secondary_startup_64+0xa5/0xb0

Dave also suggested that we put a warning in this_cpu_has() if it's used
early in the boot process. This is still work in progress as it effects
MCE.

Signed-off-by: Sai Praneeth Prakhya 
Reported-by: Linus Torvalds 
Cc: Lee Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Dave Hansen 
---
 arch/x86/include/asm/tlbflush.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 84137c22fdfa..42e040859067 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -131,7 +131,12 @@ static inline unsigned long build_cr3(pgd_t *pgd, u16 asid)
 static inline unsigned long build_cr3_noflush(pgd_t *pgd, u16 asid)
 {
VM_WARN_ON_ONCE(asid > MAX_ASID_AVAILABLE);
-   VM_WARN_ON_ONCE(!this_cpu_has(X86_FEATURE_PCID));
+   /*
+* Use boot_cpu_has() instead of this_cpu_has() as this function
+* might be called during early boot. This should work even after
+* boot because all cpu's have same capabilities anyways.
+*/
+   VM_WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_PCID));
return __sme_pa(pgd) | kern_pcid(asid) | CR3_NOFLUSH;
 }
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Peter Jones]

On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett  wrote:
> > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski  wrote:
> >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett  wrote:
> >> > A kernel that allows users arbitrary access to ring 0 is just an
> >> > overfeatured bootloader. Why would you want secure boot in that case?
> >
> >> To get a chain of trust.  I can provision a system with some public
> >> keys, stored in UEFI authenticated variables, such that the system
> >> will only boot a signed image.  That signed image, can, in turn, load
> >> a signed (or hashed or otherwise verfified) kernel and a verified
> >> initramfs.  The initramfs can run a full system from a verified (using
> >> dm-verity or similar) filesystem, for example.  Now it's very hard to
> >> persistently attack this system.  Chromium OS does something very much
> >> like this, except that it doesn't use UEFI as far as I know.  So does
> >> iOS, and so do some Android versions.  None of this requires lockdown,
> >> or even a separation between usermode and kernelmode, to work
> >> correctly.  One could even do this on an MMU-less system if one really
> >> cared to.  More usefully, someone probably has done this using a
> >> unikernel.
> >
> > That's only viable if you're the only person with the ability to sign stuff
> > for your machine - the moment there are generic distributions that your
> > machine trusts, an attacker can use one as a bootloader to compromise your
> > trust chain.
> 
> 
> If you removed "as a bootloader", then I agree with that sentence.
> 
> Can someone please explain why the UEFI crowd cares so much about "as
> a bootloader"?  Once I'm able to install an OS (Linux kernel +
> bootloader, Windows embedded doodad, OpenBSD, whatever) on your
> machine, I can use your peripherals, read your data, write your data,
> see your keystrokes, use your network connection, re-flash your BIOS
> (at least as well as any OS can), run VMs, and generally own your
> system.  Somehow you all seem fine with all of this, except that the
> fact that I can chainload something else gives UEFI people the
> willies.
> 
> Can someone explain why?

There's no inherent difference, in terms of the trust chain, between
compromising it to use the machine as a toaster or to run a botnet - the
trust chain is compromised either way.  But you're much more likely to
notice if your desktop starts producing bread products than if it hides
some malware and keeps on booting, and the second one is much more
attractive to attackers anyway.

The reason we talk about it as a bootloader is because of the model
employed by malware.  I'm sure you know that one kind of malware that
exists in the wild, a so-called "boot kit", operates by modifying a
kernel during load (or on disk before loading) so that it has some
malicious payload, like exfiltrating user data or allowing a way to
install software that the kernel hides or *whatever*, and incorporating
some way to achieve relative persistence on the system - for example
hiding the real boot settings and loading a kernel with a different than
normal initramfs that loads an exploit before continuing with a normal
looking boot.

As Kees has pointed out, the lockdown portion of this is about
separating uid-0 from ring-0.  There are a lot of reasons to want to do
that, of course.  But the reason Secure Boot exists, and ultimately the
reason we started trying to do this, is so you can't build the
persistence mechanism for a boot kit by using a trusted kernel to
springboard into a modified one, even if it's the same kernel just
modified before kexec.  If you can do that, you can use that to build
the persistence mechanism in a boot kit.

That is to say, as a result of the way malware has been written, our way
of thinking about it is often that it's a way to build a boot loader for
a malicious kernel, so that's how we wind up talking about it.  Are we
concerned with malware stealing your data?  Yes, but Secure Boot is only
indirectly about that.  It's primarily about denying the malware easy
mechanisms to build a persistence mechanism.  The uid-0 != ring-0 aspect
is useful independent of Secure Boot, but Secure Boot without it falls
way short of accomplishing its goal.

--
  Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

[Peter Jones]

On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:
> On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> > > I asked Peter Jones for suggestions how to extract this during boot and
> > > he suggested seeing if there was a copy of the firmware in the
> > > EFI_BOOT_SERVICES_CODE memory segment, which it turns out there is.
> > > 
> > > My patch to add support for this contains a table of device-model (dmi
> > > strings), firmware header (first 64 bits), length and crc32 and then if
> > > we boot on a device-model which is in the table the code scans the
> > > EFI_BOOT_SERVICES_CODE for the prefix, if found checks the crc and
> > > caches the firmware for later use by request-firmware.
> > > 
> > > So I just do a brute-force search for the firmware, this really is hack,
> > > nothing standard about it I'm afraid. But it works on 4 different x86
> > > tablets I have and makes the touchscreen work OOTB on them, so I believe
> > > it is a worthwhile hack to have.
> > 
> > The EFI Firmware Volume contains a kind of filesystem with files
> > identified by GUIDs.  Those files include EFI drivers, ACPI tables,
> > DMI data and so on.  It is actually quite common for vendors to
> > also include device firmware on the Firmware Volume.  Apple is doing
> > this to ship firmware updates e.g. for the GMUX controller found on
> > dual GPU MacBook Pros.  If they want to update the controller's
> > firmware, they include it in a BIOS update, and an EFI driver checks
> > on boot if the firmware update for the controller is necessary and
> > if so, flashes it.
> > 
> > The firmware files you're looking for are almost certainly included
> > on the Firmware Volume as individual files.
> 
> What Hans implemented seems to have been for a specific x86 hack, best if we
> confirm if indeed they are present on the Firmware Volume.

To be honest, I'm a bit skeptical about the firmware volume approach.
Tools like UEFITool[0] and uefi-firmware-parser[1] have existed for
years, still don't seem to reliably parse firmware images I see in the
wild, and have a fairly regular need for fixes.  These are tools
maintained by smart people who are making a real effort, and it still
looks pretty hard to do a good job that applies across a lot of
platforms.

So I'd rather use Hans's existing patches, at least for now, and if
someone is interested in hacking on making an efi firmware volume parser
for the kernel, switch them to that when such a thing is ready.

[0] g...@github.com:LongSoft/UEFITool.git
[1] g...@github.com:theopolis/uefi-firmware-parser.git

> > Rather than scraping
> > the EFI memory for firmware, I think it would be cleaner and more
> > elegant if you just retrieve the files you're interested in from
> > the Firmware Volume.
> > 
> > We're doing something similar with Apple EFI properties, see
> > 58c5475aba67 and c9cc3aaa0281.
> > 
> > Basically what you need to do to implement this approach is:
> > 
> > * Determine the GUIDs used by vendors for the files you're interested
> >   in.  Either dump the Firmware Volume or take an EFI update as
> >   shipped by the vendor, then feed it to UEFIExtract:
> >   https://github.com/LongSoft/UEFITool
> >   
> > * Add the EFI Firmware Volume Protocol to include/linux/efi.h:
> >   
> > https://www.intel.com/content/dam/doc/reference-guide/efi-firmware-file-volume-specification.pdf
> > 
> > * Amend arch/x86/boot/compressed/eboot.c to read the files with the
> >   GUIDs you're interested in into memory and pass the files to the
> >   kernel as setup_data payloads.
> > 
> > * Once the kernel has booted, make the files you've retrieved
> >   available to device drivers as firmware blobs.
> 
> Happen to know if devices using Firmware Volumes also sign their firmware
> and if hw checks the firmware at load time?

It varies on a per-device basis, of course.  Most new Intel machines as
of Haswell *should* be verifying their system firmware via Boot Guard,
which both checks an RSA signature and measures the firmware into the
TPM, but as with everything of this nature, there are certainly vendors
that screw it up. (I think AMD has something similar, but I'm really not
sure.)

-- 
  Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Justin Forbes]

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski  wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett  wrote:
>> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o  wrote:
>>
>>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>>> > Theodore Y. Ts'o  wrote:
>>> >
>>> > > Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
>>> > > isn't this a problem for people who are fearful that Linux could be
>>> > > used as part of a Windows boot virus in a Secure UEFI context?
>>> >
>>> > Lockdown mode restricts kexec to booting an authorised image (where the
>>> > authorisation may be by signature or by IMA).
>>
>>> If that's true, then Matthew's assertion that lockdown w/o secure boot
>>> is insecure goes away, no?
>>
>> If you don't have secure boot then an attacker with root can modify your
>> bootloader or kernel, and on next boot lockdown can be silently disabled.
>
> This has been rebutted over and over and over.  Secure boot is not the
> only verified boot mechanism in the world.  Other, better, much more
> auditable, and much simpler mechanisms have been around for a long,
> long time.
>
That is certainly the case, and one of the main reasons for the
secureboot patchset being split out and lockdown taking a different
name. The problem is, right now, secure boot is the only thing using
lockdown. I certainly wouldn't go through any effort to tie into it
with any other mechanism knowing that this patch set has been delayed
upstream for years. I would hope and expect that once lockdown is in
mainline, other verified boot mechanisms would leverage it as well.

>>> The fact that this Verified Boot on, lockdown off causes trouble
>>> points to a clear problem.   User owns the hardware they should have
>>> the right to defeat secureboot if they wish to.
>>
>> Which is why Shim allows you to disable validation if you prove physical
>> user presence.
>
> And that's a giant hack.  The actual feature should be that a user
> proves physical presence and thus disables lockdown *without*
> disabling verification.
>
> --Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski  wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett  wrote:
> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
disabled.

> This has been rebutted over and over and over.  Secure boot is not the
> only verified boot mechanism in the world.  Other, better, much more
> auditable, and much simpler mechanisms have been around for a long,
> long time.

Right and if you *know* that you're in that situation then you either turn
it on in bootparams from the verified bootloader (which we can't do in UEFI
because the *firmware* can be the bootloader thanks to the EFI boot stub)
or you enable it from userland later (I can't remember if this version of
the patchset provides that functionality, but a previous one did).

> > Which is why Shim allows you to disable validation if you prove physical
> > user presence.

> And that's a giant hack.  The actual feature should be that a user
> proves physical presence and thus disables lockdown *without*
> disabling verification.

That's a completely reasonable feature request.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding  wrote:
> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett  wrote:

> > There are four cases:
> >
> > Verified Boot off, lockdown off: Status quo in distro and mainline
kernels
> > Verified Boot off, lockdown on: Perception of security improvement
that's
> > trivially circumvented (and so bad)
> > Verified Boot on, lockdown off: Perception of security improvement
that's
> > trivially circumvented (and so bad), status quo in mainline kernels
> > Verified Boot on, lockdown on: Security improvement, status quo in
distro
> > kernels
> >
> > Of these four options, only two make sense. The most common
implementation
> > of Verified Boot on x86 platforms is UEFI Secure Boot,

> Stop right there.   Verified boot does not have to be UEFI secureboot.
>You could be using a uboot verified boot or
> https://www.coreboot.org/git-docs/Intel/vboot.html  google vboot.
> Neither of these provide flags to kernel to say they have been
> performed.

They can be modified to set the appropriate bit in the bootparams - the
reason we can't do that in the UEFI case is that Linux can be built as a
UEFI binary that the firmware execute directly, and so the firmware has no
way to set that flag.

> Now Verified Boot on, lockdown off.   Insanely this can be required in
> diagnostic on some embedded platform because EFI secureboot does not
> have a off switch.These are platforms where they don't boot if
> they don't have a PK and KEK set installed.  Yes some of these is jtag
> the PK and KEK set in.

> The fact that this Verified Boot on, lockdown off causes trouble
> points to a clear problem.   User owns the hardware they should have
> the right to defeat secureboot if they wish to.

Which is why Shim allows you to disable validation if you prove physical
user presence.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[Jann Horn]

+a...@kernel.org

On Wed, Apr 4, 2018 at 6:17 PM, David Howells  wrote:
> Andy Lutomirski  wrote:
[...]
>> 3. All the bpf and tracing stuf, etc, gets changed so it only takes
>> effect when LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY is set.
>
> Uh, no.  bpf, for example, can be used to modify kernel memory.

I'm pretty sure bpf isn't supposed to be able to modify arbitrary
kernel memory. AFAIU if you can use BPF to write to arbitrary kernel
memory, that's a bug; with CAP_SYS_ADMIN, you can read from userspace,
write to userspace, and read from kernelspace, but you shouldn't be
able to write to kernelspace.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o  wrote:

> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
> > Theodore Y. Ts'o  wrote:
> >
> > > Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> > > isn't this a problem for people who are fearful that Linux could be
> > > used as part of a Windows boot virus in a Secure UEFI context?
> >
> > Lockdown mode restricts kexec to booting an authorised image (where the
> > authorisation may be by signature or by IMA).

> If that's true, then Matthew's assertion that lockdown w/o secure boot
> is insecure goes away, no?

If you don't have secure boot then an attacker with root can modify your
bootloader or kernel, and on next boot lockdown can be silently disabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 5:57 AM Theodore Y. Ts'o  wrote:

> On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends
up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatures are mostly worthless in the non-lockdown case because
you
> > can just grab the sig_enforce symbol address and then kexec a preamble
that
> > flips it back to N regardless of the kernel config.

> Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?

It does - I was talking about the non-lockdown case. In the lockdown case
you can only kexec images you trust, so there's no problem. Red Hat have
been shipping a signed kdump image for years.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Matthew Garrett]

On Wed, Apr 4, 2018 at 9:09 AM Linus Torvalds

wrote:

> On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett  wrote:
> >
> > Bear in mind that I'm talking about defaults here

> Mattyhew, I really want you to look yourself in the mirror.

> Those defaults are really horrible defautls for real technical reasons.

> You asked me why when I questioned this, but then when I replied, you
> entirely ignored it.

> So let me repeat: the defaults are *horrible*. They are horrible for a
> very simple reason: kernel behavior changes that depend on some subtle
> boot difference are truly nasty to debug, and nasty to get coverage
> for.

They're the defaults that the mainline distros have been shipping for
years. So what are you actually asking for here? If you're saying that it
should be possible to enable the lockdown functionality even in the absence
of any kind of verified boot, then yes, I agree - I just think it makes a
poor distro default to have that be the case out of the box. If you're
saying that it should be possible to disable the lockdown functionality
even in the presence of any kind of verified boot, then yes, I agree - I
just think it makes a poor distro default to have that be the case out of
the box. You're arguing against a patch that provides the default policy
that distros want to ship.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[David Howells]

Andy Lutomirski  wrote:

> Since this thread has devolved horribly, I'm going to propose a solution.
> 
> 1. Split the "lockdown" state into three levels:  (please don't
> bikeshed about the names right now.)
> 
> LOCKDOWN_NONE: normal behavior
> 
> LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to
> kernel memory
> 
> LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY: kernel tries to keep root from
> reading or writing kernel memory.

In theory, it's good idea, but in practice it's not as easy to implement as I
think you think.

Let me list here the things that currently get restricted by lockdown:

 (1) Manipulation of devices to access the kernel image:

- Ioports & ioperm
- /dev/ports
- /dev/mem
- PCI Bar
- Some debugfs files
- pcmcia_cis
- Driver hardware parameters
  - ISA drivers
  - TIOCSSERIAL
  - SCSI EATA driver
- testmmiotrace
- firmware

 (2) Direct kernel memory modification:

- /dev/mem
- /dev/kmem
- bpf
- kprobes

 (3) Direct kernel memory reading:

- /dev/mem
- /dev/kmem
- /dev/kcore
- bpf
- kprobes
- perf

 (4) Indirect kernel access:

- Modules
- MSRs
- Suspend to disk
- ACPI (custom_method, RSDP, table override, error injection)

 (5) Kexec.

Note that /dev/mem can be used to access MMIO devices (I'm not sure about
/dev/kmem, though).  Even reads through /dev/mem can do this.  I'm not sure
whether that's sufficient to actually affect a modification, though.

Debugfs is particularly icky.  It contains at least a couple of thousand
files, a few of which provide direct access to hardware, some of which change
driver behaviour and some of which just give information.  Auditing that pile
isn't something I really want to have to do.  I'd rather just turn the whole
lot off, but got persuaded otherwise by people who have been using it to
provide mechanisms that programs rely on - hence the only allow files that
have 0444 (and even that is iffy as some of these files have side effects and
write ops anyway).

> 2. The kexec protocol gets a new flag min_lockdown_level.  A kexeced
> kernel will boot with at least that lockdown level regardless of its
> configuration.  kexec sets min_lockdown_level to the running kernels'
> lockdown_level.  Some future API could allow kexec with a higher
> min_lockdown_level.  An even fancier future API could allow a
> LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY kernel to kexec with
> min_lockdown_level == LOCKDOWN_PROTECT_INTEGRITY if there's some
> mechanism that guarantees that memory gets zeroed in the process.

Note that on x86 we already have an allocated flag for passing the secure boot
flag from kexec/bootloader to the kernel being booted, and what you're
proposing ought to be redundant.  See boot_params::secure_boot.

> 3. All the bpf and tracing stuf, etc, gets changed so it only takes
> effect when LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY is set.

Uh, no.  bpf, for example, can be used to modify kernel memory.  I think only
the following are safe from being able to talk directly to devices:

/dev/kmem (O_RDONLY only)
/dev/kcore
perf
some debugfs files

> This removes a giant annoyance on distro kernels that are likely to want to
> enable LOCKDOWN_PROTECT_INTEGRITY.

*shrug* Distros have been running with the full set for a while.  I haven't
seen many complaints.

> If you load a key into the kernel, and you want to keep that key safe, you
> can enable LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY at that time.  After all,
> if root is compromised before that, root can just remember a copu of the key
> in user memory or email it to someone.

If your key needs to be truly protected, it should never be seen unencrypted
in userspace, rather it should be decrypted in the TPM and then retained in
kernel memory only.

> ...
> 6. There's a way to *decrease* the lockdown level below the configured
> value.  (This ability itself may be gated by a config option.)
> Choices include a UEFI protected variable,

By turning secure boot off, maybe?

> an authenticated flag passed by the bootloader,

Authenticated how?  How do you stop the running system from passing this to
the bootloader next time it is run?  I guess you're thinking of a bootloader
"command" that can only be passed by someone sat at a keyboard and never read
from the config file.

> and even just some special flag in the boot handoff protocol.

We already have that with secure boot.

> It would be really quite useful for a user to be able to ask their
> bootloader to reduce the lockdown level for the purpose of a particular boot
> for debugging.

This I shall grant you - but you have to be able to prevent an attacker inside
the system from making use of it.  There's a SysRq provided to drop out of
lockdown mode - in theory only usable if you're sat at a 

Re: [GIT PULL] Kernel lockdown for secure boot

[Linus Torvalds]

On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett  wrote:
>
> Bear in mind that I'm talking about defaults here

Mattyhew, I really want you to look yourself in the mirror.

Those defaults are really horrible defautls for real technical reasons.

You asked me why when I questioned this, but then when I replied, you
entirely ignored it.

So let me repeat: the defaults are *horrible*. They are horrible for a
very simple reason: kernel behavior changes that depend on some subtle
boot difference are truly nasty to debug, and nasty to get coverage
for.

And this "subtle boot difference" is really bad because it's a
difference that has a particularly bad pattern: pretty much not a
single mainline kernel developer will have secure boot enabled,
exactly because it's so inconvenient for testing.

So what does that mean?

It means that the default is *actively* bad for kernel development. It
means that the people who do kernel development will not be testing
the behavior that "normal" users will actually see.

If you do not see why that is a HORRIBLY BAD THING, I don't know what to say.

Seriously. It's a nasty nasty default behavior. It's absolutely
disastrously wrong.

And then when people call you out on this bad linkage of this feature
with secure boot, you spent a *LOT* of time being dishonest about it.
Instead of answeing a simple technical question, you did just about
everything you could to avoid answering it.

You initially turned the question back into a "Why would you want to?"
rather than just answering.

Then you spent a whole lot of time coming up with completely wrong
excuses that had no actual technical reason for them.

And even now, you're trying to ignore the question, and the REASON for
the question.

See above: the default is really horrendously bad, and is just about
the *worst* default you could ever pick from a kernel development
angle.

So when a kernel developer - both me and Andy - ask you about the
reason for that HORRIBLY BAD default, then you had better stop dancing
around the issue, and be honesy.

Instead, you bring up complete red herrings:

> If a user has a configuration where you're able to verify that userspace
> has some degree of protection (eg, disk encryption keys are in the TPM and
> won't unseal if someone's switched out the kernel) then it's reasonable for
> userland (or a kernel command line option) to enable the functionality.

This line of arguyment of yours ends up STILL being complete and utter garbage.

There is not a single shred of evidence that there is some kind of
"reasonable to enable the functionality" based on completely unrelated
matters.

See above on why such stupid linkages are a bad bad idea. Absolutely
*ANY* time you make that decision silently for a user, you will just
be doing the wrong thing.

You will do the wrong thing for security, but equally importantly, you
will be doing the wrong thing just for *development* and *test
coverage*.

> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can just grab the sig_enforce symbol address and then kexec a preamble that
> flips it back to N regardless of the kernel config.

Honestyly, all of your arguments are made up shit.

This argument, for example, is just a complete red herring.

Do you want to protect against somebody flipping "sig_enforce"? Makes
perfect sense to me.

Then WHY is that not just a config option for extra hardening?
Seriously. I'd use it. I have never *ever* felt the need to switch
"sig_enforce" off, and I always build with MODULE_SIG_FORCE and
MODULE_SIG_ALL.

Getting rid of that switch entirely for security reasons sounds just
_fine_ to me.

So you use these *stupid* things as "arguments" for why you think you
want to do something. But you're putting the cart before the horse:
you have a particular end result you want to get to, and then you make
up arguments for why you want to get there.

Seriously, go back to that coverage and testing issue. Go back to the
*fundamental* technical issue that we want kernel developers to
actually *test* the code that users are running.

*Gasp*.

Yeah, I know, it's a completely radical idea, but it's true. Having
developers test and run the code actual real humans are using is a
truly revolutionary concept in security too.

> I'm making this argument from the perspective of "What should the kernel do
> when it has no additional information".

And I'm telling you that you're ignoring the fact that you picked a
truly horrendously shitty default.

And then you spent a *lot* of time giving misleading and bad
information about why you picked that shitty default, and instead just
questioning the people who asked you an actual and really simply
technical question.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the 

An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

[Andy Lutomirski]

Since this thread has devolved horribly, I'm going to propose a solution.

1. Split the "lockdown" state into three levels:  (please don't
bikeshed about the names right now.)

LOCKDOWN_NONE: normal behavior

LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to
kernel memory

LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY: kernel tries to keep root from
reading or writing kernel memory.

2. The kexec protocol gets a new flag min_lockdown_level.  A kexeced
kernel will boot with at least that lockdown level regardless of its
configuration.  kexec sets min_lockdown_level to the running kernels'
lockdown_level.  Some future API could allow kexec with a higher
min_lockdown_level.  An even fancier future API could allow a
LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY kernel to kexec with
min_lockdown_level == LOCKDOWN_PROTECT_INTEGRITY if there's some
mechanism that guarantees that memory gets zeroed in the process.

3. All the bpf and tracing stuf, etc, gets changed so it only takes
effect when LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY is set.  This
removes a giant annoyance on distro kernels that are likely to want to
enable LOCKDOWN_PROTECT_INTEGRITY.  If you load a key into the kernel,
and you want to keep that key safe, you can enable
LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY at that time.  After all, if
root is compromised before that, root can just remember a copu of the
key in user memory or email it to someone.

4. There's a kernel config option for the default lockdown level.
This operates completely independently of secure boot.

5. There's a command line option to increase the lockdown level above
the default level.  No particular authentication is needed for this
option to work.

6. There's a way to *decrease* the lockdown level below the configured
value.  (This ability itself may be gated by a config option.)
Choices include a UEFI protected variable, an authenticated flag
passed by the bootloader, and even just some special flag in the boot
handoff protocol.  It would be really quite useful for a user to be
able to ask their bootloader to reduce the lockdown level for the
purpose of a particular boot for debugging.  I read the docs on
mokutil --disable-validation, and it's quite messy.  Let's have a way
to do this that is mostly independent of the particular firmware in
use.

I can imagine a grub option that decreases lockdown level along with a
rule that grub will *not* load that option from its config, for
example.

7. kexec does not attempt to think about "secure boot" at all.
They're totally separate.

What do you all think?  I think that this checks basically all the
boxes, is a lot more user friendly than the current patchset or what
distros do, and actually makes some sense from a security perspective.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> > Andy Lutomirski  wrote:
> >
> >> As far as I can tell, what's really going on here is that there's a
> >> significant contingent here that wants to prevent Linux from
> >> chainloading something that isn't Linux.
> >
> > You have completely the wrong end of the stick.  No one has said that or
> > even implied that.  You are alleging dishonesty on our part.
> 
> I'm alleging that the idea that Linux seems some particular policy to
> avoid being blacklisted keeps being brought up as a justification for
> these patches.

No, you were alleging that "[we want] to prevent Linux from chainloading
something that isn't Linux.".

This is not true - at least, it's not true on my part; I cannot speak for what
other people may think privately.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Andy Lutomirski]

I've reordered your email to make my email more coherent.

> On Apr 4, 2018, at 1:05 AM, David Howells  wrote:
>

>
> What we *have* said is that *if* we want to pass the secure boot state across
> kexec, then we have to make sure that:
>

What do you even mean "pass the secure boot state across kexec"?  All
I can come up with is that you want a kexeced Linux kernel to also be
passed a flag saying "I was secure booted" and to enable or disable
lockdown accordingly.  Let's consider the cases:

1. First kernel is verified (secure boot or otherwise) and locked
down.  Certainly that lock down needs to enforce that the next kernel
in the chain is locked down, otherwise lockdown gets defeated.

2. First kernel is not verified but is locked down.  It still needs to
enforce that the next kernel is verified and locked down, otherwise
lockdown gets defeated.

3. First kernel is verified but not locked down.  There's very little
point in trying to force the next kernel to be locked down.

4. First kernel is neither verified nor locked down.  There's still no
point in trying to force the next kernel to be locked down.

Isn't the right solution to have a flag saying "force lockdown" that
kexec can pass to the child kernel?  A locked down parent kernel would
refuse to load an unsigned child kernel and would always set that
flag.

> Andy Lutomirski  wrote:
>
>> As far as I can tell, what's really going on here is that there's a
>> significant contingent here that wants to prevent Linux from
>> chainloading something that isn't Linux.
>
> You have completely the wrong end of the stick.  No one has said that or even
> implied that.  You are alleging dishonesty on our part.

I'm alleging that the idea that Linux seems some particular policy to
avoid being blacklisted keeps being brought up as a justification for
these patches.  And, in fact, you bring it up again right here:

>
> And if someone tampers with the aim of breaking, say, Windows, then someone,
> e.g.  Microsoft, might blacklist the shim.

In other words, if you chainload an intentionally corrupted copy of
Windows, you get blacklisted?  This sounds awfully like what I said
upthread.  Is this actually a real concern?  Greg seems quite
convinced that it isn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Greg Kroah-Hartman]

On Wed, Apr 04, 2018 at 09:34:11AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > > > What I'm afraid of is this turning into a "security" feature that ends 
> > > > up
> > > > being circumvented in most scenarios where it's currently deployed - eg,
> > > > module signatures are mostly worthless in the non-lockdown case because 
> > > > you
> > > > can just grab the sig_enforce symbol address and then kexec a preamble 
> > > > that
> > > > flips it back to N regardless of the kernel config.
> > > 
> > > Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> > > isn't this a problem for people who are fearful that Linux could be
> > > used as part of a Windows boot virus in a Secure UEFI context?
> > 
> > Because no one is afraid of that :)
> 
> Well, this is the excuse used by Windows.

Really?  Every time I have tried to actually follow up on this
statement, it turns into an urban myth.  If you have proof of this,
please let me know, otherwise I am going to keep saying it is false.

> Some more cynical people
> believe it's really an anti-competitvie thing, but we should
> acknowledge this is what is causing the fear that some distros have
> that their UEFI secure boot certs will be revoked by Microsoft if they
> don't have this crazy lockdown enforcement for UEFI Secure Boot.

Unsubstantiated fear of relying on another company's signing key to
suddenly stop working is worrying.  But it's just that, fear, and not
anything that is actually true.  We have a working shim binary that is
signed, in use by all distros and other operating systems (community and
corporate).  To revoke that key now would be insane on a variety of
levels.

So let's stop playing the myth and fear card people, and focus on the
actual facts here.

> And I would all be for having the Kconfig description says, "This
> config option is only needed by distros who are fearful of Microsoft
> revoking their UEFI secure boot certificate."

Again, no fear please, facts only.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Theodore Y. Ts'o  wrote:

> > Lockdown mode restricts kexec to booting an authorised image (where the
> > authorisation may be by signature or by IMA).
> 
> If that's true, then Matthew's assertion that lockdown w/o secure boot
> is insecure goes away, no?

No.

Lockdown prevents the running kernel from being modified (or, at least, that's
the hope).

But it doesn't do anything to prevent the kernel being modified before
lockdown is engaged.

We are trying to use secureboot to protect the system to the point that
lockdown can take over.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Theodore Y. Ts'o]

On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
> Theodore Y. Ts'o  wrote:
> 
> > Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part of a Windows boot virus in a Secure UEFI context?
> 
> Lockdown mode restricts kexec to booting an authorised image (where the
> authorisation may be by signature or by IMA).

If that's true, then Matthew's assertion that lockdown w/o secure boot
is insecure goes away, no?

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Theodore Y. Ts'o]

On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > > What I'm afraid of is this turning into a "security" feature that ends up
> > > being circumvented in most scenarios where it's currently deployed - eg,
> > > module signatures are mostly worthless in the non-lockdown case because 
> > > you
> > > can just grab the sig_enforce symbol address and then kexec a preamble 
> > > that
> > > flips it back to N regardless of the kernel config.
> > 
> > Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part of a Windows boot virus in a Secure UEFI context?
> 
> Because no one is afraid of that :)

Well, this is the excuse used by Windows.  Some more cynical people
believe it's really an anti-competitvie thing, but we should
acknowledge this is what is causing the fear that some distros have
that their UEFI secure boot certs will be revoked by Microsoft if they
don't have this crazy lockdown enforcement for UEFI Secure Boot.

So how about this as a compromise.  We can have a config option for
the behavior that those distros (and Matthew) want, and we can have
separate config options that turn things on in what others would say
is a more rational way.

And I would all be for having the Kconfig description says, "This
config option is only needed by distros who are fearful of Microsoft
revoking their UEFI secure boot certificate."

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Theodore Y. Ts'o  wrote:

> Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?

Lockdown mode restricts kexec to booting an authorised image (where the
authorisation may be by signature or by IMA).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Mike Galbraith]

On Wed, 2018-04-04 at 08:57 -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatures are mostly worthless in the non-lockdown case because you
> > can just grab the sig_enforce symbol address and then kexec a preamble that
> > flips it back to N regardless of the kernel config.
> 
> Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?
> 
> If lockdown simply included a requirement for a signed kernel for
> kexec --- and if kernel signing aren't available, to simply not alow
> kexec, wouldn't that take care of this case?
> 
> This wouldn't even be all that much of a burden for non-distro users
> with lockdown enabled, since in my experience outside of enterprise
> and data center use cases, kexec isn't used...

Lots of folks use kdump, ergo kexec.

-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Greg Kroah-Hartman]

On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatures are mostly worthless in the non-lockdown case because you
> > can just grab the sig_enforce symbol address and then kexec a preamble that
> > flips it back to N regardless of the kernel config.
> 
> Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?

Because no one is afraid of that :)

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Theodore Y. Ts'o]

On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can just grab the sig_enforce symbol address and then kexec a preamble that
> flips it back to N regardless of the kernel config.

Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
isn't this a problem for people who are fearful that Linux could be
used as part of a Windows boot virus in a Secure UEFI context?

If lockdown simply included a requirement for a signed kernel for
kexec --- and if kernel signing aren't available, to simply not alow
kexec, wouldn't that take care of this case?

This wouldn't even be all that much of a burden for non-distro users
with lockdown enabled, since in my experience outside of enterprise
and data center use cases, kexec isn't used --- and in fact, very
often kexec doesn't even work outside of a very carefully selected and
bug-fixed set of device drivers.  (It often doesn't work in non-distro
kernels because very few upstream developers really care about kexec.)

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

[Daniel Kiper]

On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
> On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
> > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:

[...]

> > > This looks like a bad idea: you're duplicating the secure boot
> > > check in
> > >
> > > drivers/firmware/efi/libstub/secureboot.c
> > >
> > > Which is an implementation of policy.  If we have to have policy in
> > > the kernel, it should really only be in one place to prevent drift;
> > > why can't you simply use the libstub efi_get_secureboot() so we're
> > > not duplicating the implementation of policy?
> >
> > Well, here is the first version of this patch:
> > https://lkml.org/lkml/2018/1/9/496 Ard did not like it. I was not
> > happy too. In general both approaches are not perfect. More you can
> > find in the discussion around this patchset. If you have better idea
> > how to do that I am happy to implement it.
>
> One way might be simply to have the pre exit-boot-services code lay
> down a variable containing the state which you pick up, rather than you

Do you mean variable in kernel proper or something like that? If yes this
is not possible. EFI Linux stub is not executed in Xen dom0. All UEFI
infrastructure is owned and operated by Xen. Dom0 kernel can access some
stuff in UEFI, including variables, via hypercall. However, when dom0
runs only UEFI runtime services are available.

> calling efi code separately and trying to use the insecure RT

I am not sure why they are insecure.

> variables.  That way there's a uniform view of the internal kernel
> secure boot state that everyone can use.

That would be perfect but I have a feeling that in form proposed above
it is not possible.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Greg Kroah-Hartman]

On Wed, Apr 04, 2018 at 12:19:35AM +, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski  wrote:
> 
> > if your secure boot-enabled bootloader can't prevent a bad guy from
> > using malicious kernel command line parameters, then fix it.
> 
> How is a bootloader supposed to know what the set of malicious kernel
> command line parameters is?

It wouldn't, it, if it really were "secure", would not allow any command
line parameters to be changed.  Which is exactly what those bootloaders
who "claim" to be secure do.

And, just to butt in here, there is no requirement that I have ever
heard of from anyone at UEFI or Microsoft that this type of "kernel
feature" is a requirement to allow for a bootloader/kernel to be signed
with their key.  So that should take the "politics" reason off the table
here, if people thought that somehow it was even a viable reason...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> As far as I can tell, what's really going on here is that there's a
> significant contingent here that wants to prevent Linux from
> chainloading something that isn't Linux.

You have completely the wrong end of the stick.  No one has said that or even
implied that.  You are alleging dishonesty on our part.

What we *have* said is that *if* we want to pass the secure boot state across
kexec, then we have to make sure that:

 (1) no one tampers with the intermediate kernel between boot and kexec
 otherwise the secure boot state is effectively invalidated, and

 (2) the image that gets kexec'ed is trusted.

Remember: you cannot know (2) if you don't have (1).

And if someone tampers with the aim of breaking, say, Windows, then someone,
e.g.  Microsoft, might blacklist the shim.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[Peter Dolding]

.

On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett  wrote:

> There are four cases:
>
> Verified Boot off, lockdown off: Status quo in distro and mainline kernels
> Verified Boot off, lockdown on: Perception of security improvement that's
> trivially circumvented (and so bad)
> Verified Boot on, lockdown off: Perception of security improvement that's
> trivially circumvented (and so bad), status quo in mainline kernels
> Verified Boot on, lockdown on: Security improvement, status quo in distro
> kernels
>
> Of these four options, only two make sense. The most common implementation
> of Verified Boot on x86 platforms is UEFI Secure Boot,

Stop right there.   Verified boot does not have to be UEFI secureboot.
  You could be using a uboot verified boot or
https://www.coreboot.org/git-docs/Intel/vboot.html  google vboot.
Neither of these provide flags to kernel to say they have been
performed.

So Verified boot looking off to kernel yet lockdown needing to be on
is one very valid combination and must be supported because the Linux
kernel does not always know when it verified boot environment.  When
the Linux kernel thinks verified boot is off it may not be trivial to
circumvent.

Now Verified Boot on, lockdown off.   Insanely this can be required in
diagnostic on some embedded platform because EFI secureboot does not
have a off switch.These are platforms where they don't boot if
they don't have a PK and KEK set installed.  Yes some of these is jtag
the PK and KEK set in.

The fact that this Verified Boot on, lockdown off causes trouble
points to a clear problem.   User owns the hardware they should have
the right to defeat secureboot if they wish to.

In fact the issue that you can not install a KEK per operating system
installed shows a problem as well.

So all OS use the same KEK for their installers and then you have all
non Microsoft in a lot of cases the same KEK for booting OS.   Any of
these bootloaders/kernels with defect will end up with the security
being exactly like Verified Boot on, lockdown off.  Remember attackers
will send around copies of what ever they need to so they can breach a
system so they find a defective solution some where they will ship it
everywhere.   Attackers that secureboot is attempted to prevent are
criminal anyhow what is a little bit of copyright violation to them..
  So when the current UEFI design is security theatre there should not
be any special effort to support it.

If UEFI was not security theatre there would be a clean way for people
install and setup up their systems to list what operating system KEK
should be accepted so allowing attack surface area to be minimised and
the damaged form any flawed implementation to also be limited.   This
way end users could opt in or out of operating systems based on
security.   If user has opted out of all operating systems doing
Verified Boot on, lockdown off: those are not a threat.   Also any OS
with defective kernel or bootloader that the system has not allowed
the KEK of would also not be a threat.

Really I see no reason to be bending over in the Linux kernel for UEFI
secureboot.   You list all 4 types need to exist for different usage
case of the Linux kernel.   The fact UEFI secureboot currently is
implemented on x86 does not handle the fact all 4 use cases need to
exist is really a issue with UEFI Secureboot that needs to be fixed by
those designing UEFI for the future.

Allowing the kernel to be configured the 4 different ways does not
mean a party like Microsoft has to sign off on everything the Linux
kernel can do.   Its not like android/IOT vendors have to bow to
Microsoft.

The Linux kernel should not show favouritism.   This does mean that
all 4 modes should be in the kernel configuration options.

Matthew Garrett your mistake is that only 2 are valid when all 4 are
valid in different usage cases.Circumventing security is sometimes
required  accepting that case is hard for some people.   Of course
when a party need perform circumventing security the fact that it
currently gives out the keys to world of UEFI systems is a very big
security design flaw in UEFI.

Why should the Linux kernel contain code to work around defective
design of UEFI and limit what users not using UEFI and using UEFI can
do?

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html