Re: [coreboot] Lenovo G505s AMD Hardware Virtualization

[awokd]

On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote:
> > Last resort is to flash back the OEM image but I'm hoping to avoid that.
>
> I would suggest to do this step now. As interim step, Then you can verify
> everything you are trying to do
> with Coreboot. The first and obvious step is to check for MCU using dmesg,
> if any exists. If yes, the next
> step, probably, is to retrieve MCU from BIOS and port it to Coreboot, so
> you can be sure that this is not
> an issue.
>
> Then you can verify all the rest:XEN, Cubes and etc., and record use cases
> wit logs, before returning
> back to Coreboot.

That is a painful (because this laptop needs to be completely disassembled
to get at the flash chip, and it's a Lenovo crippled InsydeH2O EFI BIOS
with phone home capability) but logical approach. Thanks, will report back
on where this problem bisection leads and/or a resolution when I get
there.

Lenovo G505s AMD Hardware Virtualization

[Ivan Ivanov]

> Mine reports they are enabled as well, it's just when I attempt to use
> an HVM I'm experiencing the freeze! Thus my plea for help to the list
> to see if anyone has actually tried to use an HVM on this Corebooted
> hardware

I have thought that if Qubes sees HVM available it is always using it.
(so if Qubes reports to you that HVM is enabled, that means its using
HVM and without any problems). Am I wrong here?
> Last resort is to flash back the OEM image but I'm hoping to avoid that.

It is rare that a default proprietary UEFI/BIOS has a good virtualization
support, especially for AMD-based consumer level hardware.
E.g. I am almost sure that no IOMMU supported by that InsydeH2O,
but still it would be curious to hear your results...
> That is a painful (because this laptop needs to be completely
> disassembled to get at the flash chip, and it's a Lenovo crippled
> InsydeH2O EFI BIOS with phone home capability) but logical approach

Next time you disassemble, you could carefully cut a small window
(e.g. using a heated knife or soldering iron) inside the bottom's half of a
laptop. Please check out the attached image to see how to do it safely.
After you cut this window - you could attach SOIC8 clip to a flash chip
without completely disassembling your laptop. But, because of the
same reason, someone may use your "quick access window" to quickly
flash a "coreboot with added backdoors" image - since now he doesn't
need to completely disassemble your laptop, can do it very quickly.
So you will have to never leave your laptop unattended after this mod,
or at least invent some additional security measures (vboot?) ...

2017-12-01 15:10 GMT+03:00 awokd :
> On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote:
> > > Last resort is to flash back the OEM image but I'm hoping to avoid that.
> >
> > I would suggest to do this step now. As interim step, Then you can verify
> > everything you are trying to do
> > with Coreboot. The first and obvious step is to check for MCU using dmesg,
> > if any exists. If yes, the next
> > step, probably, is to retrieve MCU from BIOS and port it to Coreboot, so
> > you can be sure that this is not
> > an issue.
> >
> > Then you can verify all the rest:XEN, Cubes and etc., and record use cases
> > wit logs, before returning
> > back to Coreboot.
>
> That is a painful (because this laptop needs to be completely disassembled
> to get at the flash chip, and it's a Lenovo crippled InsydeH2O EFI BIOS
> with phone home capability) but logical approach. Thanks, will report back
> on where this problem bisection leads and/or a resolution when I get
> there.

Lenovo G505s AMD Hardware Virtualization

[awokd]

On Fri, December 1, 2017 12:10 pm, awokd wrote:
> On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote:
> > > Last resort is to flash back the OEM image but I'm hoping to avoid that.
> >
> > I would suggest to do this step now. As interim step, Then you can verify
> Thanks, will report back
> on where this problem bisection leads and/or a resolution when I get
> there.

I got it [after many days of research and trial]! I had to update
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnEquivalenceTable.c
from:

STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
{
  0x6101, 0x6101,
  0x6100, 0x6100
};

// Unencrypted equivalent
STATIC CONST UINT16 ROMDATA CpuF15TnUnEncryptedMicrocodeEquivalenceTable[] =
{
  0x6101, 0x6901,
  0x6100, 0x6900
};

TO:

STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
{
  0x6131, 0x6101,
  0x6101, 0x6101,
  0x6100, 0x6100
};

// Unencrypted equivalent
STATIC CONST UINT16 ROMDATA CpuF15TnUnEncryptedMicrocodeEquivalenceTable[] =
{
  0x6131, 0x6901,
  0x6101, 0x6901,
  0x6100, 0x6900
};

Is there a newbie primer somewhere on how to make a commit?

Now I am seeing patch level 0x0600110f on all CPUs, and my Xen/Qubes HVMs
start without freezing the entire machine.

Still haven't been able to figure out how to get them to patch level
0x06001119 like under the OEM firmware. I found the blob corresponding to
that patch level in there as well as in the stock microcode_amd_fam15h.bin
3rdparty blob. From looking at
src/vendorcode/amd/agesa/f15tn/Config/OptionFamily15hInstall.h it seems as
though microcode updates might be hardcoded (F15_TN_UCODE_10F, for
example). Would I need to hardcode my newer version too, or am I reading
it wrong?

I did some quick testing with device passthrough under Qubes and it
doesn't seem to be working but I need to spend more time on it.

Lenovo G505s AMD Hardware Virtualization

[awokd]

On Mon, December 11, 2017 12:56 am, awokd wrote:
> I got it [after many days of research and trial]! I had to update
> src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnEquivalenceTable.c
> from:
>
> STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
> {
>   0x6101, 0x6101,
>   0x6100, 0x6100
> };
>
> // Unencrypted equivalent
> STATIC CONST UINT16 ROMDATA

CpuF15TnUnEncryptedMicrocodeEquivalenceTable[] =
> {
>   0x6101, 0x6901,
>   0x6100, 0x6900
> };
>
> TO:
>
> STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
> {
>   0x6131, 0x6101,
>   0x6101, 0x6101,
>   0x6100, 0x6100
> };
>
> // Unencrypted equivalent
> STATIC CONST UINT16 ROMDATA

CpuF15TnUnEncryptedMicrocodeEquivalenceTable[] =
> {
>   0x6131, 0x6901,
>   0x6101, 0x6901,
>   0x6100, 0x6900
> };
>
> Is there a newbie primer somewhere on how to make a commit?
>
> Now I am seeing patch level 0x0600110f on all CPUs, and my Xen/Qubes HVMs
> start without freezing the entire machine.
>
> Still haven't been able to figure out how to get them to patch level
> 0x06001119 like under the OEM firmware. I found the blob corresponding to
> that patch level in there as well as in the stock microcode_amd_fam15h.bin
> 3rdparty blob. From looking at
> src/vendorcode/amd/agesa/f15tn/Config/OptionFamily15hInstall.h it seems as
> though microcode updates might be hardcoded (F15_TN_UCODE_10F, for
> example). Would I need to hardcode my newer version too, or am I reading
> it wrong?
>
> I did some quick testing with device passthrough under Qubes and it
> doesn't seem to be working but I need to spend more time on it.

Got the CPU patch level to 0x06001119 by converting the blob to hex and
dumping it over top of the hex in
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnMicrocodePatch0600110F_Enc.c.
Kind of an ugly hack but I was having trouble following the microcode
update logic in there; it's scattered all over. Is there an open source
graphical IDE that makes it easier? What's the best approach to turn this
into a commit? Please cc list if you reply, my email provider is having
trouble.

Anyways, passthrough is working now too. The Atheros Ethernet and wireless
controllers support PCI strict reset, but not the built in USB
controllers. This might be a dumb question but is there a way to enable
that functionality in Coreboot, or is it a hardware limitation?

Thanks to all who replied to my earlier emails, it definitely helped.

Lenovo G505s AMD Hardware Virtualization

Congratulations for following through on the investigation :D

I am not sure how to do a commit, but I hope you are able to find out as 
you will have helped a lot of people.

I am pleased with myself for noticing that the lack of microcode updates 
was the issue - as the CPU is similar to a piledriver not a bulldozer it 
requires microcode for IOMMU.

I do not have the technical documents for that chipset and I do not know 
how to change the PCI regs but I am sure the USB controllers support FLR 
considering the nearly identical SR56xx chipsets usb controllers do - I 
will look in to this further.

Lenovo G505s AMD Hardware Virtualization

[Ivan Ivanov]

awokd, could you please answer some questions:

1) From where you got that 0x06001119 microcode patch?
Is it a trusted source of a microcode? (hope its directly from AMD)

2) Is there any way to determine that 0x06001119 is really the latest microcode?
Or there could be more recent versions available?

Best regards,
Ivan Ivanov

2017-12-12 6:21 GMT+03:00 [e-mail] :
> Congratulations for following through on the investigation :D
>
> I am not sure how to do a commit, but I hope you are able to find out as you
> will have helped a lot of people.
>
> I am pleased with myself for noticing that the lack of microcode updates was
> the issue - as the CPU is similar to a piledriver not a bulldozer it
> requires microcode for IOMMU.
>
> I do not have the technical documents for that chipset and I do not know how
> to change the PCI regs but I am sure the USB controllers support FLR
> considering the nearly identical SR56xx chipsets usb controllers do - I will
> look in to this further.