linux-kernel - Re: [RFC PATCH 0/8] x86_64: Harden compressed kernel, part 1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Aug 2022 19:41:19 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Evgeniy Baskov <baskov@...ras.ru>
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>
Subject: Re: [RFC PATCH 0/8] x86_64: Harden compressed kernel, part 1

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?