Re: [SeaBIOS] [Question] Debug Seabios by GDB with Qemu

[Kevin O'Connor]

On Mon, Feb 05, 2018 at 07:10:58PM +0800, Liu, Jing2 wrote:
> On 1/31/2018 10:46 AM, Kevin O'Connor wrote:
> > On Mon, Jan 29, 2018 at 02:18:45PM +0800, Liu, Jing2 wrote:
> > > Hello,
> > > 
> > > I am using Seabios for qemu startup, and interested in the debugging by 
> > > GDB
> > > to see how the bios works.
> > > 
> > > Currently, I do it as https://www.seabios.org/Debugging said but met some
> > > problems so that couldn't move on. :(
> > > Could someone give some pointers on what I missed or have to do to enable
> > > the gdb debugging?
> > > 
> > > Note:
> > > Arch: x86_64 PC
> > > CONFIG_DEBUG_SERIAL is enabled.
> > > CONFIG_RELOCATE_INIT is disabled.
> > > 
> > > 1.  After Qemu starts, I run "gdb out/rom32seg.o" in another session, and 
> > > do
> > > "target remote localhost:1234", it warns me that
> > > "Selected architecture i386 is not compatible with reported target
> > > architecture i386:x86_64". But I didn't find any 64bit rom.
> > 
> > I'm not sure why you choose out/rom32seg.o - to debug the 32bit code,
> > you want to use out/rom.o.
> 
> Thank you for your answer!
> But after I connect to qemu in the gdb session, and execute "run" OR "start"
> to start the rom.o, it both reports me a signal SIGKILL.

It works for me.  See log below.

-Kevin




$ ../qemu/qemu-2.10.0/i386-softmmu/qemu-system-i386 -k en-us -snapshot -L test 
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -m 
512 -hda dos-drivec -s -S



$ gdb out/rom.o
GNU gdb (GDB) Fedora 8.0.1-35.fc27
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from out/rom.o...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0xfff0 in ?? ()
(gdb) b startBoot
Breakpoint 1 at 0xf1d4d: file ./src/post.c, line 184.
(gdb) c
Continuing.

Breakpoint 1, startBoot () at ./src/post.c:184
184 {
(gdb) 


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] reboot fails with QEMU "isapc" machine type

[Kevin O'Connor]

On Mon, Feb 05, 2018 at 12:46:41PM +, Daniel P. Berrangé wrote:
> I was experimenting with old MS-DOS 6.22 under QEMU with the 'isapc' machine
> type, and found it is not able to reboot the guest. Bisecting QEMU blamed
> the QEMU change that rebased from "rel-1.9.3", to "rel-1.10.0". Further
> bisecting SeaBIOS blames this change:

What version of QEMU are you using?  I can't get anything to run with
the isapc machine type - I just get:

SeaBIOS (version rel-1.11.0-11-g4a6dbce-dirty-20180207_213141-morn.lan)
BUILD: gcc: (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) binutils: version 2.29-6.fc27
No Xen hypervisor found.
Unable to unlock ram - bridge not found

I didn't think isapc was functional at all.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Failure to detect high-capacity SD card

[Kevin O'Connor]

On Tue, Feb 06, 2018 at 07:38:22PM -0500, Chris wrote:
> Re: https://mail.coreboot.org/pipermail/seabios/2017-October/011862.html
> 
> Did this ever get resolved? I didn't see a response to the final log.
> I'm experiencing the same thing on the same platform (ASUS C302 CAVE).
> 
> Card brand doesn't seem to matter. I've tried 32GB Samsung EVO cards,
> various SanDisk cards from 32GB to 128GB. None show up as boot options
> in SeaBIOS. If I use the exact same data/layout except on a smaller
> card like 1GB of any brand then it works no problem.
> 
> Same large cards boot fine off an external USB card reader. It appears
> to be an issue with the integrated SD card reader on the C302.
> 
> I'm using the same latest MrChromeBox build from May 2017.

No - the issue was not resolved.  We looked at it, but could not
figure out what the SD card (and/or controller) did not like about the
seabios initialization sequence.  The sd card would stop responding
and it wasn't clear what seabios was doing different from linux (which
apparently works fine on the same hardware).

As Paul mentions, if you'd like us to look at this further, please
include the debug logs of a session.  It's possible additional tests
on new hardware will reveal the issue.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 1/6] Introduce the floppy_dor_read() function

[Kevin O'Connor]

On Sun, Feb 04, 2018 at 05:26:56PM +0200, Nikolay Nikolov wrote:
> Signed-off-by: Nikolay Nikolov 

Thanks.  I made some minor changes to the commit messages and
committed this series.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Saving a few bytes across a reboot

[Laszlo Ersek]

On 02/07/18 17:44, Stefan Berger wrote:
> On 02/07/2018 10:50 AM, Laszlo Ersek wrote:

>> OK, but if the OS is allowed to modify this set of "queued operations",
>> then what protection is expected of SMM? Whether you can modify the TPM
>> directly, or queue random commands for it at libery, what's the
>> difference?
> 
> 
> On the OS level it is presumably an operation that is reserved to the
> admin to queue the operation.
> 
> I am not that familiar with UEFI and who is allowed to run code there
> and what code it can execute. But UEFI seems to lock the variable that
> holds that PPI code that tells it what to do after next reboot. So
> presumably a UEFI module cannot modify that variable but can only read
> it (and hopefully not manipulate NVRAM directly). If PPI was implemented
> through a memory location where the code gets written to it could do
> that likely easily (unless memory protections are setup by UEFI, which I
> don't know), cause a reset and have UEFI execute on that code.

This makes sense... but then it doesn't make sense :)

Assume that the variable is indeed "locked" (so that random UEFI drivers
/ apps cannot rewrite it using the UEFI variable service). Then,

- if the lock is enforced in SMM, then the variable will be locked from
  the OS as well, not just from 3rd party UEFI apps, so no PPI
  operations can ever be queued,

- if the lock is "simulated" in ACPI or in non-SMM firmare code (= in
  the "runtime DXE driver" layer), then the lock can be circumvented by
  both 3rd party UEFI apps and the OS.


>> Again, we have to see where the barrier is, between OS and firmware, or
>> between OS-level users:
>>
>> - In both cases, 3rd party UEFI apps / driver are considered equally
>>    privileged to the OS kernel;
>>
>> - in the OS<->firmware barrier case, SMM is required, and UEFI apps and
>>    the OS kernel are similarly restricted to submitting requests to SMM,
>>    and all the business verification belongs in SMM,
> 
> So SMM can verify whether the parameters it gets are valid. Whether now
> the user wanted to set operation 0 but the ACPI code submitted 5 (Clear
> TPM), would be a matter of verifying the ACPI code that's in-between. Is
> an attack via ACPI manipulation through some UEFI module possible?

Yes, it is possible.

There are dedicated UEFI (and PI -- "platform init") services for
installing new ACPI tables, and even for locating and parsing -- albeit
in a *very* cumbersome way -- existing ACPI tables (AML too). Once the
right ACPI objects are found, they can be overwritten.


> On the OS level it must remain a privileged operation of an admin to
> issue these PPI codes. That it is a privileged operation is implemented
> by the OS and I don't think we need to do anything. What we would want
> to prevent is abuse by a module that the firmware executes for example.
> I think this is the driving force for a UEFI variable and the fact that
> it's being locked (and later on unlocked so SMM mode can write to it ?)

This unlocking intrigues me. Assuming it happens in SMM, I have no idea
how the implementation tells apart the requestors (3rd party UEFI app
vs. OS).


> As for the use case, I would say it's automation on the OS level. From
> that perspective it's support could probably be deferred, which may
> eliminate at least the SMM part. However, UEFI uses the PPI mechanisms
> itself to issue certain commands when interacting with its menu. I am
> not sure whether SMM code is involved here... but for being able to use
> UEFI and TPM 2 at least for the UEFI support the PPI part needs to be
> there, otherwise the menu items one gets won't do anything. [The
> question is does UEFI execute ACPI or write directly in the UEFI
> varaible? My guess is the latter.]

I'm sorry, I'm out of my depth here. Can we re-have this discussion on
edk2-devel? (A bit later though, please, because currently I'm unable to
send email to edk2-devel. The 01.org list server recently dislikes
something about my emails and keeps rejecting them.)


>> (Sorry if this email is too long and confusing! I'm confused.)
> 
> Me too. I am not clear on specifics in UEFI, such as memory protections
> setup while a module is running in UEFI. Is NVRAM protected from
> overwrite?

Only SMRAM and pflash (aka NVRAM aka UEFI variables, on QEMU anyway) are
protected from direct hardware write.

Whether the write to SMRAM/pflash hardware comes from the OS or a 3rd
party UEFI app is irrelevent, both are prevented; only code running in
SMM is permitted write access.

Furthermore, it is irrelevant whether the OS or a 3rd party UEFI app is
the one that submits a request into SMM. If the request buffer passes
validation, then SMRAM and/or pflash (as appropriate) are updated. This
is to say that only the *data* in the request determine success vs.
failure; the "origin" of the request is unprovable and means nothing.


> Who can run a module in UEFI?

If you have write access to the EFI system partition, or can plug a PCI
card in

Re: [SeaBIOS] Saving a few bytes across a reboot

[Stefan Berger]

On 02/07/2018 10:50 AM, Laszlo Ersek wrote:

On 02/07/18 15:57, Stefan Berger wrote:

On 02/07/2018 09:18 AM, Laszlo Ersek wrote:

On 02/07/18 14:51, Stefan Berger wrote:

To support SeaBIOS as well, we would have to be
able to distinguish a BIOS from the UEFI on the QEMU level so that we
could produce different ACPI

Yes and no,


(no SMI and different OperationRegion than
0x  for SeaBIOS),

"yes" with regard to the SMM difference, "no" with regard to the
operation region. We have an ACPI linker/loader command that makes the
firmware basically just allocate memory, and we have two other ACPI
linker/loader commands that (a) patch the allocation address into other
ACPI artifacts, (b) return the allocation address to QEMU (for device
emulation purposes), if necessary.

I thought about allowing the firmware to configure the memory region to
use for the PPI interface. UEFI would say 0x , SeaBIOS would
choose some other area (0xFEF4 5000). Does the ACPI patcher handle this
case or does the address patching have to be set up while building the
tables in QEMU? If latter, then we would have to know in QEMU whether
it's going to be BIOS or UEFI as firmware. I have tried a lot of things
in the recent past, but I forgot whether this type of patching is possible.

The ACPI linker/loader commands are typically added to the "linker
script" in the very functions that build the ACPI payload.

And, distinguishing the firmwares is not necessary just for this; the
point of the firmware-side allocation is that QEMU does not dictate the
address. Each firmware is expected to use its own memory allocation
service, which in turn will ensure that the runtime OS stays away from
the allocated area. So the allocation address is ultimately determined
by the firmware.

The other two commands make the firmware patch the actual allocation
address (whatever it may be) into other ACPI artifacts, and make the
firmware pass the allocation address (whatever it may be) back to QEMU.


My operating knowledge about the TPM had been that

Components measure stuff into PCRs, and if any untrusted agent messes
with those measurements, for example by directly writing to the PCRs,
then the TPM will simply not unseal its secrets, hence such tampering
is self-defeating for those agents.

While this might be correct (I hope it is correct!), the *PPI* part of
TPM appears entirely different. In fact I don't have the slightest idea
*why* PPI is lumped together with the TPM.

The physical presence interface allows *automation of TPM operations and
changing the TPM's state* (such as clearing all keys) that are typically
only possible via interaction with the TPM menu in the firmware. Think
of it as some TPM operations that can only run successfully while the
system runs the firmware. Once the firmware has given control to the
next stage (bootloader, kernel) these operations are not possible
anymore since the firmware has execute some TPM commands that put the
TPM into a state so it wouldn't allow those operations anymore.

OK, but if the OS is allowed to modify this set of "queued operations",
then what protection is expected of SMM? Whether you can modify the TPM
directly, or queue random commands for it at libery, what's the difference?



On the OS level it is presumably an operation that is reserved to the 
admin to queue the operation.


I am not that familiar with UEFI and who is allowed to run code there 
and what code it can execute. But UEFI seems to lock the variable that 
holds that PPI code that tells it what to do after next reboot. So 
presumably a UEFI module cannot modify that variable but can only read 
it (and hopefully not manipulate NVRAM directly). If PPI was implemented 
through a memory location where the code gets written to it could do 
that likely easily (unless memory protections are setup by UEFI, which I 
don't know), cause a reset and have UEFI execute on that code.





Can you explain in more detail what the PPI operations are, and why they
need protection, from what agents exactly? What is the purported
lifecycle of such PPI operations?

With the clearing of the TPM one would loose all keys associated with
the TPM. So you don't want some software module to be able to set such a
'code', reset the machine, and the user looses all keys on the way. The
control has to be strongly with the admin.

Where is this barrier erected, between OS and firmware, or between
privileged and non-privileged OS user?


Between OS and firmware.



SMM is only relevant if the barrier is expected between OS and firmware;
i.e. you want to constrain the OS kernel to a subset of valid
operations. If the barrier is between privileged and non-privileged OS
user, then the implementation belongs in the OS kernel, since mere users
don't have direct hardware access anyway.

Also, to prevent fumbling with the variables, UEFI seems to make the variable 
read-only.

That seems to imply the barrier is between OS kernel and firmware

Re: [SeaBIOS] Saving a few bytes across a reboot

[Laszlo Ersek]

On 02/07/18 15:57, Stefan Berger wrote:
> On 02/07/2018 09:18 AM, Laszlo Ersek wrote:
>> On 02/07/18 14:51, Stefan Berger wrote:

>>> To support SeaBIOS as well, we would have to be
>>> able to distinguish a BIOS from the UEFI on the QEMU level so that we
>>> could produce different ACPI
>> Yes and no,
>>
>>> (no SMI and different OperationRegion than
>>> 0x  for SeaBIOS),
>> "yes" with regard to the SMM difference, "no" with regard to the
>> operation region. We have an ACPI linker/loader command that makes the
>> firmware basically just allocate memory, and we have two other ACPI
>> linker/loader commands that (a) patch the allocation address into other
>> ACPI artifacts, (b) return the allocation address to QEMU (for device
>> emulation purposes), if necessary.
> 
> I thought about allowing the firmware to configure the memory region to
> use for the PPI interface. UEFI would say 0x , SeaBIOS would
> choose some other area (0xFEF4 5000). Does the ACPI patcher handle this
> case or does the address patching have to be set up while building the
> tables in QEMU? If latter, then we would have to know in QEMU whether
> it's going to be BIOS or UEFI as firmware. I have tried a lot of things
> in the recent past, but I forgot whether this type of patching is possible.

The ACPI linker/loader commands are typically added to the "linker
script" in the very functions that build the ACPI payload.

And, distinguishing the firmwares is not necessary just for this; the
point of the firmware-side allocation is that QEMU does not dictate the
address. Each firmware is expected to use its own memory allocation
service, which in turn will ensure that the runtime OS stays away from
the allocated area. So the allocation address is ultimately determined
by the firmware.

The other two commands make the firmware patch the actual allocation
address (whatever it may be) into other ACPI artifacts, and make the
firmware pass the allocation address (whatever it may be) back to QEMU.

>> My operating knowledge about the TPM had been that
>>
>>    Components measure stuff into PCRs, and if any untrusted agent messes
>>    with those measurements, for example by directly writing to the PCRs,
>>    then the TPM will simply not unseal its secrets, hence such tampering
>>    is self-defeating for those agents.
>>
>> While this might be correct (I hope it is correct!), the *PPI* part of
>> TPM appears entirely different. In fact I don't have the slightest idea
>> *why* PPI is lumped together with the TPM.
> 
> The physical presence interface allows *automation of TPM operations and
> changing the TPM's state* (such as clearing all keys) that are typically
> only possible via interaction with the TPM menu in the firmware. Think
> of it as some TPM operations that can only run successfully while the
> system runs the firmware. Once the firmware has given control to the
> next stage (bootloader, kernel) these operations are not possible
> anymore since the firmware has execute some TPM commands that put the
> TPM into a state so it wouldn't allow those operations anymore.

OK, but if the OS is allowed to modify this set of "queued operations",
then what protection is expected of SMM? Whether you can modify the TPM
directly, or queue random commands for it at libery, what's the difference?

>> Can you explain in more detail what the PPI operations are, and why they
>> need protection, from what agents exactly? What is the purported
>> lifecycle of such PPI operations?
> 
> With the clearing of the TPM one would loose all keys associated with
> the TPM. So you don't want some software module to be able to set such a
> 'code', reset the machine, and the user looses all keys on the way. The
> control has to be strongly with the admin.

Where is this barrier erected, between OS and firmware, or between
privileged and non-privileged OS user?

SMM is only relevant if the barrier is expected between OS and firmware;
i.e. you want to constrain the OS kernel to a subset of valid
operations. If the barrier is between privileged and non-privileged OS
user, then the implementation belongs in the OS kernel, since mere users
don't have direct hardware access anyway.

> Also, to prevent fumbling with the variables, UEFI seems to make the variable 
> read-only.

That seems to imply the barrier is between OS kernel and firmware.

> I am wondering whether a malicious UEFI module could be written that
> patches the ACPI tables and does what it wants when it comes to these
> early TPM operations, rather than what the admin wants.

This is a good point, and it applies to more than just ACPI. The answer
is that it doesn't matter what *any* OS level code does -- as long as
the barrier is expected between OS and firmware --, because the SMM code
in the firmware must perform *complete* validation / verification of the
request.

Another example is the UEFI runtime variable services. In the
SMM_REQUIRE build of OVMF, those services are split to two pr

Re: [SeaBIOS] Saving a few bytes across a reboot

[Laszlo Ersek]

On 02/07/18 15:57, Igor Mammedov wrote:
> On Wed, 7 Feb 2018 08:51:58 -0500
> Stefan Berger  wrote:
> 
>> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
>>> Stefan,
>>>
>>> On 01/09/18 20:02, Stefan Berger wrote:
>>>  
> [...]
> 
>  
>> So the point is SMM is needed for UEFI. QEMU would need to provide the 
>> ACPI code for it, which is basically a translation of the ACPI from EDK2 
>> so that this could work. To support SeaBIOS as well, we would have to be 
>> able to distinguish a BIOS from the UEFI on the QEMU level so that we 
>> could produce different ACPI (no SMI and different OperationRegion than 
>> 0x  for SeaBIOS), *if* on a system with a BIOS the memory area 
>> can be considered to be safe (like that EDK2 variable).
> Does KVM actually restrict access to SMM memory (implements SMRR MSRs)?

KVM does not implement SMRRs, but QEMU+KVM implement SMRAM. OVMF exposes
the Q35 TSEG region as SMRAM to the edk2 machinery. TSEG is controlled
through various chipset registers.

Paolo's presentation and slides from 2015:

https://www.youtube.com/watch?v=IxLvxP1O8T8

> And even with SMRR, memory might be exposed to another cpu on
> cpu hotplug in current hotplug impl. if malicious code wins
> SIPI race in bringing up hotplugged CPU from (unprotected)
> reset state.

Yes, VCPU hotplug isn't even expected to work with SMM at the moment.
"Don't do that just yet."

https://bugzilla.redhat.com/show_bug.cgi?id=1454803

Thanks
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Saving a few bytes across a reboot

[Stefan Berger]

On 02/07/2018 09:18 AM, Laszlo Ersek wrote:

On 02/07/18 14:51, Stefan Berger wrote:

On 01/10/2018 08:22 AM, Laszlo Ersek wrote:

Stefan,

On 01/09/18 20:02, Stefan Berger wrote:


Another twist is that Intel's EDK2 also implements this but the data
structure layout is different and they use SMM + SMIs etc.

https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81


As I described in my investigation linked from
, we should not
include the Tcg2Smm driver in OVMF, for TPM enablement -- at least for
the short & mid terms.

What does the Tcg2Smm driver do? In section (2f), I described that the
driver installs two tables, "TPM2" and an "SSDT".

- The TPM2 table from this driver is unneeded, since QEMU generates its
own TPM2 table, which describes the TPM device's access method --
TIS+Cancel (method 6).

- The SSDT from the driver is again unneeded. It provides (via the _DSM
method) an ACPI-level API that the OS can use, for talking to the TPM
device. An implementation detail of this ACPI method is that it raises
an SMI, for entering the firmware at an elevated privilege level (= in
SMM). Then, the actual TPM hardware manipulation, or even the TPM
*software emulation*, is performed by the firmware, in SMM.

This approach is totally ill-suited for the QEMU virtualization stack.
For starters, none of the firmware code exist -- as open source anyway
-- that would actually handle such ACPI->SMM requests. Second, I'm sure
we don't want to debug TPM software emulation running in SMM guest
firmware, rather than an actual QEMU device model.

Once we have a real device model, accessed via IO ports and/or MMIO
locations, perhaps in combination with request/response buffers
allocated in guest RAM, the SMI/SMM implementation detail falls away
completely. Our TPM emulation would attain its "privileged / protected"
status simply by existing in the hypervisor (QEMU).


Regarding the SMI/SMM: I think it will be needed for the TPM Physical
Presence interface where ACPI gets a code from the user that it sends to
the firmware and the firmware acts upon next reboot. SMM stores this
code in a UEFI variable (EDK2) to protect it from modules executed by
UEFI. I was trying to use a memory area (PPI memory device) for storing
this code but it would not give the same protection for UEFI compared to
the variable. I suppose the reason is that UEFI can execute (untrusted)
code that could manipulate this memory area and cause unwanted changes
to the TPM upon reboot by for example writing a code for clearing the
TPM. How 'safe' would the BIOS be or any path from the BIOS until the OS
kernel takes over? Can untrusted code be executed by something like a
BIOS module (vgabios.bin and the like) and mess with that memory area? A
grub module?

Yes, this is a correct assessment in my view. SMM provides protection to
platform firmware modules not only against the OS, but also against 3rd
party firmware components, such as boot loaders, various UEFI
applications, UEFI device drivers (loaded from disk or PCI card option
ROM BARs), and such.

SMRAM and the writeable pflash chip are two pieces of emulated hardware
whose (write) access is restricted to code executing in SMM.

This does not necessarily imply that QEMU should generate SMI-triggering
AML methods for the guest. Instead, the sensitive writeable register
block of the TPM chip that you added could be restricted to code
executing in SMM, similarly to pflash:

   -global driver=cfi.pflash01,property=secure,value=on

... On the other hand, I do realize this would take custom SMM code,
which is even worse than reusing the SMM variable service code.

Sigh, I *utterly* hate this. I maintain from my earlier email that
generating ACPI for this in QEMU is ill-suited. Minimally, the TPM2
table will conflict between edk2 and QEMU. edk2 will be *both* missing
code that's going to be necessary for the QEMU/OVMF use case, *and* it
will contain code that either conflicts with or is not dynamic enough
for the QEMU/OVMF use case.


One other complication is the memory area that EDK2 requires for
exchanging of data ('that code' for example) between ACPI and SMM. It's
hard coded to 0x . However, with SeaBIOS I cannot use this
memory and there's this comment here: 'src/fw/shadow.c:// On the
emulators, the bios at 0xf is also at 0x'.

So the point is SMM is needed for UEFI. QEMU would need to provide the
ACPI code for it, which is basically a translation of the ACPI from EDK2
so that this could work.

OK.


To support SeaBIOS as well, we would have to be
able to distinguish a BIOS from the UEFI on the QEMU level so that we
could produce different ACPI

Yes and no,


(no SMI and different OperationRegion than
0x  for SeaBIOS),

"yes" with regard to the SMM difference, "no" with regard to the
operation region. We have an ACPI linker/loader command that makes the
firmware basically 

Re: [SeaBIOS] Saving a few bytes across a reboot

[Igor Mammedov]

On Wed, 7 Feb 2018 08:51:58 -0500
Stefan Berger  wrote:

> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
> > Stefan,
> >
> > On 01/09/18 20:02, Stefan Berger wrote:
> >  
[...]

 
> So the point is SMM is needed for UEFI. QEMU would need to provide the 
> ACPI code for it, which is basically a translation of the ACPI from EDK2 
> so that this could work. To support SeaBIOS as well, we would have to be 
> able to distinguish a BIOS from the UEFI on the QEMU level so that we 
> could produce different ACPI (no SMI and different OperationRegion than 
> 0x  for SeaBIOS), *if* on a system with a BIOS the memory area 
> can be considered to be safe (like that EDK2 variable).
Does KVM actually restrict access to SMM memory (implements SMRR MSRs)?

And even with SMRR, memory might be exposed to another cpu on
cpu hotplug in current hotplug impl. if malicious code wins
SIPI race in bringing up hotplugged CPU from (unprotected)
reset state.


> Otherwise I am 
> afraid it's better to not support it in SeaBIOS and provide all 
> necessary early TPM 2 operations via user interaction with the menu only.
> 
> Comments ?
> 
>   Stefan
> 


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Saving a few bytes across a reboot

[Laszlo Ersek]

On 02/07/18 14:51, Stefan Berger wrote:
> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
>> Stefan,
>>
>> On 01/09/18 20:02, Stefan Berger wrote:
>>
>>> Another twist is that Intel's EDK2 also implements this but the data
>>> structure layout is different and they use SMM + SMIs etc.
>>>
>>> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81
>>>
>> As I described in my investigation linked from
>> , we should not
>> include the Tcg2Smm driver in OVMF, for TPM enablement -- at least for
>> the short & mid terms.
>>
>> What does the Tcg2Smm driver do? In section (2f), I described that the
>> driver installs two tables, "TPM2" and an "SSDT".
>>
>> - The TPM2 table from this driver is unneeded, since QEMU generates its
>>    own TPM2 table, which describes the TPM device's access method --
>>    TIS+Cancel (method 6).
>>
>> - The SSDT from the driver is again unneeded. It provides (via the _DSM
>>    method) an ACPI-level API that the OS can use, for talking to the TPM
>>    device. An implementation detail of this ACPI method is that it raises
>>    an SMI, for entering the firmware at an elevated privilege level (= in
>>    SMM). Then, the actual TPM hardware manipulation, or even the TPM
>>    *software emulation*, is performed by the firmware, in SMM.
>>
>> This approach is totally ill-suited for the QEMU virtualization stack.
>> For starters, none of the firmware code exist -- as open source anyway
>> -- that would actually handle such ACPI->SMM requests. Second, I'm sure
>> we don't want to debug TPM software emulation running in SMM guest
>> firmware, rather than an actual QEMU device model.
>>
>> Once we have a real device model, accessed via IO ports and/or MMIO
>> locations, perhaps in combination with request/response buffers
>> allocated in guest RAM, the SMI/SMM implementation detail falls away
>> completely. Our TPM emulation would attain its "privileged / protected"
>> status simply by existing in the hypervisor (QEMU).
> 
> 
> Regarding the SMI/SMM: I think it will be needed for the TPM Physical
> Presence interface where ACPI gets a code from the user that it sends to
> the firmware and the firmware acts upon next reboot. SMM stores this
> code in a UEFI variable (EDK2) to protect it from modules executed by
> UEFI. I was trying to use a memory area (PPI memory device) for storing
> this code but it would not give the same protection for UEFI compared to
> the variable. I suppose the reason is that UEFI can execute (untrusted)
> code that could manipulate this memory area and cause unwanted changes
> to the TPM upon reboot by for example writing a code for clearing the
> TPM. How 'safe' would the BIOS be or any path from the BIOS until the OS
> kernel takes over? Can untrusted code be executed by something like a
> BIOS module (vgabios.bin and the like) and mess with that memory area? A
> grub module?

Yes, this is a correct assessment in my view. SMM provides protection to
platform firmware modules not only against the OS, but also against 3rd
party firmware components, such as boot loaders, various UEFI
applications, UEFI device drivers (loaded from disk or PCI card option
ROM BARs), and such.

SMRAM and the writeable pflash chip are two pieces of emulated hardware
whose (write) access is restricted to code executing in SMM.

This does not necessarily imply that QEMU should generate SMI-triggering
AML methods for the guest. Instead, the sensitive writeable register
block of the TPM chip that you added could be restricted to code
executing in SMM, similarly to pflash:

  -global driver=cfi.pflash01,property=secure,value=on

... On the other hand, I do realize this would take custom SMM code,
which is even worse than reusing the SMM variable service code.

Sigh, I *utterly* hate this. I maintain from my earlier email that
generating ACPI for this in QEMU is ill-suited. Minimally, the TPM2
table will conflict between edk2 and QEMU. edk2 will be *both* missing
code that's going to be necessary for the QEMU/OVMF use case, *and* it
will contain code that either conflicts with or is not dynamic enough
for the QEMU/OVMF use case.

> One other complication is the memory area that EDK2 requires for
> exchanging of data ('that code' for example) between ACPI and SMM. It's
> hard coded to 0x . However, with SeaBIOS I cannot use this
> memory and there's this comment here: 'src/fw/shadow.c:// On the
> emulators, the bios at 0xf is also at 0x'.
> 
> So the point is SMM is needed for UEFI. QEMU would need to provide the
> ACPI code for it, which is basically a translation of the ACPI from EDK2
> so that this could work.

OK.

> To support SeaBIOS as well, we would have to be
> able to distinguish a BIOS from the UEFI on the QEMU level so that we
> could produce different ACPI

Yes and no,

> (no SMI and different OperationRegion than
> 0x  for SeaBIOS),

"yes" with regard to the SMM difference, "n

Re: [SeaBIOS] Saving a few bytes across a reboot

[Stefan Berger]

On 01/10/2018 08:22 AM, Laszlo Ersek wrote:

Stefan,

On 01/09/18 20:02, Stefan Berger wrote:


Another twist is that Intel's EDK2 also implements this but the data
structure layout is different and they use SMM + SMIs etc.

https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81

As I described in my investigation linked from
, we should not
include the Tcg2Smm driver in OVMF, for TPM enablement -- at least for
the short & mid terms.

What does the Tcg2Smm driver do? In section (2f), I described that the
driver installs two tables, "TPM2" and an "SSDT".

- The TPM2 table from this driver is unneeded, since QEMU generates its
   own TPM2 table, which describes the TPM device's access method --
   TIS+Cancel (method 6).

- The SSDT from the driver is again unneeded. It provides (via the _DSM
   method) an ACPI-level API that the OS can use, for talking to the TPM
   device. An implementation detail of this ACPI method is that it raises
   an SMI, for entering the firmware at an elevated privilege level (= in
   SMM). Then, the actual TPM hardware manipulation, or even the TPM
   *software emulation*, is performed by the firmware, in SMM.

This approach is totally ill-suited for the QEMU virtualization stack.
For starters, none of the firmware code exist -- as open source anyway
-- that would actually handle such ACPI->SMM requests. Second, I'm sure
we don't want to debug TPM software emulation running in SMM guest
firmware, rather than an actual QEMU device model.

Once we have a real device model, accessed via IO ports and/or MMIO
locations, perhaps in combination with request/response buffers
allocated in guest RAM, the SMI/SMM implementation detail falls away
completely. Our TPM emulation would attain its "privileged / protected"
status simply by existing in the hypervisor (QEMU).



Regarding the SMI/SMM: I think it will be needed for the TPM Physical 
Presence interface where ACPI gets a code from the user that it sends to 
the firmware and the firmware acts upon next reboot. SMM stores this 
code in a UEFI variable (EDK2) to protect it from modules executed by 
UEFI. I was trying to use a memory area (PPI memory device) for storing 
this code but it would not give the same protection for UEFI compared to 
the variable. I suppose the reason is that UEFI can execute (untrusted) 
code that could manipulate this memory area and cause unwanted changes 
to the TPM upon reboot by for example writing a code for clearing the 
TPM. How 'safe' would the BIOS be or any path from the BIOS until the OS 
kernel takes over? Can untrusted code be executed by something like a 
BIOS module (vgabios.bin and the like) and mess with that memory area? A 
grub module?


One other complication is the memory area that EDK2 requires for 
exchanging of data ('that code' for example) between ACPI and SMM. It's 
hard coded to 0x . However, with SeaBIOS I cannot use this 
memory and there's this comment here: 'src/fw/shadow.c:// On the 
emulators, the bios at 0xf is also at 0x'.


So the point is SMM is needed for UEFI. QEMU would need to provide the 
ACPI code for it, which is basically a translation of the ACPI from EDK2 
so that this could work. To support SeaBIOS as well, we would have to be 
able to distinguish a BIOS from the UEFI on the QEMU level so that we 
could produce different ACPI (no SMI and different OperationRegion than 
0x  for SeaBIOS), *if* on a system with a BIOS the memory area 
can be considered to be safe (like that EDK2 variable). Otherwise I am 
afraid it's better to not support it in SeaBIOS and provide all 
necessary early TPM 2 operations via user interaction with the menu only.


Comments ?

 Stefan


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Failure to detect high-capacity SD card

[Paul Menzel]

Dear Chris,


Am 07.02.2018 um 01:38 schrieb Chris:

Re: https://mail.coreboot.org/pipermail/seabios/2017-October/011862.html

Did this ever get resolved? I didn't see a response to the final log.
I'm experiencing the same thing on the same platform (ASUS C302 CAVE).

Card brand doesn't seem to matter. I've tried 32GB Samsung EVO cards,
various SanDisk cards from 32GB to 128GB. None show up as boot options
in SeaBIOS. If I use the exact same data/layout except on a smaller
card like 1GB of any brand then it works no problem.

Same large cards boot fine off an external USB card reader. It appears
to be an issue with the integrated SD card reader on the C302.

I'm using the same latest MrChromeBox build from May 2017. >
Any ideas?


Please tell us what SeaBIOS version you use, and attach the debug logs 
from a working and non-working setup.



Kind regards,

Paul

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios