On Tue, 9 Sep 2025, Theo de Raadt wrote:

> Stefan Fritsch <sf@sfritsch.de> wrote:
> 
> > > >  struct cfdriver acpi_cd = {
> > > > -	NULL, "acpi", DV_DULL
> > > > +	NULL, "acpi", DV_DULL, CD_COCOVM
> > > >  };
> > > 
> > > I still think that by including acpi(4) in the list of allowed drivers
> > > you have included the driver with the largest possible attack surface.
> > > And our the AML interpreter code certainly isn't the best quality code
> > > in our tree.
> > 
> > Making ACPI secure will be some big piece of work in the future. For not 
> > it is neccessary.
> 
> I don't see how that can ever be achieved, because it is a turing-complete
> engine.
> 
> I'll go back to my suggestion to try to use MPBIOS information if it exists.

I agree that making ACPI secure means not parsing any AML. So maybe it 
will involve finding other sources for the information we need from the 
DSDT/SSDT. Maybe in the end it will allow us to simply disable acpi(4). 
SEV-SNP already defines a way to get the APIC IDs of all present CPUs. 
Knowledge about IO APICs could be replaced by using MSI/MSI-X exclusively 
or by using some para-virtualized intterupt controller. We will have to 
see what other pieces we absolutely need. PCI busses come to mind.