lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29312ea704885f1b8d3c229e1f22dad7@ispras.ru>
Date:   Wed, 03 Aug 2022 02:45:57 +0300
From:   Evgeniy Baskov <baskov@...ras.ru>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] x86_64: Harden compressed kernel, part 1

On 2022-08-02 05:41, Dave Hansen wrote:
> On 8/1/22 17:25, Evgeniy Baskov wrote:
>> On 2022-08-01 19:48, Dave Hansen wrote:
>>> On 8/1/22 09:38, Evgeniy Baskov wrote:
>>>> This is the first half of changes aimed to increase security of 
>>>> early
>>>> boot code of compressed kernel for x86_64 by enforcing memory 
>>>> protection
>>>> on page table level.
>>> 
>>> Could you share a little more background here?  Hardening is good, 
>>> but
>>> you _can_ have too much of a good thing.
>>> 
>>> Is this part of the boot cycle becoming a target for attackers in
>>> trusted boot environments?  Do emerging confidential computing
>>> technologies like SEV and TDX cause increased reliance on compressed
>>> kernel security?
>>> 
>>> In other words, why is *THIS* important versus all the other patches
>>> floating around out there?
>> 
>> Now compressed kernel code becomes larger, partially because of adding
>> SEV and TDX, so it worth adding memory protection here.
> ...
> 
> Is it fair to say that the problems here are on the potential,
> theoretical side rather than driven by practical, known issues that our
> users face?

Partially. We do have known issues because kernel PE image is not 
compliant
with the MS PE and COFF specification v8.3 referenced by the UEFI 
specification.
UEFI implementations with stricter PE loaders (e.g. mentioned above) 
fail to
boot Linux kernel.

As for hardening side, these improvements are indeed just nice-to-haves.
But we believe it is good to have them if they are available for free.

Thanks,
Evgeniy Baskov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ