Re: [PATCH v2 2/6] percpu: Bound decrypted storage for all x86 encrypted guests

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Sep 29, 2026 at 01:12:45PM -0400, Zack Rusin wrote:
> On Tue, Sep 29, 2026 at 3:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, Sep 29, 2026 at 12:02:51AM -0400, Zack Rusin wrote:
> > > @@ -1022,11 +1024,13 @@
> > >   * Note: We use a separate section so that only this section gets
> > >   * decrypted to avoid exposing more than we wish.
> > >   */
> > > -#ifdef CONFIG_AMD_MEM_ENCRYPT
> > > +#if defined(CONFIG_X86_MEM_ENCRYPT) && defined(CONFIG_SMP)
> > >  #define PERCPU_DECRYPTED_SECTION                                     \
> > >       . = ALIGN(PAGE_SIZE);                                           \
> > > +     __start_percpu_decrypted = .;                                   \
> > >       *(.data..percpu..decrypted)                                     \
> > > -     . = ALIGN(PAGE_SIZE);
> > > +     . = ALIGN(PAGE_SIZE);                                           \
> > > +     __end_percpu_decrypted = .;
> > >  #else
> > >  #define PERCPU_DECRYPTED_SECTION
> > >  #endif
> >
> > So you're page aligning something that will get different protection and
> > will thus shatter large pages?
> >
> > That is somewhat uncool. We like large pages, large pages are good.
> 
> I'm a huge large pages fan too. I have a poster in my office and
> everything... And I never do things that are uncool. I have a wwcdd
> (what would cool dude do) bracelet and I look at it every time I make
> a decision, which given that I'm old gets on my wife's nerves a lot.
> That is to say I'm handsome and innocent.

:-)

> The alignment isn't new. It has been there since ac26963a1175
> ("percpu: Introduce DEFINE_PER_CPU_DECRYPTED") under AMD_MEM_ENCRYPT,
> which common distro kernels enable. This patch extends it to TDX-only
> builds and adds the boundary symbols. On bare metal and in ordinary
> guests nothing changes protection, so no large pages are split.

Right, I saw it is pre-existing, but you made me notice ;-)

Anyway, the thing that wasn't immediately obvious was that we only
really change the protection for (sekjoer) guests. This means I mostly
don't care.

> In confidential guests, yes, converting each CPU's page splits the
> direct map around it. The alignment doesn't cause that: a large

Nit you could 2M align, so alignment is somewhat related.

> mapping can't be part private and part shared, so a converted page
> can't stay inside one. The alignment only keeps unrelated per-CPU data
> out of the shared page. Because that page sits in every CPU's per-CPU
> unit, each 2M mapping that holds one of them becomes 4K mappings,
> including the ordinary per-CPU data around it. In the layouts we've
> tested that's most of the first per-CPU chunk.

So perhaps a little more invasive would be poking at the per-cpu
allocator and having a whole 'decrypted' pcpu_chunk which is 2M aligned
or something.


Anyway, as long as this is sekjoer guests only, I really could not be
bothered much. Proceed, but perhaps put on a comment in the
vmlinux.lds.h to clarify this, for those of us who do not live in
coconut land?