Date   

Re: UEFI accessibility mandate

Rafael Machado <rafaelrodrigues.machado@...>
 

Hi Ethin and all

As Leif mentioned, my mastering thesys was the implementation of a
reference code so a driver for audio at pre-OS would be possible,
eliminating the first barrier for the creation of a screen reader at UEFI,
that is the lack of audio drivers.

My project was based on Intel High Definition Audio, so it is not a generic
code that would fit at all scenarios, but it a first step.
The idea was to proceed this work using the Google Summer of Code
initiative,and I will try my best to make this happen in future editions of
this initiative.
Unfortunately my thesys was written in portuguese, because there was almost
nothing related to BIOS in Portuguese, so the decision was to write in
Portuguese to help the community to attract brasilian developers. As soon
as I find some slot, I'll translate to english.
But you are not alone. Just in Brazil I discovered around 30 blind
developers that area waiting for accessibility at BIOS. Also had some
contacts from US and Ireland.
So it is a market to be explored. Everyone will win.
The companies, because they will attract more people and their families,
and the ones who need accessibility.
By the way, most of the population will need accessible solutions if they
live enough. This includes the uefi community members, that today do not
have special needs, but that may require it in future.
Accessibility is not a wast of money.
This ia what I would like to show to the UEFI community.
Hope to have the opportunity to present this in some future event.

Since this discussion was started, who knows what are the next steps?
My code is available at github if someone gets interested (ps.: The code
has failures. It was just a Prof of Concept)

https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility

Lets keep the discussion, because it is important.

Thanks and Regards
Rafael R. Machado


Em ter, 10 de set de 2019 17:00, Ethin Probst <harlydavidsen@...>
escreveu:

Woops, I just realized while reading my message after I'd sent it that
I had linked to the wrong document. The priority system is outlined
over here (https://freebsoft.org/doc/speechd/ssip.html#Top). This
document discusses SsIP -- the Speech Synthesis Interface Protocol.

On 9/10/19, Ethin Probst <harlydavidsen@...> wrote:
While conquering refreshable braille displays would be nice, I think
we should take it in stages. (Some blind people would want this in
along with the accessibility subsystems, however I do not believe that
would be the wisest approach.) Instead, I think we should do what you
suggest: implement protocols for communicating with audio devices
(both input and output) and add audio hooks for the HII. (We could
even make those audio hooks just general hooks/events instead of
partitioning them for a particular purpose.)
You mentioned that not all devices 'have a keyboard'. This is most
definitely true, but not all devices have audio outputs and/or inputs
either. Therefore, if we can't mandate it for *all* devices, perhaps
we could only mandate it (or at least somehow infer it as a
requirement) for devices that both have an interaction mechanism (any
form of interacting with the system directly via the HII and not, say,
over the wire, because that would be superfluous) and have
mechanisms/devices/drivers/... for audio output at minimum. (Audio
input is not necessarily something that is required unless the device
is controlled primarily by voice, but I think having voice controls is
a bit beyond the UEFI specification and is not something UEFI should
worry about. Voice control is not something you should have in the
preboot environment anyway, correct?)
So, I think the first stage we should work on should include:
- Implementing protocols for communicating with audio outputs (don't
worry about inputs right now)
- Implementing protocols/hooks/events that can be intercepted in the
HII by a foreground/background UEFI driver/application
- Implementing some kind of method to allow the accessibility
protocols to read what is drawn to the text when navigating around
The third item -- when implemented properly -- will prevent the
accessibility subsystem from reading everything on the screen every
time the "cursor" moves. Perhaps another good idea would be to
implement some kind of priority system for text-to-speech, like speech
dispatcher does
(
https://docs.microsoft.com/en-us/cortana/skills/speech-synthesis-markup-language
).

On 9/10/19, Leif Lindholm <leif.lindholm@...> wrote:
Hi Ethin,

Apologies for the delay in responding - I personally don't tend to
read the RFC list (and I know that applies to some other developers
who have now subscribed).

On Sun, Aug 11, 2019 at 06:15:18PM -0700, Ethin Probst wrote:
Hello all,

I'm new here, and was recommended to the TianoCore project by
someone over at the UEFI forum. I've run across TianoCore before,
and like the project.
Before anyone gets worried by the subject line, no, this is not any
kind of legal thing. Its just something I believe needs to
happen. :)
Back in 2016-2017 I contacted the UEFI forum about two problems, one
of which was the format of the spec, which I figured out on my
own. The other problem was not so easily dealt with. Te other
problem relates to accessibility of UEFI-compliant systems and
platform firmware to persons with disabilities. As it currently
stands, such a thing is nonexistent. To be fair, I completely
understand the difficulty that such a thing would require, and I
would fully agree if we still used the PC-AT BIOS systems -- yes,
indeed, I would never suggest this kind of thing on such a system
given that there was no actual standard of any kind for
BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have
access to their computers in the general sense (I am blind
myself). We can do pretty much anything anyone else could do. We can
code, play games, all that. There are few things that we cannot
do. One of those things is managing our systems firmware in the
preboot environment.
As it stands now, I can only boot other OSes or disks via
memorization. While that worked on BIOS machines (I have, or had, an
old Toshiba laptop that was BIOS-based), it no longer works because
UEFI is mercurial. When I access the boot menu now, I play a game of
chance. If the cards are in my favor, the OS I want to boot boots,
and I can go on my way. But if the cards aren't in my favor, I end
up making something happen that was unintended, and, worst of all, I
have no idea what I did.
However, the boot menu is only one portion of a platform firmware
UI. What about the setup utility or other utilities offered by
computer manufacturers? What about diagnostic utilities,
bootloaders, etc? What do I do with those? Well, I only have one
option -- sited assistance. If I go into my computers setup utility,
I cannot trust myself and say to myself, "OK, I know what I'm
doing. All I need to do is change x and save and quit." No, I can't
do that, because memorizing such a complex interface is extremely
difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd like
comments and feedback before it actually gets implemented (it will
take a lot of time, I'm sure): mandate, in the UEFI specification,
that accessibility features for persons with disabilities must be
implemented and documented, and, if such features are not
implemented, then that vendor is not compliant with the
specification. Place strict minimum requirements for what the
accessibility features should do and how they should work.
So, first of all, I need to point out that what you suggest would be
very difficult for the UEFI Forum to mandate. *But* I don't think this
needs to be a problem.

UEFI primarily exists as a means through which interoperability can be
guaranteed. This means it does not tend to so much mandate what is
actually implemented in a platform, as it defines how it behaves if it
is. This is not 100% true, but suffice to say that mandating the
functionality you are asking for *without* having a reference
implementation available would likely simply be ignored.

If you want to turn thumbscrews, get Microsoft to add the requirement
to their windows logo requirements :)

However, as much as it is difficult to force people to develop this
support, if a functional reference implementation was published under
a permissive open source license, it would take a pretty spectacularly
incompetent product owner not to incorporate it in their products.

Now, I'm sure someone out there will ask me how this can be
done. Well, that's why I've joined the group -- though as I
familiarize myself with EDK2 development and all that I may actually
be able to participate as more than just an accessibility expert, of
sorts.
I have added Rafael Machado on cc. He did a PhD on firmware
accessibility, including a prototype implementing an audio driver for
EDK2. The resulting thesis can be found at
https://arxiv.org/abs/1712.03186 .

As a side note, I have been blind all my life. I was born with
retinopathy of prematurity (ROP), which resulted because I was born
at 26 weeks. My retina was detached, and, though the doctors
attempted to fix it, it would not remain attached, and there is no
chance of it getting fixed now. I would neither want nor care for
such a cure, however. I have lived my entire life blind, and while
the thought of gaining site back is appealing, I am unwilling to go
through the years and years of rewiring and reconditioning of my
brain that would be required for me to survive with site. To me, it
is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss how
the accessibility features would work and what would be
required. Even standardizing, through the specification, a key
combination to toggle the accessibility features would be nice, as
that would alleviate the major problem of a blind person buying a
new computer and not knowing how to enable the accessibility
features. The overarching goal would be to make the preboot
environment (including applications run within it) accessible and
usable by blind and visually impaired people as a boot service
only.
Yes, I agree, operating systems are already doing their things.

Again, mandating such a key combination is not necessarily something
that the UEFI specification can do. Some devices won't necessarily
have a keyboard.

Some things the UEFI specification could do is:
- Add protocols for Audio output (and possibly input) and talking to
audio codecs.
- Add audio hooks for the Human Interaction Interface subsystem (HII).

EDK2 could then start adding device drivers producing these protocols,
and enable the support for some reference platforms.

Would we need any specific support for things like refreshable braille
displays?

It would be superfluous to make this a runtime service, as all
major OSes already have accessibility features. Plus, managing such
a thing would be impossible to do.
Agreed.

This email has gotten quite long, so I will suspend the discussion
of functionality and how I would like it to work for a future email
once everyone has gotten on board.
Best Regards,

Leif


Thank you for your time and consideration.



--
Signed,
Ethin D. Probst

--
Signed,
Ethin D. Probst


Re: UEFI accessibility mandate

Ethin Probst
 

Woops, I just realized while reading my message after I'd sent it that
I had linked to the wrong document. The priority system is outlined
over here (https://freebsoft.org/doc/speechd/ssip.html#Top). This
document discusses SsIP -- the Speech Synthesis Interface Protocol.

On 9/10/19, Ethin Probst <harlydavidsen@...> wrote:
While conquering refreshable braille displays would be nice, I think
we should take it in stages. (Some blind people would want this in
along with the accessibility subsystems, however I do not believe that
would be the wisest approach.) Instead, I think we should do what you
suggest: implement protocols for communicating with audio devices
(both input and output) and add audio hooks for the HII. (We could
even make those audio hooks just general hooks/events instead of
partitioning them for a particular purpose.)
You mentioned that not all devices 'have a keyboard'. This is most
definitely true, but not all devices have audio outputs and/or inputs
either. Therefore, if we can't mandate it for *all* devices, perhaps
we could only mandate it (or at least somehow infer it as a
requirement) for devices that both have an interaction mechanism (any
form of interacting with the system directly via the HII and not, say,
over the wire, because that would be superfluous) and have
mechanisms/devices/drivers/... for audio output at minimum. (Audio
input is not necessarily something that is required unless the device
is controlled primarily by voice, but I think having voice controls is
a bit beyond the UEFI specification and is not something UEFI should
worry about. Voice control is not something you should have in the
preboot environment anyway, correct?)
So, I think the first stage we should work on should include:
- Implementing protocols for communicating with audio outputs (don't
worry about inputs right now)
- Implementing protocols/hooks/events that can be intercepted in the
HII by a foreground/background UEFI driver/application
- Implementing some kind of method to allow the accessibility
protocols to read what is drawn to the text when navigating around
The third item -- when implemented properly -- will prevent the
accessibility subsystem from reading everything on the screen every
time the "cursor" moves. Perhaps another good idea would be to
implement some kind of priority system for text-to-speech, like speech
dispatcher does
(https://docs.microsoft.com/en-us/cortana/skills/speech-synthesis-markup-language).

On 9/10/19, Leif Lindholm <leif.lindholm@...> wrote:
Hi Ethin,

Apologies for the delay in responding - I personally don't tend to
read the RFC list (and I know that applies to some other developers
who have now subscribed).

On Sun, Aug 11, 2019 at 06:15:18PM -0700, Ethin Probst wrote:
Hello all,

I'm new here, and was recommended to the TianoCore project by
someone over at the UEFI forum. I've run across TianoCore before,
and like the project.
Before anyone gets worried by the subject line, no, this is not any
kind of legal thing. Its just something I believe needs to
happen. :)
Back in 2016-2017 I contacted the UEFI forum about two problems, one
of which was the format of the spec, which I figured out on my
own. The other problem was not so easily dealt with. Te other
problem relates to accessibility of UEFI-compliant systems and
platform firmware to persons with disabilities. As it currently
stands, such a thing is nonexistent. To be fair, I completely
understand the difficulty that such a thing would require, and I
would fully agree if we still used the PC-AT BIOS systems -- yes,
indeed, I would never suggest this kind of thing on such a system
given that there was no actual standard of any kind for
BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have
access to their computers in the general sense (I am blind
myself). We can do pretty much anything anyone else could do. We can
code, play games, all that. There are few things that we cannot
do. One of those things is managing our systems firmware in the
preboot environment.
As it stands now, I can only boot other OSes or disks via
memorization. While that worked on BIOS machines (I have, or had, an
old Toshiba laptop that was BIOS-based), it no longer works because
UEFI is mercurial. When I access the boot menu now, I play a game of
chance. If the cards are in my favor, the OS I want to boot boots,
and I can go on my way. But if the cards aren't in my favor, I end
up making something happen that was unintended, and, worst of all, I
have no idea what I did.
However, the boot menu is only one portion of a platform firmware
UI. What about the setup utility or other utilities offered by
computer manufacturers? What about diagnostic utilities,
bootloaders, etc? What do I do with those? Well, I only have one
option -- sited assistance. If I go into my computers setup utility,
I cannot trust myself and say to myself, "OK, I know what I'm
doing. All I need to do is change x and save and quit." No, I can't
do that, because memorizing such a complex interface is extremely
difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd like
comments and feedback before it actually gets implemented (it will
take a lot of time, I'm sure): mandate, in the UEFI specification,
that accessibility features for persons with disabilities must be
implemented and documented, and, if such features are not
implemented, then that vendor is not compliant with the
specification. Place strict minimum requirements for what the
accessibility features should do and how they should work.
So, first of all, I need to point out that what you suggest would be
very difficult for the UEFI Forum to mandate. *But* I don't think this
needs to be a problem.

UEFI primarily exists as a means through which interoperability can be
guaranteed. This means it does not tend to so much mandate what is
actually implemented in a platform, as it defines how it behaves if it
is. This is not 100% true, but suffice to say that mandating the
functionality you are asking for *without* having a reference
implementation available would likely simply be ignored.

If you want to turn thumbscrews, get Microsoft to add the requirement
to their windows logo requirements :)

However, as much as it is difficult to force people to develop this
support, if a functional reference implementation was published under
a permissive open source license, it would take a pretty spectacularly
incompetent product owner not to incorporate it in their products.

Now, I'm sure someone out there will ask me how this can be
done. Well, that's why I've joined the group -- though as I
familiarize myself with EDK2 development and all that I may actually
be able to participate as more than just an accessibility expert, of
sorts.
I have added Rafael Machado on cc. He did a PhD on firmware
accessibility, including a prototype implementing an audio driver for
EDK2. The resulting thesis can be found at
https://arxiv.org/abs/1712.03186 .

As a side note, I have been blind all my life. I was born with
retinopathy of prematurity (ROP), which resulted because I was born
at 26 weeks. My retina was detached, and, though the doctors
attempted to fix it, it would not remain attached, and there is no
chance of it getting fixed now. I would neither want nor care for
such a cure, however. I have lived my entire life blind, and while
the thought of gaining site back is appealing, I am unwilling to go
through the years and years of rewiring and reconditioning of my
brain that would be required for me to survive with site. To me, it
is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss how
the accessibility features would work and what would be
required. Even standardizing, through the specification, a key
combination to toggle the accessibility features would be nice, as
that would alleviate the major problem of a blind person buying a
new computer and not knowing how to enable the accessibility
features. The overarching goal would be to make the preboot
environment (including applications run within it) accessible and
usable by blind and visually impaired people as a boot service
only.
Yes, I agree, operating systems are already doing their things.

Again, mandating such a key combination is not necessarily something
that the UEFI specification can do. Some devices won't necessarily
have a keyboard.

Some things the UEFI specification could do is:
- Add protocols for Audio output (and possibly input) and talking to
audio codecs.
- Add audio hooks for the Human Interaction Interface subsystem (HII).

EDK2 could then start adding device drivers producing these protocols,
and enable the support for some reference platforms.

Would we need any specific support for things like refreshable braille
displays?

It would be superfluous to make this a runtime service, as all
major OSes already have accessibility features. Plus, managing such
a thing would be impossible to do.
Agreed.

This email has gotten quite long, so I will suspend the discussion
of functionality and how I would like it to work for a future email
once everyone has gotten on board.
Best Regards,

Leif


Thank you for your time and consideration.



--
Signed,
Ethin D. Probst
--
Signed,
Ethin D. Probst


Re: UEFI accessibility mandate

Ethin Probst
 

While conquering refreshable braille displays would be nice, I think
we should take it in stages. (Some blind people would want this in
along with the accessibility subsystems, however I do not believe that
would be the wisest approach.) Instead, I think we should do what you
suggest: implement protocols for communicating with audio devices
(both input and output) and add audio hooks for the HII. (We could
even make those audio hooks just general hooks/events instead of
partitioning them for a particular purpose.)
You mentioned that not all devices 'have a keyboard'. This is most
definitely true, but not all devices have audio outputs and/or inputs
either. Therefore, if we can't mandate it for *all* devices, perhaps
we could only mandate it (or at least somehow infer it as a
requirement) for devices that both have an interaction mechanism (any
form of interacting with the system directly via the HII and not, say,
over the wire, because that would be superfluous) and have
mechanisms/devices/drivers/... for audio output at minimum. (Audio
input is not necessarily something that is required unless the device
is controlled primarily by voice, but I think having voice controls is
a bit beyond the UEFI specification and is not something UEFI should
worry about. Voice control is not something you should have in the
preboot environment anyway, correct?)
So, I think the first stage we should work on should include:
- Implementing protocols for communicating with audio outputs (don't
worry about inputs right now)
- Implementing protocols/hooks/events that can be intercepted in the
HII by a foreground/background UEFI driver/application
- Implementing some kind of method to allow the accessibility
protocols to read what is drawn to the text when navigating around
The third item -- when implemented properly -- will prevent the
accessibility subsystem from reading everything on the screen every
time the "cursor" moves. Perhaps another good idea would be to
implement some kind of priority system for text-to-speech, like speech
dispatcher does
(https://docs.microsoft.com/en-us/cortana/skills/speech-synthesis-markup-language).

On 9/10/19, Leif Lindholm <leif.lindholm@...> wrote:
Hi Ethin,

Apologies for the delay in responding - I personally don't tend to
read the RFC list (and I know that applies to some other developers
who have now subscribed).

On Sun, Aug 11, 2019 at 06:15:18PM -0700, Ethin Probst wrote:
Hello all,

I'm new here, and was recommended to the TianoCore project by
someone over at the UEFI forum. I've run across TianoCore before,
and like the project.
Before anyone gets worried by the subject line, no, this is not any
kind of legal thing. Its just something I believe needs to
happen. :)
Back in 2016-2017 I contacted the UEFI forum about two problems, one
of which was the format of the spec, which I figured out on my
own. The other problem was not so easily dealt with. Te other
problem relates to accessibility of UEFI-compliant systems and
platform firmware to persons with disabilities. As it currently
stands, such a thing is nonexistent. To be fair, I completely
understand the difficulty that such a thing would require, and I
would fully agree if we still used the PC-AT BIOS systems -- yes,
indeed, I would never suggest this kind of thing on such a system
given that there was no actual standard of any kind for
BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have
access to their computers in the general sense (I am blind
myself). We can do pretty much anything anyone else could do. We can
code, play games, all that. There are few things that we cannot
do. One of those things is managing our systems firmware in the
preboot environment.
As it stands now, I can only boot other OSes or disks via
memorization. While that worked on BIOS machines (I have, or had, an
old Toshiba laptop that was BIOS-based), it no longer works because
UEFI is mercurial. When I access the boot menu now, I play a game of
chance. If the cards are in my favor, the OS I want to boot boots,
and I can go on my way. But if the cards aren't in my favor, I end
up making something happen that was unintended, and, worst of all, I
have no idea what I did.
However, the boot menu is only one portion of a platform firmware
UI. What about the setup utility or other utilities offered by
computer manufacturers? What about diagnostic utilities,
bootloaders, etc? What do I do with those? Well, I only have one
option -- sited assistance. If I go into my computers setup utility,
I cannot trust myself and say to myself, "OK, I know what I'm
doing. All I need to do is change x and save and quit." No, I can't
do that, because memorizing such a complex interface is extremely
difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd like
comments and feedback before it actually gets implemented (it will
take a lot of time, I'm sure): mandate, in the UEFI specification,
that accessibility features for persons with disabilities must be
implemented and documented, and, if such features are not
implemented, then that vendor is not compliant with the
specification. Place strict minimum requirements for what the
accessibility features should do and how they should work.
So, first of all, I need to point out that what you suggest would be
very difficult for the UEFI Forum to mandate. *But* I don't think this
needs to be a problem.

UEFI primarily exists as a means through which interoperability can be
guaranteed. This means it does not tend to so much mandate what is
actually implemented in a platform, as it defines how it behaves if it
is. This is not 100% true, but suffice to say that mandating the
functionality you are asking for *without* having a reference
implementation available would likely simply be ignored.

If you want to turn thumbscrews, get Microsoft to add the requirement
to their windows logo requirements :)

However, as much as it is difficult to force people to develop this
support, if a functional reference implementation was published under
a permissive open source license, it would take a pretty spectacularly
incompetent product owner not to incorporate it in their products.

Now, I'm sure someone out there will ask me how this can be
done. Well, that's why I've joined the group -- though as I
familiarize myself with EDK2 development and all that I may actually
be able to participate as more than just an accessibility expert, of
sorts.
I have added Rafael Machado on cc. He did a PhD on firmware
accessibility, including a prototype implementing an audio driver for
EDK2. The resulting thesis can be found at
https://arxiv.org/abs/1712.03186 .

As a side note, I have been blind all my life. I was born with
retinopathy of prematurity (ROP), which resulted because I was born
at 26 weeks. My retina was detached, and, though the doctors
attempted to fix it, it would not remain attached, and there is no
chance of it getting fixed now. I would neither want nor care for
such a cure, however. I have lived my entire life blind, and while
the thought of gaining site back is appealing, I am unwilling to go
through the years and years of rewiring and reconditioning of my
brain that would be required for me to survive with site. To me, it
is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss how
the accessibility features would work and what would be
required. Even standardizing, through the specification, a key
combination to toggle the accessibility features would be nice, as
that would alleviate the major problem of a blind person buying a
new computer and not knowing how to enable the accessibility
features. The overarching goal would be to make the preboot
environment (including applications run within it) accessible and
usable by blind and visually impaired people as a boot service
only.
Yes, I agree, operating systems are already doing their things.

Again, mandating such a key combination is not necessarily something
that the UEFI specification can do. Some devices won't necessarily
have a keyboard.

Some things the UEFI specification could do is:
- Add protocols for Audio output (and possibly input) and talking to
audio codecs.
- Add audio hooks for the Human Interaction Interface subsystem (HII).

EDK2 could then start adding device drivers producing these protocols,
and enable the support for some reference platforms.

Would we need any specific support for things like refreshable braille
displays?

It would be superfluous to make this a runtime service, as all
major OSes already have accessibility features. Plus, managing such
a thing would be impossible to do.
Agreed.

This email has gotten quite long, so I will suspend the discussion
of functionality and how I would like it to work for a future email
once everyone has gotten on board.
Best Regards,

Leif


Thank you for your time and consideration.


--
Signed,
Ethin D. Probst


Re: UEFI accessibility mandate

Leif Lindholm
 

Hi Ethin,

Apologies for the delay in responding - I personally don't tend to
read the RFC list (and I know that applies to some other developers
who have now subscribed).

On Sun, Aug 11, 2019 at 06:15:18PM -0700, Ethin Probst wrote:
Hello all,

I'm new here, and was recommended to the TianoCore project by
someone over at the UEFI forum. I've run across TianoCore before,
and like the project.
Before anyone gets worried by the subject line, no, this is not any
kind of legal thing. Its just something I believe needs to
happen. :)
Back in 2016-2017 I contacted the UEFI forum about two problems, one
of which was the format of the spec, which I figured out on my
own. The other problem was not so easily dealt with. Te other
problem relates to accessibility of UEFI-compliant systems and
platform firmware to persons with disabilities. As it currently
stands, such a thing is nonexistent. To be fair, I completely
understand the difficulty that such a thing would require, and I
would fully agree if we still used the PC-AT BIOS systems -- yes,
indeed, I would never suggest this kind of thing on such a system
given that there was no actual standard of any kind for
BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have
access to their computers in the general sense (I am blind
myself). We can do pretty much anything anyone else could do. We can
code, play games, all that. There are few things that we cannot
do. One of those things is managing our systems firmware in the
preboot environment.
As it stands now, I can only boot other OSes or disks via
memorization. While that worked on BIOS machines (I have, or had, an
old Toshiba laptop that was BIOS-based), it no longer works because
UEFI is mercurial. When I access the boot menu now, I play a game of
chance. If the cards are in my favor, the OS I want to boot boots,
and I can go on my way. But if the cards aren't in my favor, I end
up making something happen that was unintended, and, worst of all, I
have no idea what I did.
However, the boot menu is only one portion of a platform firmware
UI. What about the setup utility or other utilities offered by
computer manufacturers? What about diagnostic utilities,
bootloaders, etc? What do I do with those? Well, I only have one
option -- sited assistance. If I go into my computers setup utility,
I cannot trust myself and say to myself, "OK, I know what I'm
doing. All I need to do is change x and save and quit." No, I can't
do that, because memorizing such a complex interface is extremely
difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd like
comments and feedback before it actually gets implemented (it will
take a lot of time, I'm sure): mandate, in the UEFI specification,
that accessibility features for persons with disabilities must be
implemented and documented, and, if such features are not
implemented, then that vendor is not compliant with the
specification. Place strict minimum requirements for what the
accessibility features should do and how they should work.
So, first of all, I need to point out that what you suggest would be
very difficult for the UEFI Forum to mandate. *But* I don't think this
needs to be a problem.

UEFI primarily exists as a means through which interoperability can be
guaranteed. This means it does not tend to so much mandate what is
actually implemented in a platform, as it defines how it behaves if it
is. This is not 100% true, but suffice to say that mandating the
functionality you are asking for *without* having a reference
implementation available would likely simply be ignored.

If you want to turn thumbscrews, get Microsoft to add the requirement
to their windows logo requirements :)

However, as much as it is difficult to force people to develop this
support, if a functional reference implementation was published under
a permissive open source license, it would take a pretty spectacularly
incompetent product owner not to incorporate it in their products.

Now, I'm sure someone out there will ask me how this can be
done. Well, that's why I've joined the group -- though as I
familiarize myself with EDK2 development and all that I may actually
be able to participate as more than just an accessibility expert, of
sorts.
I have added Rafael Machado on cc. He did a PhD on firmware
accessibility, including a prototype implementing an audio driver for
EDK2. The resulting thesis can be found at
https://arxiv.org/abs/1712.03186 .

As a side note, I have been blind all my life. I was born with
retinopathy of prematurity (ROP), which resulted because I was born
at 26 weeks. My retina was detached, and, though the doctors
attempted to fix it, it would not remain attached, and there is no
chance of it getting fixed now. I would neither want nor care for
such a cure, however. I have lived my entire life blind, and while
the thought of gaining site back is appealing, I am unwilling to go
through the years and years of rewiring and reconditioning of my
brain that would be required for me to survive with site. To me, it
is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss how
the accessibility features would work and what would be
required. Even standardizing, through the specification, a key
combination to toggle the accessibility features would be nice, as
that would alleviate the major problem of a blind person buying a
new computer and not knowing how to enable the accessibility
features. The overarching goal would be to make the preboot
environment (including applications run within it) accessible and
usable by blind and visually impaired people as a boot service
only.
Yes, I agree, operating systems are already doing their things.

Again, mandating such a key combination is not necessarily something
that the UEFI specification can do. Some devices won't necessarily
have a keyboard.

Some things the UEFI specification could do is:
- Add protocols for Audio output (and possibly input) and talking to
audio codecs.
- Add audio hooks for the Human Interaction Interface subsystem (HII).

EDK2 could then start adding device drivers producing these protocols,
and enable the support for some reference platforms.

Would we need any specific support for things like refreshable braille
displays?

It would be superfluous to make this a runtime service, as all
major OSes already have accessibility features. Plus, managing such
a thing would be impossible to do.
Agreed.

This email has gotten quite long, so I will suspend the discussion
of functionality and how I would like it to work for a future email
once everyone has gotten on board.
Best Regards,

Leif


Thank you for your time and consideration.



Re: [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

Igor Mammedov <imammedo@...>
 

On Mon, 9 Sep 2019 21:15:44 +0200
Laszlo Ersek <lersek@...> wrote:

Hi Igor,

On 09/05/19 17:49, Igor Mammedov wrote:
lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.

Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x30000,128K RAM range into SMRAM address
space and mask this region from normal RAM address space
(reads return 0xff and writes are ignored, i.e. guest code
should be able to deal with not usable 0x30000,128K RAM range
once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).

To make negotiated change effective, guest should read
"etc/smi/features-ok" fw_cfg file, which activates negotiated
features and locks down negotiating capabilities until hard reset.

Flow for initializing SMI handler on guest side:
1. set SMI handler entry point at default SMBASE location
2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
in "etc/smi/supported-features" and set if supported set
it in "etc/smi/requested-features"
3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.
Tying the [0x30000+128K) lockdown to the broadcast SMI negotiation is a
simplification for QEMU, but it is a complication for OVMF.

(This QEMU patch ties those things together in effect because
"etc/smi/features-ok" can be selected for lockdown only once.)

In OVMF, at least 6 modules are involved in SMM setup. Here I'm only
going to list some steps for 4 modules (skipping
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf" and
"UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf").


(1) The "OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf" driver is launched,
and it produces the EFI_SMM_CONTROL2_PROTOCOL.

EFI_SMM_CONTROL2_PROTOCOL.Trigger() is the standard / abstract method
for synchronously raising an SMI. The OVMF implementation writes to IO
port 0xB2.

Because OVMF exposes this protocol to the rest of the firmware, it first
negotiates SMI broadcast, if QEMU offers it. The idea is that, without
negotiating SMI broadcast (if it's available), EFI_SMM_CONTROL2_PROTOCOL
is not fully configured, and should not be exposed. (Because, Trigger()
wouldn't work properly). Incomplete / halfway functional protocols are
not to be published.

That is, we have

(1a) negotiate SMI broadcast
(1b) install EFI_SMM_CONTROL2_PROTOCOL.


(2) Dependent on EFI_SMM_CONTROL2_PROTOCOL, the SMM IPL (Initial Program
Load -- "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf") is launched.

This module
(2a) registers a callback for EFI_SMM_CONFIGURATION_PROTOCOL,
(2b) loads the SMM Core ("MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf")
into SMRAM and starts it.


(3) The SMM Core launches the SMM processor driver
("UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf").

The SMM processor driver
(3a) performs the initial SMBASE relocation,
(3b) and then installs EFI_SMM_CONFIGURATION_PROTOCOL.

(Side remark: the SMM processor driver does not use IO port 0xB2 (it
does not call Trigger()); it uses LAPIC accesses. This is by design (PI
spec); Trigger() is supposed to be called after the relocation is done,
and not for starting the relocation.)


(4) The SMM IPL's callback fires. It uses EFI_SMM_CONFIGURATION_PROTOCOL
to connect the platform-independent SMM entry point (= central
high-level SMI handler), which is in the SMM Core, into the low-level
(CPU-specific) SMI handler in the SMM processor driver.

At this point, SMIs are considered fully functional. General drivers
that are split into privileged (SMM) and unprivileged (runtime DXE)
halves, such as the variable service driver, can use
EFI_SMM_COMMUNICATION_PROTOCOL to submit messages to the privileged
(SMM) halves. And that boils down to EFI_SMM_CONTROL2_PROTOCOL.Trigger()
calls, which depends on SMI broadcast.

--*--

The present QEMU patch requires the firmware to (i) negotiate SMI
broadcast and to (ii) lock down [0x30000+128K) at the same time.

If OVMF does both in step (1a) -- i.e. where it currently negotiates the
broadcast --, then step (3a) breaks: because the initial SMBASE
relocation depends on RAM at [0x30000+128K).

In a theoretical ordering perspective, we could perhaps move the logic
from step (1a) between steps (3a) and (3b). There are two problems with
that:

- The platform logic from step (1a) doesn't belong in the SMM processor
driver (even if we managed to hook it in).

- In step (1b), we'd be installing a protocol
(EFI_SMM_CONTROL2_PROTOCOL) that is simply not set up correctly -- it's
incomplete.


Can QEMU offer this new "[0x30000+128K) lockdown" hardware feature in a
separate platform device? (Such as a PCI device with fixed
(QEMU-specified) B/D/F, and config space register(s).)
It looks like fwcfg smi feature negotiation isn't reusable in this case.
I'd prefer not to add another device just for another SMI feature
negotiation/activation.
How about stealing reserved register from pci-host similar to your
extended TSEG commit (2f295167 q35/mch: implement extended TSEG sizes)?
(Looking into spec can (ab)use 0x58 or 0x59 register)

It would be less difficult to lock such hardware down in isolation: I
wouldn't even attempt to inject that action between steps (3a) and (3b),
but write it as a new, independent End-of-DXE handler, in
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf". (That driver already offers SMRAM
open/close/lock services.) I would also reserve the memory away at that
time -- I don't expect the firmware to keep anything that low.
(Allocations are generally served top-down.)

--*--

... I've done some testing too. Applying the QEMU patch on top of
89ea03a7dc83, my plan was:

- do not change OVMF, just see if it continues booting with the QEMU
patch

- then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
to break.

Unfortunately, the result is worse than that; even without negotiating
bit#1 (i.e. in the baseline test), the firmware crashes (reboots) in
step (3a). I've checked "info mtree", and all occurences of
"smbase-blackhole" and "smbase-blackhole" are marked [disabled]. I'm not
sure what's wrong with the baseline test (i.e. without negotiating
bit#1). If I drop the patch (build QEMU at 89ea03a7dc83), then things
work fine.
that was a bug in my code, which always made lock down effective on
feature_ok selection, which breaks relocation for reasons you've
explained above.

diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17a8cd1b51..32ddf54fc2 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -383,7 +383,7 @@ static const MemoryRegionOps smbase_blackhole_ops = {

static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
{
- bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+ bool en = lpc->smi_negotiated_features & (UINT64_C(1) << ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT);

memory_region_transaction_begin();
memory_region_set_enabled(&lpc->smbase_blackhole, en);



Thank you!
Laszlo


Signed-off-by: Igor Mammedov <imammedo@...>
---
include/hw/i386/ich9.h | 11 ++++++--
hw/i386/pc.c | 4 ++-
hw/i386/pc_q35.c | 3 ++-
hw/isa/lpc_ich9.c | 58 +++++++++++++++++++++++++++++++++++++++++-
4 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 72e803f6e2..c28685b753 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -12,11 +12,14 @@
#include "hw/acpi/acpi.h"
#include "hw/acpi/ich9.h"
#include "hw/pci/pci_bus.h"
+#include "qemu/units.h"

void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram);
I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);

void ich9_generate_smi(void);
@@ -71,6 +74,8 @@ typedef struct ICH9LPCState {
uint8_t smi_features_ok; /* guest-visible, read-only; selecting it
* triggers feature lockdown */
uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+ MemoryRegion smbase_blackhole;
+ MemoryRegion smbase_window;

/* isa bus */
ISABus *isa_bus;
@@ -248,5 +253,7 @@ typedef struct ICH9LPCState {

/* bit positions used in fw_cfg SMI feature negotiation */
#define ICH9_LPC_SMI_F_BROADCAST_BIT 0
-
+#define ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT 1
+#define ICH9_LPC_SMBASE_ADDR 0x30000
+#define ICH9_LPC_SMBASE_RAM_SIZE (128 * KiB)
#endif /* HW_ICH9_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c14ed86439..99a98303eb 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
/* Physical Address of PVH entry point read from kernel ELF NOTE */
static size_t pvh_start_addr;

-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+ { "ICH9-LPC", "x-smi-locked-smbase", "off" },
+};
const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);

GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4e8a1cb9f..50462686a0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,7 +292,8 @@ static void pc_q35_init(MachineState *machine)
0xff0104);

/* connect pm stuff to lpc */
- ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), get_system_memory(),
+ ram_memory, MEMORY_REGION(object_resolve_path("/machine/smram", NULL)));

if (pcms->sata_enabled) {
/* ahci and SATA device, for q35 1 ahci controller is built-in */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17c292e306..17a8cd1b51 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -359,6 +359,38 @@ static void ich9_set_sci(void *opaque, int irq_num, int level)
}
}

+static uint64_t smbase_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+ return 0xffffffff;
+}
+
+static void smbase_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+ /* nothing */
+}
+
+static const MemoryRegionOps smbase_blackhole_ops = {
+ .read = smbase_blackhole_read,
+ .write = smbase_blackhole_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid.min_access_size = 1,
+ .valid.max_access_size = 4,
+ .impl.min_access_size = 4,
+ .impl.max_access_size = 4,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
+{
+ bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+
+ memory_region_transaction_begin();
+ memory_region_set_enabled(&lpc->smbase_blackhole, en);
+ memory_region_set_enabled(&lpc->smbase_window, en);
+ memory_region_transaction_commit();
+}
+
static void smi_features_ok_callback(void *opaque)
{
ICH9LPCState *lpc = opaque;
@@ -379,9 +411,13 @@ static void smi_features_ok_callback(void *opaque)
/* valid feature subset requested, lock it down, report success */
lpc->smi_negotiated_features = guest_features;
lpc->smi_features_ok = 1;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

-void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
+void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram)
{
ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pci);
qemu_irq sci_irq;
@@ -413,6 +449,20 @@ void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
&lpc->smi_features_ok,
sizeof lpc->smi_features_ok,
true);
+
+ memory_region_init_io(&lpc->smbase_blackhole, OBJECT(lpc),
+ &smbase_blackhole_ops, NULL,
+ "smbase-blackhole", ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_blackhole, false);
+ memory_region_add_subregion_overlap(system_memory, ICH9_LPC_SMBASE_ADDR,
+ &lpc->smbase_blackhole, 1);
+
+
+ memory_region_init_alias(&lpc->smbase_window, OBJECT(lpc),
+ "smbase-window", ram,
+ ICH9_LPC_SMBASE_ADDR, ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_window, false);
+ memory_region_add_subregion(smram, 0x30000, &lpc->smbase_window);
}

ich9_lpc_reset(DEVICE(lpc));
@@ -508,6 +558,7 @@ static int ich9_lpc_post_load(void *opaque, int version_id)
ich9_lpc_pmbase_sci_update(lpc);
ich9_lpc_rcba_update(lpc, 0 /* disabled ICH9_LPC_RCBA_EN */);
ich9_lpc_pmcon_update(lpc);
+ ich9_lpc_smbase_locked_update(lpc);
return 0;
}

@@ -567,6 +618,8 @@ static void ich9_lpc_reset(DeviceState *qdev)
memset(lpc->smi_guest_features_le, 0, sizeof lpc->smi_guest_features_le);
lpc->smi_features_ok = 0;
lpc->smi_negotiated_features = 0;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

/* root complex register block is mapped into memory space */
@@ -697,6 +750,7 @@ static void ich9_lpc_realize(PCIDevice *d, Error **errp)
qdev_init_gpio_out_named(dev, lpc->gsi, ICH9_GPIO_GSI, GSI_NUM_PINS);

isa_bus_irqs(isa_bus, lpc->gsi);
+
}

static bool ich9_rst_cnt_needed(void *opaque)
@@ -764,6 +818,8 @@ static Property ich9_lpc_properties[] = {
DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
ICH9_LPC_SMI_F_BROADCAST_BIT, true),
+ DEFINE_PROP_BIT64("x-smi-locked-smbase", ICH9LPCState, smi_host_features,
+ ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT, true),
DEFINE_PROP_END_OF_LIST(),
};


Re: [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

Laszlo Ersek
 

On 09/09/19 21:15, Laszlo Ersek wrote:

... I've done some testing too. Applying the QEMU patch on top of
89ea03a7dc83, my plan was:

- do not change OVMF, just see if it continues booting with the QEMU
patch

- then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
to break.

Unfortunately, the result is worse than that; even without negotiating
bit#1 (i.e. in the baseline test), the firmware crashes (reboots) in
step (3a). I've checked "info mtree", and all occurences of
"smbase-blackhole" and "smbase-blackhole" are marked [disabled]. I'm not
sure what's wrong with the baseline test (i.e. without negotiating
bit#1). If I drop the patch (build QEMU at 89ea03a7dc83), then things
work fine.
Sorry, there's a typo above: I pasted "smbase-blackhole" twice. The
second instance was meant to be "smbase-window". I checked all instances
of both regions in the info mtree output, I just fumbled the pasting.

Thanks
Laszlo


Re: [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

Laszlo Ersek
 

Hi Igor,

On 09/05/19 17:49, Igor Mammedov wrote:
lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.

Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x30000,128K RAM range into SMRAM address
space and mask this region from normal RAM address space
(reads return 0xff and writes are ignored, i.e. guest code
should be able to deal with not usable 0x30000,128K RAM range
once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).

To make negotiated change effective, guest should read
"etc/smi/features-ok" fw_cfg file, which activates negotiated
features and locks down negotiating capabilities until hard reset.

Flow for initializing SMI handler on guest side:
1. set SMI handler entry point at default SMBASE location
2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
in "etc/smi/supported-features" and set if supported set
it in "etc/smi/requested-features"
3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.
Tying the [0x30000+128K) lockdown to the broadcast SMI negotiation is a
simplification for QEMU, but it is a complication for OVMF.

(This QEMU patch ties those things together in effect because
"etc/smi/features-ok" can be selected for lockdown only once.)

In OVMF, at least 6 modules are involved in SMM setup. Here I'm only
going to list some steps for 4 modules (skipping
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf" and
"UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf").


(1) The "OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf" driver is launched,
and it produces the EFI_SMM_CONTROL2_PROTOCOL.

EFI_SMM_CONTROL2_PROTOCOL.Trigger() is the standard / abstract method
for synchronously raising an SMI. The OVMF implementation writes to IO
port 0xB2.

Because OVMF exposes this protocol to the rest of the firmware, it first
negotiates SMI broadcast, if QEMU offers it. The idea is that, without
negotiating SMI broadcast (if it's available), EFI_SMM_CONTROL2_PROTOCOL
is not fully configured, and should not be exposed. (Because, Trigger()
wouldn't work properly). Incomplete / halfway functional protocols are
not to be published.

That is, we have

(1a) negotiate SMI broadcast
(1b) install EFI_SMM_CONTROL2_PROTOCOL.


(2) Dependent on EFI_SMM_CONTROL2_PROTOCOL, the SMM IPL (Initial Program
Load -- "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf") is launched.

This module
(2a) registers a callback for EFI_SMM_CONFIGURATION_PROTOCOL,
(2b) loads the SMM Core ("MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf")
into SMRAM and starts it.


(3) The SMM Core launches the SMM processor driver
("UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf").

The SMM processor driver
(3a) performs the initial SMBASE relocation,
(3b) and then installs EFI_SMM_CONFIGURATION_PROTOCOL.

(Side remark: the SMM processor driver does not use IO port 0xB2 (it
does not call Trigger()); it uses LAPIC accesses. This is by design (PI
spec); Trigger() is supposed to be called after the relocation is done,
and not for starting the relocation.)


(4) The SMM IPL's callback fires. It uses EFI_SMM_CONFIGURATION_PROTOCOL
to connect the platform-independent SMM entry point (= central
high-level SMI handler), which is in the SMM Core, into the low-level
(CPU-specific) SMI handler in the SMM processor driver.

At this point, SMIs are considered fully functional. General drivers
that are split into privileged (SMM) and unprivileged (runtime DXE)
halves, such as the variable service driver, can use
EFI_SMM_COMMUNICATION_PROTOCOL to submit messages to the privileged
(SMM) halves. And that boils down to EFI_SMM_CONTROL2_PROTOCOL.Trigger()
calls, which depends on SMI broadcast.

--*--

The present QEMU patch requires the firmware to (i) negotiate SMI
broadcast and to (ii) lock down [0x30000+128K) at the same time.

If OVMF does both in step (1a) -- i.e. where it currently negotiates the
broadcast --, then step (3a) breaks: because the initial SMBASE
relocation depends on RAM at [0x30000+128K).

In a theoretical ordering perspective, we could perhaps move the logic
from step (1a) between steps (3a) and (3b). There are two problems with
that:

- The platform logic from step (1a) doesn't belong in the SMM processor
driver (even if we managed to hook it in).

- In step (1b), we'd be installing a protocol
(EFI_SMM_CONTROL2_PROTOCOL) that is simply not set up correctly -- it's
incomplete.


Can QEMU offer this new "[0x30000+128K) lockdown" hardware feature in a
separate platform device? (Such as a PCI device with fixed
(QEMU-specified) B/D/F, and config space register(s).)

It would be less difficult to lock such hardware down in isolation: I
wouldn't even attempt to inject that action between steps (3a) and (3b),
but write it as a new, independent End-of-DXE handler, in
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf". (That driver already offers SMRAM
open/close/lock services.) I would also reserve the memory away at that
time -- I don't expect the firmware to keep anything that low.
(Allocations are generally served top-down.)

--*--

... I've done some testing too. Applying the QEMU patch on top of
89ea03a7dc83, my plan was:

- do not change OVMF, just see if it continues booting with the QEMU
patch

- then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
to break.

Unfortunately, the result is worse than that; even without negotiating
bit#1 (i.e. in the baseline test), the firmware crashes (reboots) in
step (3a). I've checked "info mtree", and all occurences of
"smbase-blackhole" and "smbase-blackhole" are marked [disabled]. I'm not
sure what's wrong with the baseline test (i.e. without negotiating
bit#1). If I drop the patch (build QEMU at 89ea03a7dc83), then things
work fine.

Thank you!
Laszlo


Signed-off-by: Igor Mammedov <imammedo@...>
---
include/hw/i386/ich9.h | 11 ++++++--
hw/i386/pc.c | 4 ++-
hw/i386/pc_q35.c | 3 ++-
hw/isa/lpc_ich9.c | 58 +++++++++++++++++++++++++++++++++++++++++-
4 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 72e803f6e2..c28685b753 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -12,11 +12,14 @@
#include "hw/acpi/acpi.h"
#include "hw/acpi/ich9.h"
#include "hw/pci/pci_bus.h"
+#include "qemu/units.h"

void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram);
I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);

void ich9_generate_smi(void);
@@ -71,6 +74,8 @@ typedef struct ICH9LPCState {
uint8_t smi_features_ok; /* guest-visible, read-only; selecting it
* triggers feature lockdown */
uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+ MemoryRegion smbase_blackhole;
+ MemoryRegion smbase_window;

/* isa bus */
ISABus *isa_bus;
@@ -248,5 +253,7 @@ typedef struct ICH9LPCState {

/* bit positions used in fw_cfg SMI feature negotiation */
#define ICH9_LPC_SMI_F_BROADCAST_BIT 0
-
+#define ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT 1
+#define ICH9_LPC_SMBASE_ADDR 0x30000
+#define ICH9_LPC_SMBASE_RAM_SIZE (128 * KiB)
#endif /* HW_ICH9_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c14ed86439..99a98303eb 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
/* Physical Address of PVH entry point read from kernel ELF NOTE */
static size_t pvh_start_addr;

-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+ { "ICH9-LPC", "x-smi-locked-smbase", "off" },
+};
const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);

GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4e8a1cb9f..50462686a0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,7 +292,8 @@ static void pc_q35_init(MachineState *machine)
0xff0104);

/* connect pm stuff to lpc */
- ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), get_system_memory(),
+ ram_memory, MEMORY_REGION(object_resolve_path("/machine/smram", NULL)));

if (pcms->sata_enabled) {
/* ahci and SATA device, for q35 1 ahci controller is built-in */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17c292e306..17a8cd1b51 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -359,6 +359,38 @@ static void ich9_set_sci(void *opaque, int irq_num, int level)
}
}

+static uint64_t smbase_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+ return 0xffffffff;
+}
+
+static void smbase_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+ /* nothing */
+}
+
+static const MemoryRegionOps smbase_blackhole_ops = {
+ .read = smbase_blackhole_read,
+ .write = smbase_blackhole_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid.min_access_size = 1,
+ .valid.max_access_size = 4,
+ .impl.min_access_size = 4,
+ .impl.max_access_size = 4,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
+{
+ bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+
+ memory_region_transaction_begin();
+ memory_region_set_enabled(&lpc->smbase_blackhole, en);
+ memory_region_set_enabled(&lpc->smbase_window, en);
+ memory_region_transaction_commit();
+}
+
static void smi_features_ok_callback(void *opaque)
{
ICH9LPCState *lpc = opaque;
@@ -379,9 +411,13 @@ static void smi_features_ok_callback(void *opaque)
/* valid feature subset requested, lock it down, report success */
lpc->smi_negotiated_features = guest_features;
lpc->smi_features_ok = 1;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

-void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
+void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram)
{
ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pci);
qemu_irq sci_irq;
@@ -413,6 +449,20 @@ void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
&lpc->smi_features_ok,
sizeof lpc->smi_features_ok,
true);
+
+ memory_region_init_io(&lpc->smbase_blackhole, OBJECT(lpc),
+ &smbase_blackhole_ops, NULL,
+ "smbase-blackhole", ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_blackhole, false);
+ memory_region_add_subregion_overlap(system_memory, ICH9_LPC_SMBASE_ADDR,
+ &lpc->smbase_blackhole, 1);
+
+
+ memory_region_init_alias(&lpc->smbase_window, OBJECT(lpc),
+ "smbase-window", ram,
+ ICH9_LPC_SMBASE_ADDR, ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_window, false);
+ memory_region_add_subregion(smram, 0x30000, &lpc->smbase_window);
}

ich9_lpc_reset(DEVICE(lpc));
@@ -508,6 +558,7 @@ static int ich9_lpc_post_load(void *opaque, int version_id)
ich9_lpc_pmbase_sci_update(lpc);
ich9_lpc_rcba_update(lpc, 0 /* disabled ICH9_LPC_RCBA_EN */);
ich9_lpc_pmcon_update(lpc);
+ ich9_lpc_smbase_locked_update(lpc);
return 0;
}

@@ -567,6 +618,8 @@ static void ich9_lpc_reset(DeviceState *qdev)
memset(lpc->smi_guest_features_le, 0, sizeof lpc->smi_guest_features_le);
lpc->smi_features_ok = 0;
lpc->smi_negotiated_features = 0;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

/* root complex register block is mapped into memory space */
@@ -697,6 +750,7 @@ static void ich9_lpc_realize(PCIDevice *d, Error **errp)
qdev_init_gpio_out_named(dev, lpc->gsi, ICH9_GPIO_GSI, GSI_NUM_PINS);

isa_bus_irqs(isa_bus, lpc->gsi);
+
}

static bool ich9_rst_cnt_needed(void *opaque)
@@ -764,6 +818,8 @@ static Property ich9_lpc_properties[] = {
DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
ICH9_LPC_SMI_F_BROADCAST_BIT, true),
+ DEFINE_PROP_BIT64("x-smi-locked-smbase", ICH9LPCState, smi_host_features,
+ ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT, true),
DEFINE_PROP_END_OF_LIST(),
};


Re: UEFI terminal console keyboard type extend for Putty

Gao, Zhichao
 

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Gao,
Zhichao
Sent: Monday, September 9, 2019 8:28 AM
To: Ni, Ray <ray.ni@...>; rfc@edk2.groups.io; Gao, Liming
<liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend for Putty



-----Original Message-----
From: Ni, Ray
Sent: Saturday, September 7, 2019 4:35 AM
To: rfc@edk2.groups.io; Ni, Ray <ray.ni@...>; Gao, Zhichao
<zhichao.gao@...>; Gao, Liming <liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend for
Putty

Another specific question: What's the meaning of "F1 and F2 don't work
in UEFI Shell"? That sounds like a bug in Terminal driver.
My mistake, the key worked fine in uefi shell. The default type is VT100, and
the ESC+O+P and ESC+O+Q sequence key is seem as F1 and F2.
Same with the SCO map. So I would add four type, they are XtermR6, Vt400, Linux and SCO.

+=========+======+===========+=============+=============+=============+=========+
| | EFI | | | | | |
| | Scan | | | Normal | | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux | SCO |
+=========+======+===========+=============+=============+=============+=========+
| F1 | 0x0B | ESC O P | ESC O P | ESC [ 1 1 ~ | ESC [ [ A | ESC [ M |
| F2 | 0x0C | ESC O Q | ESC O Q | ESC [ 1 2 ~ | ESC [ [ B | ESC [ N |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C | ESC [ O |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 4 ~ | ESC [ [ D | ESC [ P |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E | ESC [ Q |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ R |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ S |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ T |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ U |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ V |
| Escape | 0x17 | ESC | ESC | ESC | ESC | ESC
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ W |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ X |
+=========+======+===========+=============+=============+=============+=========+
Thanks,
Zhichao



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Ni, Ray
Sent: Friday, September 6, 2019 12:57 PM
To: rfc@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>; Gao,
Liming <liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend
for Putty

Zhichao,
Can you please summarize what terminal types are supported by EDKII
Terminal driver today and what you are going to add through this RFC?
For now it supported 5 types VT100, VT100+, PS ANSI, UTF8 and TTY Term. I
am going to add the support of VT400, Linux and Xterm R6.
By the way the VT100+'s mapping is different with the spec, I would also
extend its mapping.


For the newly added terminal types, where is the mapping defined in
public space?
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-
funkeys
Here define the mapping, but it is only for function key. And I would only add
the support of function key.

Thanks,
Zhichao


Thanks,
Ray


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Gao,
Zhichao
Sent: Friday, September 6, 2019 12:56 AM
To: Gao, Liming <liming.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend
for Putty

Liming,
All the three types will be introduced.

By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'.
Thanks,
Zhichao

From: Gao, Liming
Sent: Friday, September 6, 2019 3:51 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend
for Putty

Zhichao:
One clarification. What terminal type will be introduced? Xterm,
VT400
and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming
<liming.gao@...<mailto:liming.gao@...>>; Xu, Shiwei
<shiwei.xu@...<mailto:shiwei.xu@...>>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for
Putty

Hi everyone,

Putty is a popular terminal console software in windows and it
support various types of terminal keyboard type. I would like to
add most of the type support. Here is the key map info. Hope to
get comments. Here is the type and mapping
table:
Putty function key map:
+=========+======+===========+=============+=============+
=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+
=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |

+=========+======+===========+=============+=============+
==========
===+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q,
but it doesn't work on UEFI shell. Same with the SCO mode. So I
would ignore
the unworkable key map.
Info refer to
https://www.ssh.com/ssh/putty/putty-
manuals/0.68/Chapter4.html#confi
g-funkeys

Thanks,
Zhichao





Re: UEFI terminal console keyboard type extend for Putty

Gao, Zhichao
 

-----Original Message-----
From: Ni, Ray
Sent: Saturday, September 7, 2019 4:35 AM
To: rfc@edk2.groups.io; Ni, Ray <ray.ni@...>; Gao, Zhichao
<zhichao.gao@...>; Gao, Liming <liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Another specific question: What's the meaning of "F1 and F2 don't work in
UEFI Shell"? That sounds like a bug in Terminal driver.
My mistake, the key worked fine in uefi shell. The default type is VT100, and the ESC+O+P and ESC+O+Q sequence key is seem as F1 and F2.


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Ni, Ray
Sent: Friday, September 6, 2019 12:57 PM
To: rfc@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>; Gao,
Liming <liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend for
Putty

Zhichao,
Can you please summarize what terminal types are supported by EDKII
Terminal driver today and what you are going to add through this RFC?
For now it supported 5 types VT100, VT100+, PS ANSI, UTF8 and TTY Term. I am going to add the support of VT400, Linux and Xterm R6.
By the way the VT100+'s mapping is different with the spec, I would also extend its mapping.


For the newly added terminal types, where is the mapping defined in
public space?
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys
Here define the mapping, but it is only for function key. And I would only add the support of function key.

Thanks,
Zhichao


Thanks,
Ray


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Gao,
Zhichao
Sent: Friday, September 6, 2019 12:56 AM
To: Gao, Liming <liming.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend
for Putty

Liming,
All the three types will be introduced.

By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'.
Thanks,
Zhichao

From: Gao, Liming
Sent: Friday, September 6, 2019 3:51 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend
for Putty

Zhichao:
One clarification. What terminal type will be introduced? Xterm, VT400
and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming
<liming.gao@...<mailto:liming.gao@...>>; Xu, Shiwei
<shiwei.xu@...<mailto:shiwei.xu@...>>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for
Putty

Hi everyone,

Putty is a popular terminal console software in windows and it
support various types of terminal keyboard type. I would like to add
most of the type support. Here is the key map info. Hope to get
comments. Here is the type and mapping
table:
Putty function key map:
+=========+======+===========+=============+=============+
=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+
=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |

+=========+======+===========+=============+=============+
==========
===+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but
it doesn't work on UEFI shell. Same with the SCO mode. So I would ignore
the unworkable key map.
Info refer to
https://www.ssh.com/ssh/putty/putty-
manuals/0.68/Chapter4.html#confi
g-funkeys

Thanks,
Zhichao




Re: UEFI terminal console keyboard type extend for Putty

Ni, Ray
 

Another specific question: What's the meaning of "F1 and F2 don't work in UEFI Shell"? That sounds like a bug in Terminal driver.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Ni, Ray
Sent: Friday, September 6, 2019 12:57 PM
To: rfc@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>; Gao, Liming <liming.gao@...>
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Zhichao,
Can you please summarize what terminal types are supported by EDKII Terminal driver today and what you are going to
add through this RFC?

For the newly added terminal types, where is the mapping defined in public space?

Thanks,
Ray


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Gao, Zhichao
Sent: Friday, September 6, 2019 12:56 AM
To: Gao, Liming <liming.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Liming,
All the three types will be introduced.

By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'.
Thanks,
Zhichao

From: Gao, Liming
Sent: Friday, September 6, 2019 3:51 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Zhichao:
One clarification. What terminal type will be introduced? Xterm, VT400 and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming
<liming.gao@...<mailto:liming.gao@...>>; Xu, Shiwei <shiwei.xu@...<mailto:shiwei.xu@...>>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Hi everyone,

Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would
like to add most of the type support. Here is the key map info. Hope to get comments. Here is the type and mapping
table:
Putty function key map:
+=========+======+===========+=============+=============+=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
+=========+======+===========+=============+=============+=============+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't work on UEFI shell. Same with the SCO
mode. So I would ignore the unworkable key map.
Info refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao




Re: UEFI terminal console keyboard type extend for Putty

Ni, Ray
 

Zhichao,
Can you please summarize what terminal types are supported by EDKII Terminal driver today and what you are going to add through this RFC?

For the newly added terminal types, where is the mapping defined in public space?

Thanks,
Ray

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Gao, Zhichao
Sent: Friday, September 6, 2019 12:56 AM
To: Gao, Liming <liming.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: Re: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Liming,
All the three types will be introduced.

By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'.
Thanks,
Zhichao

From: Gao, Liming
Sent: Friday, September 6, 2019 3:51 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Zhichao:
One clarification. What terminal type will be introduced? Xterm, VT400 and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming
<liming.gao@...<mailto:liming.gao@...>>; Xu, Shiwei <shiwei.xu@...<mailto:shiwei.xu@...>>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Hi everyone,

Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would
like to add most of the type support. Here is the key map info. Hope to get comments. Here is the type and mapping table:
Putty function key map:
+=========+======+===========+=============+=============+=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
+=========+======+===========+=============+=============+=============+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't work on UEFI shell. Same with the SCO
mode. So I would ignore the unworkable key map.
Info refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao



Re: UEFI terminal console keyboard type extend for Putty

Gao, Zhichao
 

Liming,
All the three types will be introduced.

By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'.
Thanks,
Zhichao

From: Gao, Liming
Sent: Friday, September 6, 2019 3:51 PM
To: Gao, Zhichao <zhichao.gao@...>; rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Xu, Shiwei <shiwei.xu@...>
Subject: RE: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Zhichao:
One clarification. What terminal type will be introduced? Xterm, VT400 and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Gao, Liming <liming.gao@...<mailto:liming.gao@...>>; Xu, Shiwei <shiwei.xu@...<mailto:shiwei.xu@...>>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Hi everyone,

Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would like to add most of the type support. Here is the key map info. Hope to get comments. Here is the type and mapping table:
Putty function key map:
+=========+======+===========+=============+=============+=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
+=========+======+===========+=============+=============+=============+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't work on UEFI shell. Same with the SCO mode. So I would ignore the unworkable key map.
Info refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao


Re: UEFI terminal console keyboard type extend for Putty

Liming Gao
 

Zhichao:
One clarification. What terminal type will be introduced? Xterm, VT400 and Linux?

Thanks
Liming
From: Gao, Zhichao
Sent: Friday, September 06, 2019 12:56 PM
To: rfc@edk2.groups.io
Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@...>; Xu, Shiwei <shiwei.xu@...>
Subject: [edk2-rfc] UEFI terminal console keyboard type extend for Putty

Hi everyone,

Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would like to add most of the type support. Here is the key map info. Hope to get comments. Here is the type and mapping table:
Putty function key map:
+=========+======+===========+=============+=============+=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
+=========+======+===========+=============+=============+=============+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't work on UEFI shell. Same with the SCO mode. So I would ignore the unworkable key map.
Info refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao


UEFI terminal console keyboard type extend for Putty

Gao, Zhichao
 

Hi everyone,

Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would like to add most of the type support. Here is the key map info. Hope to get comments. Here is the type and mapping table:
Putty function key map:
+=========+======+===========+=============+=============+=============+
| | EFI | | | | |
| | Scan | | | Normal | |
| KEY | Code | VT100+ | Xterm R6 | VT400 | Linux |
+=========+======+===========+=============+=============+=============+
| F1 | 0x0B | ESC O P | NONE | ESC [ 1 1 ~ | ESC [ [ A |
| F2 | 0x0C | ESC O Q | NONE | ESC [ 1 2 ~ | ESC [ [ B |
| F3 | 0x0D | ESC O R | ESC O R | ESC [ 1 3 ~ | ESC [ [ C |
| F4 | 0x0E | ESC O S | ESC O S | ESC [ 1 3 ~ | ESC [ [ D |
| F5 | 0x0F | ESC O T | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E |
| F6 | 0x10 | ESC O U | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
| F7 | 0x11 | ESC [ V | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
| F8 | 0x12 | ESC [ W | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
| F9 | 0x13 | ESC [ X | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
| F10 | 0x14 | ESC [ Y | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
| Escape | 0x17 | ESC | ESC | ESC | ESC |
| F11 | 0x15 | ESC O Z | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
| F12 | 0x16 | ESC O [ | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
+=========+======+===========+=============+=============+=============+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't work on UEFI shell. Same with the SCO mode. So I would ignore the unworkable key map.
Info refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao


[PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

Igor Mammedov <imammedo@...>
 

lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.

Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x30000,128K RAM range into SMRAM address
space and mask this region from normal RAM address space
(reads return 0xff and writes are ignored, i.e. guest code
should be able to deal with not usable 0x30000,128K RAM range
once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).

To make negotiated change effective, guest should read
"etc/smi/features-ok" fw_cfg file, which activates negotiated
features and locks down negotiating capabilities until hard reset.

Flow for initializing SMI handler on guest side:
1. set SMI handler entry point at default SMBASE location
2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
in "etc/smi/supported-features" and set if supported set
it in "etc/smi/requested-features"
3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.

Signed-off-by: Igor Mammedov <imammedo@...>
---
include/hw/i386/ich9.h | 11 ++++++--
hw/i386/pc.c | 4 ++-
hw/i386/pc_q35.c | 3 ++-
hw/isa/lpc_ich9.c | 58 +++++++++++++++++++++++++++++++++++++++++-
4 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 72e803f6e2..c28685b753 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -12,11 +12,14 @@
#include "hw/acpi/acpi.h"
#include "hw/acpi/ich9.h"
#include "hw/pci/pci_bus.h"
+#include "qemu/units.h"

void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram);
I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);

void ich9_generate_smi(void);
@@ -71,6 +74,8 @@ typedef struct ICH9LPCState {
uint8_t smi_features_ok; /* guest-visible, read-only; selecting it
* triggers feature lockdown */
uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+ MemoryRegion smbase_blackhole;
+ MemoryRegion smbase_window;

/* isa bus */
ISABus *isa_bus;
@@ -248,5 +253,7 @@ typedef struct ICH9LPCState {

/* bit positions used in fw_cfg SMI feature negotiation */
#define ICH9_LPC_SMI_F_BROADCAST_BIT 0
-
+#define ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT 1
+#define ICH9_LPC_SMBASE_ADDR 0x30000
+#define ICH9_LPC_SMBASE_RAM_SIZE (128 * KiB)
#endif /* HW_ICH9_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c14ed86439..99a98303eb 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
/* Physical Address of PVH entry point read from kernel ELF NOTE */
static size_t pvh_start_addr;

-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+ { "ICH9-LPC", "x-smi-locked-smbase", "off" },
+};
const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);

GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4e8a1cb9f..50462686a0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,7 +292,8 @@ static void pc_q35_init(MachineState *machine)
0xff0104);

/* connect pm stuff to lpc */
- ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), get_system_memory(),
+ ram_memory, MEMORY_REGION(object_resolve_path("/machine/smram", NULL)));

if (pcms->sata_enabled) {
/* ahci and SATA device, for q35 1 ahci controller is built-in */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17c292e306..17a8cd1b51 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -359,6 +359,38 @@ static void ich9_set_sci(void *opaque, int irq_num, int level)
}
}

+static uint64_t smbase_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+ return 0xffffffff;
+}
+
+static void smbase_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+ /* nothing */
+}
+
+static const MemoryRegionOps smbase_blackhole_ops = {
+ .read = smbase_blackhole_read,
+ .write = smbase_blackhole_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid.min_access_size = 1,
+ .valid.max_access_size = 4,
+ .impl.min_access_size = 4,
+ .impl.max_access_size = 4,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
+{
+ bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+
+ memory_region_transaction_begin();
+ memory_region_set_enabled(&lpc->smbase_blackhole, en);
+ memory_region_set_enabled(&lpc->smbase_window, en);
+ memory_region_transaction_commit();
+}
+
static void smi_features_ok_callback(void *opaque)
{
ICH9LPCState *lpc = opaque;
@@ -379,9 +411,13 @@ static void smi_features_ok_callback(void *opaque)
/* valid feature subset requested, lock it down, report success */
lpc->smi_negotiated_features = guest_features;
lpc->smi_features_ok = 1;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

-void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
+void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled,
+ MemoryRegion *system_memory, MemoryRegion *ram,
+ MemoryRegion *smram)
{
ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pci);
qemu_irq sci_irq;
@@ -413,6 +449,20 @@ void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
&lpc->smi_features_ok,
sizeof lpc->smi_features_ok,
true);
+
+ memory_region_init_io(&lpc->smbase_blackhole, OBJECT(lpc),
+ &smbase_blackhole_ops, NULL,
+ "smbase-blackhole", ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_blackhole, false);
+ memory_region_add_subregion_overlap(system_memory, ICH9_LPC_SMBASE_ADDR,
+ &lpc->smbase_blackhole, 1);
+
+
+ memory_region_init_alias(&lpc->smbase_window, OBJECT(lpc),
+ "smbase-window", ram,
+ ICH9_LPC_SMBASE_ADDR, ICH9_LPC_SMBASE_RAM_SIZE);
+ memory_region_set_enabled(&lpc->smbase_window, false);
+ memory_region_add_subregion(smram, 0x30000, &lpc->smbase_window);
}

ich9_lpc_reset(DEVICE(lpc));
@@ -508,6 +558,7 @@ static int ich9_lpc_post_load(void *opaque, int version_id)
ich9_lpc_pmbase_sci_update(lpc);
ich9_lpc_rcba_update(lpc, 0 /* disabled ICH9_LPC_RCBA_EN */);
ich9_lpc_pmcon_update(lpc);
+ ich9_lpc_smbase_locked_update(lpc);
return 0;
}

@@ -567,6 +618,8 @@ static void ich9_lpc_reset(DeviceState *qdev)
memset(lpc->smi_guest_features_le, 0, sizeof lpc->smi_guest_features_le);
lpc->smi_features_ok = 0;
lpc->smi_negotiated_features = 0;
+
+ ich9_lpc_smbase_locked_update(lpc);
}

/* root complex register block is mapped into memory space */
@@ -697,6 +750,7 @@ static void ich9_lpc_realize(PCIDevice *d, Error **errp)
qdev_init_gpio_out_named(dev, lpc->gsi, ICH9_GPIO_GSI, GSI_NUM_PINS);

isa_bus_irqs(isa_bus, lpc->gsi);
+
}

static bool ich9_rst_cnt_needed(void *opaque)
@@ -764,6 +818,8 @@ static Property ich9_lpc_properties[] = {
DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
ICH9_LPC_SMI_F_BROADCAST_BIT, true),
+ DEFINE_PROP_BIT64("x-smi-locked-smbase", ICH9LPCState, smi_host_features,
+ ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT, true),
DEFINE_PROP_END_OF_LIST(),
};

--
2.18.1


Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Igor Mammedov <imammedo@...>
 

On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek <lersek@...> wrote:

On 09/04/19 11:52, Igor Mammedov wrote:

it could be stolen RAM + black hole like TSEG, assuming fw can live without RAM(0x30000+128K) range
(in this case fwcfg interface would only work for locking down the range)

or

we can actually have a dedicated SMRAM (like in my earlier RFC),
in this case FW can use RAM(0x30000+128K) when SMRAM isn't mapped into RAM address space
(in this case fwcfg would be used to temporarily map SMRAM into normal RAM and unmap/lock
after SMI relocation handler was initialized).

If possible I'd prefer a simpler TSEG like variant.
I think TSEG-like behavior is between these two. That is, I believe we
should have explicit open/close/lock operations. And, when the range is
closed (meaning, closed+unlocked, or closed+locked), then the black hole
should take effect for code that's not running in SMM.

Put differently, its like the second choice, except the range never
appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
then the address range shows "nothing" (black hole).
I guess we at point where patch is better then words, I'll send one as reply here shortly.
I've just implemented subset of above (opened, closed+locked).


Regarding "fw can live without RAM(0x30000+128K) range" -- do you mean
whether the firmware could use another RAM area for fw_cfg DMA?

If that's the question, then I wouldn't worry about it. I'd remove the
0x30000+128K range from the memory map, so the fw_cfg stuff (or anything
else) would never allocate memory from the range. It's much more
concerning to me however how the SMM infrastructure would deal with a
hole in the memory map right there.
I didn't mean fwcfg in this context, what I meant if firmware were able
to avoid using RAM(0x30000+128K) range (since it becomes unusable after locking).
Looks like you just answered it here


Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Laszlo Ersek
 

On 09/04/19 11:52, Igor Mammedov wrote:

it could be stolen RAM + black hole like TSEG, assuming fw can live without RAM(0x30000+128K) range
(in this case fwcfg interface would only work for locking down the range)

or

we can actually have a dedicated SMRAM (like in my earlier RFC),
in this case FW can use RAM(0x30000+128K) when SMRAM isn't mapped into RAM address space
(in this case fwcfg would be used to temporarily map SMRAM into normal RAM and unmap/lock
after SMI relocation handler was initialized).

If possible I'd prefer a simpler TSEG like variant.
I think TSEG-like behavior is between these two. That is, I believe we
should have explicit open/close/lock operations. And, when the range is
closed (meaning, closed+unlocked, or closed+locked), then the black hole
should take effect for code that's not running in SMM.

Put differently, its like the second choice, except the range never
appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
then the address range shows "nothing" (black hole).


Regarding "fw can live without RAM(0x30000+128K) range" -- do you mean
whether the firmware could use another RAM area for fw_cfg DMA?

If that's the question, then I wouldn't worry about it. I'd remove the
0x30000+128K range from the memory map, so the fw_cfg stuff (or anything
else) would never allocate memory from the range. It's much more
concerning to me however how the SMM infrastructure would deal with a
hole in the memory map right there.

Thanks
Laszlo


Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1

rebecca@...
 

On 2019-09-03 10:41, Ni, Ray wrote:
Can we change the process a bit?
1. maintainers created pull requests on behave of the patch owners
2. patch owners can be notified automatically if pull requests fail
3. patch owners update the pull requests
(I am not familiar to pull requests. I assume the rights of modifying pull requests and creating pull requests are separated. Are they?)

So, maintainers only need to initiate the pull requests. It assumes when pull requests are initiated, everyone at least agrees the justifications of the changes are valid and the ways the changes are done.
In other projects I've worked on, patch owners initiate the pre-commit
build/test, and either comment on the review (ideally with link to the
results) about its status, or have the CI system comment automatically
on the review page/thread.

Once the maintainer has signed off on the patch, it can then be sent for
gatekeeping, which is either a manual process whereby the repo owner (or
subsystem maintainer) checks the review, runs any additional tests they
want etc. - or via a 'land' command (for example with Review Board it's
"rbt land") which automates the checks and pushes the changeset.


I understand that with Azure Pipelines and how it integrates with
Github, along with the fact that this project doesn't use pull requests
or any other review automation, means things are probably going to be
pretty different to most other projects for now.


--

Rebecca Cran


Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Igor Mammedov <imammedo@...>
 

On Tue, 3 Sep 2019 19:20:25 +0200
Laszlo Ersek <lersek@...> wrote:

On 09/03/19 16:53, Igor Mammedov wrote:
On Mon, 2 Sep 2019 21:09:58 +0200
Laszlo Ersek <lersek@...> wrote:

On 09/02/19 10:45, Igor Mammedov wrote:
On Fri, 30 Aug 2019 20:46:14 +0200
Laszlo Ersek <lersek@...> wrote:

On 08/30/19 16:48, Igor Mammedov wrote:

(01) On boot firmware maps and initializes SMI handler at default SMBASE (30000)
(using dedicated SMRAM at 30000 would allow us to avoid save/restore
steps and make SMM handler pointer not vulnerable to DMA attacks)

(02) QEMU hotplugs a new CPU in reset-ed state and sends SCI

(03) on receiving SCI, host CPU calls GPE cpu hotplug handler
which writes to IO port 0xB2 (broadcast SMI)

(04) firmware waits for all existing CPUs rendezvous in SMM mode,
new CPU(s) have SMI pending but does nothing yet

(05) host CPU wakes up one new CPU (INIT-INIT-SIPI)
SIPI vector points to RO flash HLT loop.
(how host CPU will know which new CPUs to relocate?
possibly reuse QEMU CPU hotplug MMIO interface???)

(06) new CPU does relocation.
(in case of attacker sends SIPI to several new CPUs,
open question how to detect collision of several CPUs at the same default SMBASE)

(07) once new CPU relocated host CPU completes initialization, returns
from IO port write and executes the rest of GPE handler, telling OS
to online new CPU.
In step (03), it is the OS that handles the SCI; it transfers control to
ACPI. The AML can write to IO port 0xB2 only because the OS allows it.

If the OS decides to omit that step, and sends an INIT-SIPI-SIPI
directly to the new CPU, can it steal the CPU?
It sure can but this way it won't get access to privileged SMRAM
so OS can't subvert firmware.
The next time SMI broadcast is sent the CPU will use SMI handler at
default 30000 SMBASE. It's up to us to define behavior here (for example
relocation handler can put such CPU in shutdown state).

It's in the best interest of OS to cooperate and execute AML
provided by firmware, if it does not follow proper cpu hotplug flow
we can't guarantee that stolen CPU will work.
This sounds convincing enough, for the hotplugged CPU; thanks.

So now my concern is with step (01). While preparing for the initial
relocation (of cold-plugged CPUs), the code assumes the memory at the
default SMBASE (0x30000) is normal RAM.

Is it not a problem that the area is written initially while running in
normal 32-bit or 64-bit mode, but then executed (in response to the
first, synchronous, SMI) as SMRAM?
currently there is no SMRAM at 0x30000, so all access falls through
into RAM address space and we are about to change that.

but firmware doesn't have to use it as RAM, it can check if QEMU
supports SMRAM at 0x30000 and if supported map it to configure
and then lock it down.
I'm sure you are *technically* right, but you seem to be assuming that I
can modify or rearrange anything I want in edk2. :)
yep, I'm looking at it from theoretical perspective so far,
but what could be done in reality might be limited.

If we can solve the above in OVMF platform code, that's great. If not
(e.g. UefiCpuPkg code needs to be updated), then things will get tricky.
If we can introduce another platform hook for this, that would help. I
can't say before I try.




Basically I'm confused by the alias.

TSEG (and presumably, A/B seg) work like this:
- when open, looks like RAM to normal mode and SMM
- when closed, looks like black-hole to normal mode, and like RAM to SMM

The generic edk2 code knows this, and manages the SMRAM areas accordingly.

The area at 0x30000 is different:
- looks like RAM to both normal mode and SMM

If we set up the alias at 0x30000 into A/B seg,
- will that *permanently* hide the normal RAM at 0x30000?
- will 0x30000 start behaving like A/B seg?

Basically my concern is that the universal code in edk2 might or might
not keep A/B seg open while initially populating the area at the default
SMBASE. Specifically, I can imagine two issues:

- if the alias into A/B seg is inactive during the initial population,
then the initial writes go to RAM, but the execution (the first SMBASE
relocation) will occur from A/B seg through the alias

- alternatively, if the alias is always active, but A/B seg is closed
during initial population (which happens in normal mode), then the
initial writes go to the black hole, and execution will occur from a
"blank" A/B seg.

Am I seeing things? (Sorry, I keep feeling dumber and dumber in this
thread.)
I don't really know how firmware uses A/B segments and I'm afraid that
cannibalizing one for configuring 0x30000 might break something.

Since we are inventing something out of q35 spec anyway, How about
leaving A/B/TSEG to be and using fwcfg to configure when/where
SMRAM(0x30000+128K) should be mapped into RAM address space.

I see a couple of options:
1: use identity mapping where SMRAM(0x30000+128K) maps into the same
range in RAM address space when firmware writes into fwcfg
file and unmaps/locks on the second write (until HW reset)
2: let firmware choose where to map SMRAM(0x30000+128K) in RAM address
space, logic is essentially the same as above only firmware
picks and writes into fwcfg an address where SMRAM(0x30000+128K)
should be mapped.
Option#1 would be similar to how TSEG works now, correct? IOW normal RAM
(from the QEMU perspective) is exposed as "SMRAM" to the guest, hidden
with a "black hole" overlay (outside of SMM) if SMRAM is closed.
it could be stolen RAM + black hole like TSEG, assuming fw can live without RAM(0x30000+128K) range
(in this case fwcfg interface would only work for locking down the range)

or

we can actually have a dedicated SMRAM (like in my earlier RFC),
in this case FW can use RAM(0x30000+128K) when SMRAM isn't mapped into RAM address space
(in this case fwcfg would be used to temporarily map SMRAM into normal RAM and unmap/lock
after SMI relocation handler was initialized).

If possible I'd prefer a simpler TSEG like variant.


If that's correct, then #1 looks more attractive to me than #2.

Thanks
Laszlo


Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Igor Mammedov <imammedo@...>
 

On Mon, 2 Sep 2019 21:09:58 +0200
Laszlo Ersek <lersek@...> wrote:

On 09/02/19 10:45, Igor Mammedov wrote:
On Fri, 30 Aug 2019 20:46:14 +0200
Laszlo Ersek <lersek@...> wrote:

On 08/30/19 16:48, Igor Mammedov wrote:

(01) On boot firmware maps and initializes SMI handler at default SMBASE (30000)
(using dedicated SMRAM at 30000 would allow us to avoid save/restore
steps and make SMM handler pointer not vulnerable to DMA attacks)

(02) QEMU hotplugs a new CPU in reset-ed state and sends SCI

(03) on receiving SCI, host CPU calls GPE cpu hotplug handler
which writes to IO port 0xB2 (broadcast SMI)

(04) firmware waits for all existing CPUs rendezvous in SMM mode,
new CPU(s) have SMI pending but does nothing yet

(05) host CPU wakes up one new CPU (INIT-INIT-SIPI)
SIPI vector points to RO flash HLT loop.
(how host CPU will know which new CPUs to relocate?
possibly reuse QEMU CPU hotplug MMIO interface???)

(06) new CPU does relocation.
(in case of attacker sends SIPI to several new CPUs,
open question how to detect collision of several CPUs at the same default SMBASE)

(07) once new CPU relocated host CPU completes initialization, returns
from IO port write and executes the rest of GPE handler, telling OS
to online new CPU.
In step (03), it is the OS that handles the SCI; it transfers control to
ACPI. The AML can write to IO port 0xB2 only because the OS allows it.

If the OS decides to omit that step, and sends an INIT-SIPI-SIPI
directly to the new CPU, can it steal the CPU?
It sure can but this way it won't get access to privileged SMRAM
so OS can't subvert firmware.
The next time SMI broadcast is sent the CPU will use SMI handler at
default 30000 SMBASE. It's up to us to define behavior here (for example
relocation handler can put such CPU in shutdown state).

It's in the best interest of OS to cooperate and execute AML
provided by firmware, if it does not follow proper cpu hotplug flow
we can't guarantee that stolen CPU will work.
This sounds convincing enough, for the hotplugged CPU; thanks.

So now my concern is with step (01). While preparing for the initial
relocation (of cold-plugged CPUs), the code assumes the memory at the
default SMBASE (0x30000) is normal RAM.

Is it not a problem that the area is written initially while running in
normal 32-bit or 64-bit mode, but then executed (in response to the
first, synchronous, SMI) as SMRAM?
currently there is no SMRAM at 0x30000, so all access falls through
into RAM address space and we are about to change that.

but firmware doesn't have to use it as RAM, it can check if QEMU
supports SMRAM at 0x30000 and if supported map it to configure
and then lock it down.


Basically I'm confused by the alias.

TSEG (and presumably, A/B seg) work like this:
- when open, looks like RAM to normal mode and SMM
- when closed, looks like black-hole to normal mode, and like RAM to SMM

The generic edk2 code knows this, and manages the SMRAM areas accordingly.

The area at 0x30000 is different:
- looks like RAM to both normal mode and SMM

If we set up the alias at 0x30000 into A/B seg,
- will that *permanently* hide the normal RAM at 0x30000?
- will 0x30000 start behaving like A/B seg?

Basically my concern is that the universal code in edk2 might or might
not keep A/B seg open while initially populating the area at the default
SMBASE. Specifically, I can imagine two issues:

- if the alias into A/B seg is inactive during the initial population,
then the initial writes go to RAM, but the execution (the first SMBASE
relocation) will occur from A/B seg through the alias

- alternatively, if the alias is always active, but A/B seg is closed
during initial population (which happens in normal mode), then the
initial writes go to the black hole, and execution will occur from a
"blank" A/B seg.

Am I seeing things? (Sorry, I keep feeling dumber and dumber in this
thread.)
I don't really know how firmware uses A/B segments and I'm afraid that
cannibalizing one for configuring 0x30000 might break something.

Since we are inventing something out of q35 spec anyway, How about
leaving A/B/TSEG to be and using fwcfg to configure when/where
SMRAM(0x30000+128K) should be mapped into RAM address space.

I see a couple of options:
1: use identity mapping where SMRAM(0x30000+128K) maps into the same
range in RAM address space when firmware writes into fwcfg
file and unmaps/locks on the second write (until HW reset)
2: let firmware choose where to map SMRAM(0x30000+128K) in RAM address
space, logic is essentially the same as above only firmware
picks and writes into fwcfg an address where SMRAM(0x30000+128K)
should be mapped.


Anyway, I guess we could try and see if OVMF still boots with the alias...

Thanks
Laszlo

641 - 660 of 772