lkml.org 
[lkml]   [2022]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux DRTM on UEFI platforms
    On 7/7/22 23:36, Brendan Trotter wrote:
    > Hi,
    >
    > On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
    > <dpsmith@apertussolutions.com> wrote:
    >> On 7/5/22 20:03, Brendan Trotter wrote:
    >> Greetings!
    >>
    >> Not sure why I got dropped from distro, but no worries.
    >>
    >>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
    >>> <dpsmith@apertussolutions.com> wrote:
    >>>> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59,
    >>>> To help provide clarity, consider the following flows for comparison,
    >>>>
    >>>> Normal/existing efi-stub:
    >>>> EFI -> efi-stub -> head_64.S
    >>>>
    >>>> Proposed secure launch:
    >>>> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S
    >>>
    >>> For more clarity; the entire point is to ensure that the kernel only
    >>> has to trust itself and the CPU/TPM hardware (and does not have to
    >>> trust a potentially malicious boot loader)..Any attempt to avoid a
    >>> one-off solution for Linux is an attempt to weaken security.
    >>
    >> Please elaborate so I might understand how this entrypoint allows for
    >> the kernel to only trust itself and the CPU/TPM.
    >
    > Is this a serious request?

    Yes, it was serious because I found the statements to be terse and open
    to interpretation. Specifically, when I read it, it almost seemed that
    the position is that dynamic launch is not needed, and that the kernel
    could just establish its own RoT.

    > Kernel is started (via. firmware using the kernel's efi-stub, or via.
    > "kexec()", or..); and regardless of how the kernel was started the
    > kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or
    > Intel's TXT, followed by measuring the remainder of itself and
    > anything passed from firmware like APCI tables) without relying on a
    > call-back provided by "untrusted by kernel" third-parties that don't
    > exist in most cases. The dynamic root of trust that kernel creates
    > depends on the kernel, CPU, TPM, etc (and excludes untrusted and
    > unnecessary third parties)..

    This clarifies the previous statements and I would say, yes, this is one
    approach. Considering the challenges we have/are facing in getting a
    minimal post-launch handling (sl-stub) into the setup kernel, I would be
    hard-pressed to believe adding all the pre-launch handling would be
    found to be acceptable. If the intent is to have it completely
    self-contained, this would require,
    1) the introduction of a TPM driver into the setup kernel, a hole I
    would rather not go down again
    2) potentially the ability to load files from disk if it is not
    acceptable for the bootloader to load the DCE (ACM/SLB)
    3) miscellaneous system evaluations, memory table, machine check, etc.

    The only thing that is gained from such an approach is to make dynamic
    launch for Linux be self-contained in the kernel. It does not reduce the
    TCB because the whole design of the dynamic launch is to provide a
    controlled process that establishes a new trust chain/TCB that is
    started from an untrusted state. Specifically, dynamic launch starts
    with the CPU being provided all the material for the process by
    untrusted code that is currently in control at the time the launch is
    initiated.

    > The only potential benefit that the callback solution provides is that
    > it, in theory, it could reduce duplication of work for other operating
    > systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same
    > callback instead of doing it themselves); but previous discussions
    > (talk of formalising the contract between the boot stub and the Linux
    > kernel) suggest that you aren't interested in any other OS.

    With all due respect, but this is where I would have to disagree. There
    is substantial benefit,
    1) a single code base that needs to be reviewed vs multiple OS
    specific versions
    2) establishes an API that decouples pre- and post-launch
    3) reduces the complexity required to enable adoption by an OS
    4) zero reduction in the security properties of the architecture

    > This leaves me wondering what your true motivation is. Are you trying
    > to benefit GRUB/Trenchboot (at the expense of security, end-user
    > convenience, distro installer hassle, etc); or trying to manufacture
    > scope for future man-in-the middle attacks (by promoting a solution
    > that requires something between firmware and kernel)?

    As a loyal member of the tinfoil hat brigade, I will always advocate for
    accept nothing and question everything. All I can ask is to evaluate the
    technical merit of the presentations [1][2][3] and the patch series [4].
    If there is anything concerning with the theory or the implementation,
    then it should be raised so that it may be addressed. A means to do so
    is the "what if" game, as it is great to formulate a hypothesis. In this
    case, the "what if" postulated is the assumption that the approach is to
    allow a future MitM attack. Then the challenge is to examine the
    process, their underlying mechanism, and the security properties of
    those mechanisms to see if a MitM can be discerned. I will gladly engage
    with anyone that presents an analysis demonstrating an assumption I
    made/missed that opens the possibility for subversion of the launch
    integrity attempting to be built.

    [1] https://www.platformsecuritysummit.com/2018/speaker/smith/
    [2]
    https://events19.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/schedule/
    [3] https://lpc.events/event/7/contributions/739/
    [4] https://lkml.org/lkml/2022/2/18/699

    \
     
     \ /
      Last update: 2022-07-22 19:24    [W:6.506 / U:0.612 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site