• CR feedback: remove unused "key" local var

• CR feedback: call cleanup on error paths

• CR feedback: check key size in parent

• __read_mostly

In D29942#673010, @mav wrote:

It looks good to me. I am just thinking whether it worth to mark the variable as __read_mostly.

@sjg or @stevek If one of you could take a look, I'd appreciate it.

• refactor VERIEXEC vars into new veriexec.mk

I'll finish this for Bret.

@mav How does this look?

• xAPIC only

• naming is important

• add sysctl/tunable and wait 1s by default

In D29942#671819, @mav wrote:

I don't have specific objections. I can't recall I ever saw this panic and not sure how the interrupt delivery can take more that 50ms. But it reminds me that we do have spinlock timeout, which is also not required. Do you see any benefits from this comparing to just increasing the timeout back to 1s as it was before f418f79ce299 to keep ability to debug misbehaving hardware?

smbios still attaches on a bhyve VM running FreeBSD main plus this change, booting in Legacy BIOS mode. The device address did not change, of course.

In D29606#663782, @trasz wrote:

No objections, but please note that 'uefisign -V' doesn't actually verify the signature. It would be useful to try to actually boot the signed binary.

In D29512#662047, @yongbo.yao_dell.com wrote:

In D29512#661559, @imp wrote:

I'm fine with this, but think we need to document it somewhere and also discuss any limitations relative to other boot methods there might be.

Thanks Warner. Should it be documented to loader.8? if so , can I update it in this patch?

@greg_unrelenting.technology Please look back over the comments from @ambrisko . In particular, I'd like to see testing on a non-UEFI system.

In D29276#655921, @ambrisko wrote:

I'm not sure what happens if efirt is loaded on a non-UEFI system?

I would like a review from at least one of these fine folks: @imp @kevans @tsoome

This fixes it. Thanks for the quick help, John.

In D26973#609750, @gallatin wrote:

In D26973#609585, @gallatin wrote:

After this change, perl freaks out like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "C.UTF-8"

are supported and installed on your system.

perl: warning: Falling back to the standard locale ("C").
panic: locale.c: 4560: Could not change LC_CTYPE locale to C.UTF-8, errno=22

Is this expected? This is perl5-5.32.0

Thanks

My issue appears to have been caused by building with WITHOUT_LOCALES=YES. Removing that makes perl happy again. Sort of odd that nothing else cared.

In D26817#601100, @imp wrote:

In D26817#601097, @pfg wrote:

First of all: thanks!

I should mention this was actually for a hacked linux binary-based intel compiler.

There exists a native FreeBSD [[ https://software.intel.com/content/www/us/en/develop/tools/system-studio/freebsd.html | Intel System Studio ]]compiler that claims to be GCC compatible which may just work (I tihnk it may be based on clang, but I am not sure).

I keep hearing rumors of this item, but never have been able to get a copy through my friends at Intel. I'll have to send a few emails out to see if I can see if I can get access to one, though it's a fairly low propriety. I suspect, based on a lot of things, that this doesn't actually exist, but I'll poke and prod anyway.