On Tue, Dec 22, 2015 at 11:03:09AM -0500, Stefan Berger wrote:
> "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 12/22/2015 10:40:03 AM:
> > On Mon, Dec 21, 2015 at 11:50:07AM -0500, Stefan Berger wrote:
> > > tpm_foo()
> > > {
> > > [...]
> > >
> > > switch (tpmversion) {
> > > case TPM_VERSION_1_2:
> > > tpm12_foo()
> > > break;
> > > case TPM_VERSION_2:
> > > tpm2_foo();
> > > break;
> > > }
> > >
> > > [...]
> > > }
> >
> > Is the difference between 1.2 and 2.0 so large that the above is
> > needed?
>
> TPM 2 and TPM 1.2 have completely different commands, so yes,
> unfortunately it's needed.
Okay. Just so I understand, is TPM 2.0 a new interface to the
hardware, new BIOS API, or both?
-Kevin
On Tue, Dec 22, 2015 at 03:15:26AM +0000, Xulei (Stone) wrote:
> Hi, Kevin,
> Can you tell how to reset/reboot this VM, if it goes to the handle_hwpic1()
> on its booting procedure? I mean, usually, SeaBIOS would not go to
> handle_hwpic routine. But in my test case, SeaBIOS calls handle_hwpic when
> KVM injects a #UD expcetion (not irq) and SeaBIOS will loop to handle this
> if KVM persistently injects exception.
>
> Now, i just wish to reset/reboot this VM if it is fall into handle_hwpic. I
> tried follwing patch and it seems not work. What can i do to force reset/reboot?
Call the reset() function.
-Kevin
Hello Stefan,
I think it will work perfectly for the higher level functions like : tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2 and 2.0 handling. For the functions like tpm_add_measurement_to_log() I don't think it is that easy or useful. For those it's probably better to have a tpm 1.2 and a tpm 2.0 variant each with their own API but not with a wrapper.
Please note I did not look into all details so I might be seeing problems that aren't there (or can be solved easily).
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wvervoorn(a)eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
From: Stefan Berger [mailto:stefanb@us.ibm.com]
Sent: Tuesday, December 22, 2015 2:56 PM
To: Wim Vervoorn <wvervoorn(a)eltan.com>
Cc: Kevin O'Connor <kevin(a)koconnor.net>; seabios(a)seabios.org
Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 08:43:54 AM:
>
> Hello Stefan,
>
> I have my doubts. This will work fine as long as the toplevel
> function tpm_foo() in your example can be implemented to have a
> single API independent of the required support. If the API differs
> between the tpm 1.2 and tpm 2.0 case I think it will only be confusing things.
>
> Given the differences between tpm 1.2 and 2.0 do you think you will
> be able to maintain this single API?
The top level function tpm_foo() will be called by other SeaBIOS code for doing TPM initialization,
measurements, the menu, S3 resume, and for the BIOS API. For the API we would support the same API
for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and tpm2_foo functions are mainly
that different TPM commands are created and sent to the TIS. So far, this works fine.
Do you have concrete concerns regarding this? How else would you do it ?
Regards,
Stefan
>
>
> Best Regards,
> Wim Vervoorn
>
> Eltan B.V.
> Ambachtstraat 23
> 5481 SM Schijndel
> The Netherlands
>
> T : +31-(0)73-594 46 64
> E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>
> W : http://www.eltan.com<http://www.eltan.com/>
> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
>
>
>
>
> From: Stefan Berger [mailto:stefanb@us.ibm.com]
> Sent: Monday, December 21, 2015 5:50 PM
> To: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>>
> Cc: seabios(a)seabios.org<mailto:seabios@seabios.org>; Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>>
> Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
>
> "Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM:
>
> >
> > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote:
> > > Hello,
> > >
> > > I noticed that a lot of work is going on for the TPM support in SeaBIOS.
> > >
> > > All of this work is TPM 1.2 based. I was wondering if there are any
> > > plans to support TPM 2.0 in the future.
> >
> > I'm not aware of any plans.
>
> We're working on it...
>
>
> So maybe you have some comments to the following:
>
> There will be a patch for probing the TPM TIS hardware interface for
> whether there's a TPM 1.2 or a TPM 2.
> We then have a patch for prefixing all TPM 1.2 functions with tpm12_
> and then introduce functions like these ones here:
>
> static ... tpm12_foo() { ... }
> static ... tpm2_foo() { ... }
>
> tpm_foo()
> {
> [...]
>
> switch (tpmversion) {
> case TPM_VERSION_1_2:
> tpm12_foo()
> break;
> case TPM_VERSION_2:
> tpm2_foo();
> break;
> }
>
> [...]
> }
>
> That way the probing will lead us to use either TPM1.2 or TPM 2
> specific code. There will be multiple such constructs in tcgbios.c file.
>
> Stefan
Hello Stefan,
I have my doubts. This will work fine as long as the toplevel function tpm_foo() in your example can be implemented to have a single API independent of the required support. If the API differs between the tpm 1.2 and tpm 2.0 case I think it will only be confusing things.
Given the differences between tpm 1.2 and 2.0 do you think you will be able to maintain this single API?
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wvervoorn(a)eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
From: Stefan Berger [mailto:stefanb@us.ibm.com]
Sent: Monday, December 21, 2015 5:50 PM
To: Kevin O'Connor <kevin(a)koconnor.net>
Cc: seabios(a)seabios.org; Wim Vervoorn <wvervoorn(a)eltan.com>
Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
"Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM:
>
> On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote:
> > Hello,
> >
> > I noticed that a lot of work is going on for the TPM support in SeaBIOS.
> >
> > All of this work is TPM 1.2 based. I was wondering if there are any
> > plans to support TPM 2.0 in the future.
>
> I'm not aware of any plans.
We're working on it...
So maybe you have some comments to the following:
There will be a patch for probing the TPM TIS hardware interface for whether there's a TPM 1.2 or a TPM 2.
We then have a patch for prefixing all TPM 1.2 functions with tpm12_ and then introduce functions like these ones here:
static ... tpm12_foo() { ... }
static ... tpm2_foo() { ... }
tpm_foo()
{
[...]
switch (tpmversion) {
case TPM_VERSION_1_2:
tpm12_foo()
break;
case TPM_VERSION_2:
tpm2_foo();
break;
}
[...]
}
That way the probing will lead us to use either TPM1.2 or TPM 2 specific code. There will be multiple such constructs in tcgbios.c file.
Stefan
On Mon, Dec 21, 2015 at 09:41:32AM +0000, Gonglei (Arei) wrote:
> When the gurb of OS is booting, then the softirq and C function send_disk_op()
> may use extra stack of SeaBIOS. If we inject a NMI, romlayout.S: irqentry_extrastack
> is invoked, and the extra stack will be used again. And the stack of first calling
> will be broken, so that the SeaBIOS stuck.
>
> You can easily reproduce the problem.
>
> 1. start on guest
> 2. reset the guest
> 3. inject a NMI when the guest show the grub surface
> 4. then the guest stuck
Does the SeaBIOS patch below help? I'm not familiar with how to
"inject a NMI" - can you describe the process in more detail?
-Kevin
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -548,7 +548,9 @@ entry_post:
ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point
ORG 0xe2c3
- IRQ_ENTRY 02
+ .global entry_02
+entry_02:
+ ENTRY handle_02 // NMI handler does not switch onto extra stack
ORG 0xe3fe
.global entry_13_official
On Mon, Dec 21, 2015 at 06:44:18PM +0000, edward wandasiewicz wrote:
> With 47-g977a7d4, we get
>
> 1. YES - we get no duplicate of the Philips, and get just one of each
> appear in the boot list, Mushkin & Philips
>
> 2. NO - we sometimes get just the Mushkin only - no Philips detected -
> with both devices plugged in, about 1 in 10 cold boot starts - both
> plugged in USB 3 port and both plugged in Type C port
>
> The 2 Type C cables used, are those from the Google Play Store, for the record.
>
> cbmem attached for each.
It looks like in both of the failure logs that the super/high
confusion delayed the usb3 connection notification past the time
SeaBIOS was looking for connection notifications. I suspect you could
get around this by increasing "etc/usb-time-sigatt". (For example, by
adding "$CBFSTOOL $CBFSFILE add-int -i 300 -n etc/usb-time-sigatt" to
the "Other settings" section of the chrome image building script I
previously sent.) This "secondary failure" after patch 47 is one of
the reasons I'm not sure how to really fix the dup drive issue.
-Kevin
On Sun, Dec 20, 2015 at 09:47:04PM +0000, edward wandasiewicz wrote:
> As requested, for rel-1.9.0-46-g636cbb4.
Thanks. So, same as before?
> Is it worth testing the double scenario, or maybe put it down to a
> "manufacturer's flaw" going forward?
I need additional time to think about that and to see if any other
similar reports occur. In the mean time, could you pull testing again
and retry (with 47-g977a7d4). I think that branch will fix the issue
for you (and it could give you a short term workaround if you need
that).
-Kevin
On Mon, Dec 21, 2015 at 12:57:33PM +0000, Stojsavljevic, Zoran wrote:
> Hello Kevin,
>
> All Good with setting CSM ON for legacy support. You need it for 16 bit BIOSes, and for legacy OSes, such as WIN XP or WIN 7 and derivatives.
>
> Here is the question I am wondering: What if I decide to bring FSP -> Coreboot -> SeaBIOS -> WIN 8.1 32. Do I really need SeaBIOS with option set to: CSM ON (I brought WIN 8.1 32 on CC2 with SeaBIOS and feature CSM ON)? In other words, can I bring WIN 8.1 32 on FSP -> Coreboot -> SeaBIOS with CSM OFF?
>
> The same question for: FSP -> Coreboot -> SeaBIOS -> WIN 8.1 64? I guess, here is CSM ON mandatory. Am I correct?
>
> Could I have a true 32 or 64 UEFI compliant OS on BSP: FSP -> Coreboot -> SeaBIOS -> UEFI OS sans/without CSM feature ON? The same one I have after bringing on UEFI 32/64 BIOS UEFI 32/64 OS (CSM is OFF always)?
>
In all of the above situations you must compile SeaBIOS with
CONFIG_COREBOOT=y and CONFIG_CSM=n. CONFIG_CSM is mutually exclusive
with CONFIG_COREBOOT, and if one is planning to run SeaBIOS directly
from coreboot then one must use CONFIG_COREBOOT=y.
-Kevin
