SysReport needs to be present in RELEASE

[ghost]

There is no consistent cross-platform method to obtain DSDT. It should not be expected that end-users run DEBUG to obtain DSDT to resolve incompatibilities.

I am struggling to understand what valid security concerns exist that prevent this from being a feature in RELEASE. Even ACPICA releases acpidump.efi however, it does not work in OpenShell as expected but it does work in UEFI Shell.

If we have security concerns with dumping ACPI tables with OpenCore, but not UEFI Shell, then perhaps we shouldn't trust OpenCore.

After all, Clover can do it.

[vit9696]

UEFI Shell cannot (should not) run from OpenCore in full-secure mode when vaulting and UEFI Secure Boot are enabled, making it not possible to run acpidump.efi, be that release or not.

it does not work in OpenShell as expected but it does work in UEFI Shell.

It works fine for us.

After all, Clover can do it.

Clover has no security model at all.

Closing as invalid.

[ghost]

I don't run UEFI Shell from OC, I run it from my BIOS and acpidump works. This implies to me OpenShell is not a standard UEFI Shell as acpidump does not work within it.

There is NO industry security concern with dumping ACPI tables. AFAIK that region is write-protected and can not be modified.

Why is it a security concern to dump ACPI tables from OC?

[vit9696]

I don't run UEFI Shell from OC, I run it from my BIOS and acpidump works.

Whether or not you run Shell from BIOS should not affect this.

This implies to me OpenShell is not a standard UEFI Shell as acpidump does not work within it.

This is false. OpenShell is UEFI Shell with few changes intended to adopt for some older firmwares.

There is NO industry security concern with dumping ACPI tables. AFAIK that region is write-protected and can not be modified.

This is false as it can disclose various physical addresses and corrupt your ESP filesystem due to a bug in most FAT32 drivers of APTIO IV firmwares, which is the primary reason we cannot let this in RELEASE builds.

[ghost]

I appreciate your responses and I'm sorry for being argumentative but it should not be required to run DEBUG solely to obtain ACPI tables. Wouldn't this corruption possibility still exist in DEBUG then? Shouldn't needing to manually enable the quirk once, get the tables and turning it off be enough?

Or an F4 to dump and be done with it?

[ghost]

To add, physical addresses are still accessible at user-level within the OS.

[vit9696]

I appreciate your responses and I'm sorry for being argumentative but it should not be required to run DEBUG solely to obtain ACPI tables.

That is your opinion. Our opinion is not (yet) changed at the very least.

Wouldn't this corruption possibility still exist in DEBUG then?

It does, but we view a DEBUG build as a way to setup your board, which you use once at an early stage, and then remove.

Shouldn't needing to manually enable the quirk once, get the tables and turning it off be enough? Or an F4 to dump and be done with it?

Once the dump happens it will not be overwritten, so there is no need to disable the quirk as it will no longer cause subsequent corruptions if they happen. That is why we do not need e.g. F4. However, the thing is, "one" is enough, so we better not to risk.

I do not understand why do you need dumping in RELEASE builds in particular? If you need to the tables, then you are likely debugging things, and without a DEBUG log your setup is pretty much blind in the first place.

[ghost]

I do not understand why do you need dumping in RELEASE builds in particular? If you need to the tables, then you are most likely debugging things, and without a DEBUG log your setup is pretty much blind in the first case.

Well from my personal experiences and assisting others, I've never needed DEBUG. Generally if the hardware is known, then the DeviceProperties and Quirks are fairly standard as are kexts. The remaining exception is ACPI scopes and incompatibilities. SSDT-PLUG and EC solve most of the remaining issues preventing boot.

To me it seems faster to put together an EFI, edit DeviceProperties/Quirks, add PLUG and EC which should install, then it's far easier to complete with an IOReg and ACPI dump. No need for DEBUG unless developing.

I understand your position. now however regarding the corruption. I just think if most users don't need DEBUG and just need an ACPI dump one time, then there is less work.

[vit9696]

That's surprising. The position of the development and validation teams is that you start with a debug log unless you are ignorant to the documentation. I am surprised to hear that you may not use a debug build during first-time setup. This is equivalent to doing it entirely blind way and likely missing configuration hints and warnings.

Really unsure about it. Technically SysReprot is guarded by config.plist anyway, but the original design allows you to have it set to YES and generate a report only when you install a debug build…

@Download-Fritz what do you think?

[ghost]

I understand that, I just think there are repeatable commonalities in known platforms/processors/igpu/dgpu/audio/ethernet/wireless/bluetooth/nvme. We know most platform/device-ids/layout-ids/quirks/kexts/boot-args, remaining issues are largely ACPI (OSYS/USB/etc. SSDTs). For hardware not known to work that has issues I would use DEBUG. I find the need for DEBUG to the be the exception though.

Truly my personal observations though.

[vit9696]

Well, ok. After some discussion we came up with a few ways to make it possible. But in this case we will need to make a text file containing dump timestamp and information about dumped data, because currently all that information is in the log.

[icedterminal]

My concern with this is boot times. OC is already extremely fast. With the picker disabled/bypassed I see the Apple logo virtually instantaneously. Would generating a log file slow down boot times?

[vit9696]

If you do not enable SysReport in the configuration it will not affect the boot performance of RELEASE builds. Otherwise it will, likely not by much (only initial report creation will be slow, and the rest will just check for report presence), but that should still be noticeable. Unsure if desired.

[vit9696]

This was not contributed externally after a considerable amount of time and there also was no real demand in this feature. Closing.