Hi Stefan,
I dusted off some TPM patches I had worked on earlier in the year.
Mostly just code movement, but the last patch I think helps simplify
tpm_build_and_send_cmd().
Do they look okay to you?
-Kevin
Kevin O'Connor (6):
tpm: Add comment banners to tcg.c separating major parts of spec
tpm: Don't call tpm_set_failure() from tpm12_get_capability()
tpm: Move code around in tcgbios.c to keep like code together
acpi: Generalize find_fadt() and find_tcpa_by_rsdp() into
find_acpi_table()
tpm: Don't call tpm_build_and_send_cmd() from tpm20_stirrandom()
tpm: Rework tpm_build_and_send_cmd() into tpm_simple_cmd()
src/fw/biostables.c | 18 +-
src/std/acpi.h | 7 -
src/std/tcg.h | 199 +++++++++--------
src/tcgbios.c | 611 ++++++++++++++++++++++------------------------------
src/util.h | 1 +
5 files changed, 369 insertions(+), 467 deletions(-)
--
2.5.5
Hi,
Next round of serial console patches, Still not ready to merge.
Headline feature of this version is split mode (i.e. output on both vga
and serial). Have a initial working implementation now, logic is
simliar to the vgabios timer hook (as suggested by Kevin).
Also changed the output logic, down to a one-cell buffer (char+attr) for
output. Cursor updates are simply written to BDA now, with the actual
move being done lazily when printing the next character or checking for
keyboard input. That is especially useful for splitmode as we can
simply skip the cursor position updates and let the vgabios do them
instead.
TODO list:
* compile time (CONFIG_*) option.
* input handling cleanups.
* implement missing int10h functions.
* more testing.
cheers,
Gerd
Gerd Hoffmann (5):
std: add cp437 to unicode map
kbd: make enqueue_key public, add ascii_to_keycode
paravirt: read QEMU_CFG_NOGRAPHIC, store in etc/sercon-enable romfile
add serial console support
[wip] sercon: initial split-output implementation
Makefile | 7 +-
src/clock.c | 1 +
src/fw/paravirt.c | 2 +
src/kbd.c | 17 +-
src/misc.c | 2 +
src/optionroms.c | 9 +-
src/romlayout.S | 39 ++++
src/sercon.c | 621 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/std/cp437.c | 275 ++++++++++++++++++++++++
src/std/cp437.h | 1 +
src/util.h | 5 +
11 files changed, 974 insertions(+), 5 deletions(-)
create mode 100644 src/sercon.c
create mode 100644 src/std/cp437.c
create mode 100644 src/std/cp437.h
--
1.8.3.1
Dear SeaBIOS developers,
Building the attached configuration with GCC 5.3.0 and the static
analyzer scan-build shipped with Clang 3.8, the following error is
reported in `src/hw/usb-msc.c` in line 110.
The static analyzer seems to think that the struct member is not
initialized. But I guess it’s done in the line below, and therefore a
false positive?
```
ret = usb_msc_send(udrive_gf, USB_DIR_IN
, MAKE_FLATPTR(GET_SEG(SS), &csw), sizeof(csw));
```
Thanks,
Paul
This is a patch that worked for the Bochs BIOS. The code is similar.
The important part is the keycode. DOSRMX needs this for console switching.
The other part is a hook. I have key presses; key releases should be done too.
I don't know what uses this, but it is a standard BIOS feature.
Dear SeaBIOS folks,
Playing with the bootsplash feature, I noticed, that it’s only
displayed when the boot menu is displayed, when no bootsplash is used.
On the ASRock E350M1 it takes ten seconds to detect the connected
spinning hard disk, and the bootsplash is not displayed during that
time. Would it make sense to already show the bootsplash then?
Thanks,
Paul
Commit 4ce5d207 removed the code to wait for a possible second byte
from a keyboard reset command, but it did not remove the extra check
when warning in ps2_recvbyte(). Remove the now stale code in
ps2_recvbyte().
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/hw/ps2port.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/hw/ps2port.c b/src/hw/ps2port.c
index d5504f7..d9727d2 100644
--- a/src/hw/ps2port.c
+++ b/src/hw/ps2port.c
@@ -179,9 +179,7 @@ ps2_recvbyte(int aux, int needack, int timeout)
}
if (timer_check(end)) {
- // Don't warn on second byte of a reset
- if (timeout > 100)
- warn_timeout();
+ warn_timeout();
return -1;
}
yield();
--
2.5.5
> On 11/08/2016 04:13, Xulei (Stone) wrote:
> > Following your suggestion, I found this problem may be caused by the
> > flag of HF_SMM_MASK. I'm now sure QEMU is sending the KVM_SMI ioctl,
> > and kmod already handles this ioctl.
> >
> > I add printk in inject_pending_event(), like this:
> >
> > /* try to inject new event if pending */
> > + if(get_smi)
> > + printk(KERN_INFO "is_smm:%d\n", is_smm(vcpu));
> > +
> > if (vcpu->arch.smi_pending && !is_smm(vcpu)) {
> > vcpu->arch.smi_pending = false;
> > process_smi(vcpu);
> > }
> >
> > Then I found that the normal output is (is_smm is 0):
> > 2016-08-11T09:44:45.090078+08:00|info|kernel[-]|[1269634.151054get smi
> > ioctl from qemu
> > 2016-08-11T09:44:45.090097+08:00|info|kernel[-]|[1269634.151056in
> > process_smi_request
> > 2016-08-11T09:44:45.090114+08:00|info|kernel[-]|[1269634.151057is_smm:
> > 0
> > 2016-08-11T09:44:45.090131+08:00|info|kernel[-]|[1269634.151058process
> > smi 2016-08-11T09:44:45.090914+08:00|info|kernel[-]|[1269634.151575get
> > smi ioctl from qemu
> > 2016-08-11T09:44:45.090947+08:00|info|kernel[-]|[1269634.151578in
> > process_smi_request
> > 2016-08-11T09:44:45.090972+08:00|info|kernel[-]|[1269634.151579is_smm:
> > 0
> >
> > When problem occurs the output is (is_smm is 1):
> > 2016-08-11T10:07:11.755982+08:00|info|kernel[-]|[1270981.916056get smi
> > ioctl from qemu
> > 2016-08-11T10:07:11.756035+08:00|info|kernel[-]|[1270981.916062in
> > process_smi_request
> > 2016-08-11T10:07:11.756078+08:00|info|kernel[-]|[1270981.916064is_smm:
> > 1 2016-08-11T10:07:13.896977+08:00|info|kernel[-]|[1270984.058117get
> > smi ioctl from qemu
> > 2016-08-11T10:07:13.897063+08:00|info|kernel[-]|[1270984.058121in
> > process_smi_request
> > 2016-08-11T10:07:13.897091+08:00|info|kernel[-]|[1270984.058123is_smm:
> > 1
> >
> > So, it seems kvm cannot set HF_SMM_MASK flag correctly when we
> continuously reset VM.
> > Any futher suggestion? Paolo :)
>
> I guess a KVM_SET_VCPU_EVENTS is missing at reset time.
This maybe a kvm bug of SMM supporting feature:
assuming kvm SMI injection process is interrupted at the point
between process_smi() and bios executing RSM. Then bios runs from
the beginning again because of resetting and kvm keeps is_smm() =1.
When bios writes 0xb2 to raise a SMI, kvm thinks is_smm() = 1, and
will not process this request, and also will not call kvm_vcpu_reset()
to clear HF_SMM_MASK flag any more. Bios will not executing RSM
because of it does not get this SMI injecting from kvm. This condition
cannot break until we destroy this VM.
After testing 2 days, following patch can solve this problem, but obviously
it is not a suitable solution:
static int kvm_vcpu_ioctl_smi(struct kvm_vcpu *vcpu)
{
+ if (is_smm(vcpu)) {
+ vcpu->arch.hflags &= ~HF_SMM_MASK;
+ vcpu->arch.smi_pending = 0;
+ }
kvm_make_request(KVM_REQ_SMI, vcpu);
return 0;
}
Paolo, could you post a suitable patch to solve this problem based on
the information I mentioned above?
> Paolo
This series of patches extends the TPM2 code to extend the BIOS related
PCRs 0-7 in all available banks. This prevents that these PCRs remain
untouched and filled with bogus values by applications. For example, the
SHA1 hash is extended into the SHA256 bank. The value that is extended
into this bank is essentially a SHA1 with zero bytes used for filling it to
the size of a sha256 hash. This is done for all PCR banks of the TPM2
where these PCRs are available.
v2->v3:
- Following Kevin's comments; would defer split-up of code in tcgbios.c
to a later time
v1->v2:
- extended the log functions for logging the additional hashes. This added
more patches to this series
Regards,
Stefan
Stefan Berger (7):
tpm: Retrieve the PCR Bank configuration
tpm: Restructure tpm20_extend to use buffer and take hash as parameter
tpm: Refactor tpml_digest_values_sha1 structure
tpm: Extend tpm20_extend to support extending to multiple PCR banks
tpm: Move tpm_log_init to a later point
tpm: Adjust the TPM2 log header to show all hashes
tpm: Append to TPM2 log the hashes used for PCR extension
src/std/tcg.h | 86 +++++++++++--
src/tcgbios.c | 404 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 421 insertions(+), 69 deletions(-)
--
2.5.5
On 11/08/2016 04:13, Xulei (Stone) wrote:
> Following your suggestion, I found this problem may be caused by the flag of
> HF_SMM_MASK. I'm now sure QEMU is sending the KVM_SMI ioctl, and
> kmod already handles this ioctl.
>
> I add printk in inject_pending_event(), like this:
>
> /* try to inject new event if pending */
> + if(get_smi)
> + printk(KERN_INFO "is_smm:%d\n", is_smm(vcpu));
> +
> if (vcpu->arch.smi_pending && !is_smm(vcpu)) {
> vcpu->arch.smi_pending = false;
> process_smi(vcpu);
> }
>
> Then I found that the normal output is (is_smm is 0):
> 2016-08-11T09:44:45.090078+08:00|info|kernel[-]|[1269634.151054get smi ioctl from qemu
> 2016-08-11T09:44:45.090097+08:00|info|kernel[-]|[1269634.151056in process_smi_request
> 2016-08-11T09:44:45.090114+08:00|info|kernel[-]|[1269634.151057is_smm:0
> 2016-08-11T09:44:45.090131+08:00|info|kernel[-]|[1269634.151058process smi
> 2016-08-11T09:44:45.090914+08:00|info|kernel[-]|[1269634.151575get smi ioctl from qemu
> 2016-08-11T09:44:45.090947+08:00|info|kernel[-]|[1269634.151578in process_smi_request
> 2016-08-11T09:44:45.090972+08:00|info|kernel[-]|[1269634.151579is_smm:0
>
> When problem occurs the output is (is_smm is 1):
> 2016-08-11T10:07:11.755982+08:00|info|kernel[-]|[1270981.916056get smi ioctl from qemu
> 2016-08-11T10:07:11.756035+08:00|info|kernel[-]|[1270981.916062in process_smi_request
> 2016-08-11T10:07:11.756078+08:00|info|kernel[-]|[1270981.916064is_smm:1
> 2016-08-11T10:07:13.896977+08:00|info|kernel[-]|[1270984.058117get smi ioctl from qemu
> 2016-08-11T10:07:13.897063+08:00|info|kernel[-]|[1270984.058121in process_smi_request
> 2016-08-11T10:07:13.897091+08:00|info|kernel[-]|[1270984.058123is_smm:1
>
> So, it seems kvm cannot set HF_SMM_MASK flag correctly when we continuously reset VM.
> Any futher suggestion? Paolo :)
I guess a KVM_SET_VCPU_EVENTS is missing at reset time.
Paolo
