public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Malgorzata Kukiello" <jacek.kukiello@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"gaoliming@byosoft.com.cn" <gaoliming@byosoft.com.cn>,
	"Rothman, Michael A" <michael.a.rothman@intel.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Wang, Jian J" <jian.j.wang@intel.com>,
	"Wu, Hao A" <hao.a.wu@intel.com>,
	"Bi, Dandan" <dandan.bi@intel.com>,
	"Liu, Zhiguang" <zhiguang.liu@intel.com>,
	"'Oleksiy Yakovlev'" <oleksiyy@ami.com>,
	'Ard Biesheuvel' <ard.biesheuvel@arm.com>
Subject: Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too
Date: Fri, 2 Oct 2020 12:52:08 +0000	[thread overview]
Message-ID: <CY4PR11MB1573D9E5FC927D6B7E9BC4B191310@CY4PR11MB1573.namprd11.prod.outlook.com> (raw)
In-Reply-To: <001701d695fd$bdda8e90$398fabb0$@byosoft.com.cn>

Liming,
I am trying to enable a crypto technology, that requires handling on the OS side (implemented in the kernel.org patch), generally speaking I mark in memory map all regions that can be encrypted using the before mentioned tech. Then OS checks that attribute and decides whether or not to enable that.
So the real problem is that currently all my attributes are overwritten and cleared.
Thanks
Meg

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, September 29, 2020 3:13 AM
To: devel@edk2.groups.io; Kukiello, Malgorzata <jacek.kukiello@intel.com>; Rothman, Michael A <michael.a.rothman@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; 'Oleksiy Yakovlev' <oleksiyy@ami.com>; 'Ard Biesheuvel' <ard.biesheuvel@arm.com>
Subject: 回复: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

Meg:
  What real problem do you meet with? What purpose is for this change? And, I also include UEFI Arch Rothman. 

Rothman:
  Can you help clarify what OS (Windows or Linux) behavior is expected for UEFI SP and CRYPTO memory attribute?

Thanks
Liming
> -----邮件原件-----
> 发件人: bounce+27952+65683+4905953+8761045@groups.io
> <bounce+27952+65683+4905953+8761045@groups.io> 代表 Malgorzata Kukiello
> 发送时间: 2020年9月28日 23:39
> 收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn
> 抄送: Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Jian J 
> <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan 
> <dandan.bi@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; 
> 'Oleksiy Yakovlev' <oleksiyy@ami.com>; 'Ard Biesheuvel' 
> <ard.biesheuvel@arm.com>
> 主题: Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding 
> page-access caps from OSes hides SP and CRYPTO caps too
> 
> Liming,
> As for mktme there is a change commited:
> https://patchwork.kernel.org/patch/10935909/
> As for SP I can't find anything specific.
> Thanks
> Meg
> 
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> gaoliming
> Sent: Friday, September 25, 2020 10:55 AM
> To: devel@edk2.groups.io; Kukiello, Malgorzata 
> <jacek.kukiello@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Jian J 
> <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan 
> <dandan.bi@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; 
> 'Oleksiy Yakovlev' <oleksiyy@ami.com>; 'Ard Biesheuvel' 
> <ard.biesheuvel@arm.com>
> Subject: 回复: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for 
> hiding page-access caps from OSes hides SP and CRYPTO caps too
> 
> Malgorzata:
>   How do know OS (Windows or Linux) behavior for SP and CRYPTO attribute?
> Is there the public document to describe this behavior?
> 
> Thanks
> Liming
> > -----邮件原件-----
> > 发件人: bounce+27952+65566+4905953+8761045@groups.io
> > <bounce+27952+65566+4905953+8761045@groups.io> 代表 Malgorzata
> Kukiello
> > 发送时间: 2020年9月24日 18:22
> > 收件人: devel@edk2.groups.io
> > 抄送: Malgorzata Kukiello <jacek.kukiello@intel.com>; Michael D Kinney 
> > <michael.d.kinney@intel.com>; Jian J Wang <jian.j.wang@intel.com>; 
> > Hao A Wu <hao.a.wu@intel.com>; Dandan Bi <dandan.bi@intel.com>; 
> > Liming Gao <gaoliming@byosoft.com.cn>; Zhiguang Liu 
> > <zhiguang.liu@intel.com>; Oleksiy Yakovlev <oleksiyy@ami.com>; Ard 
> > Biesheuvel <ard.biesheuvel@arm.com>
> > 主题: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding 
> > page-access caps from OSes hides SP and CRYPTO caps too
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2982
> >
> > The workaround in the UEFI memmap construction, near the end of the 
> > function CoreGetMemoryMap() [MdeModulePkg/Core/Dxe/Mem/Page.c]
> > should
> > not clear the SP and CRYPTO bits, because OSes do (apparently) 
> > correctly interpret SP and CRYPTO as capabilities, and not as 
> > currently set attributes (upon which the OSes should set their page 
> > tables). For this reason, the SP and CRYPTO bits should be separated 
> > from the bitmask that we use for hiding the page-access attributes, 
> > in the workaround
> >
> > Signed-off-by: Malgorzata Kukiello <jacek.kukiello@intel.com>
> > Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > Cc: Jian J Wang <jian.j.wang@intel.com>
> > Cc: Hao A Wu <hao.a.wu@intel.com>
> > Cc: Dandan Bi <dandan.bi@intel.com>
> > Cc: Liming Gao <gaoliming@byosoft.com.cn>
> > Cc: Zhiguang Liu <zhiguang.liu@intel.com>
> > Cc: Oleksiy Yakovlev <oleksiyy@ami.com>
> > Cc: Ard Biesheuvel (ARM address) <ard.biesheuvel@arm.com>
> >
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 12 ++++++------
> >  MdePkg/Include/Uefi/UefiSpec.h   |  3 ++-
> >  2 files changed, 8 insertions(+), 7 deletions(-)
> > --------------------------------------------------------------------
> > -
> > Intel Technology Poland sp. z o.o.
> > ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII 
> > Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP
> > 957-07-52-316
> > | Kapita zakadowy 200.000 PLN.
> > Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego 
> > adresata i moe zawiera informacje poufne. W razie przypadkowego 
> > otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae 
> > jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione.
> > This e-mail and any attachments may contain confidential material 
> > for the sole use of the intended recipient(s). If you are not the 
> > intended
> recipient,
> > please contact the sender and delete all copies; any review or
> distribution by
> > others is strictly prohibited.
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Intel Technology Poland sp. z o.o.
> ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII 
> Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 
> 957-07-52-316 | Kapita zakadowy 200.000 PLN.
> Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata 
> i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej 
> wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; 
> jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). If you are not the intended 
> recipient, please contact the sender and delete all copies; any review 
> or distribution by others is strictly prohibited.
> 
> 
> 
> 
> 








---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN.
Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
 

  reply	other threads:[~2020-10-02 12:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 10:21 [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too jacek.kukiello
2020-09-24 10:21 ` [PATCH v2 2/2] MdeModulePkg/Core/Dxe: expose SP and CRYPTO capabilities in UEFI memmap Malgorzata Kukiello
2020-09-24 10:21 ` [PATCH v2 1/2] MdePkg/UefiSpec: separate page access bitmask from SP and CRYPTO caps Malgorzata Kukiello
2020-09-24 13:04 ` [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too Laszlo Ersek
2020-09-25  8:54 ` 回复: " gaoliming
2020-09-28 15:39   ` Malgorzata Kukiello
2020-09-29  1:13     ` 回复: " gaoliming
2020-10-02 12:52       ` Malgorzata Kukiello [this message]
     [not found]       ` <163A2DF5FC986A3A.27356@groups.io>
2020-10-09  6:01         ` Malgorzata Kukiello
2020-10-09  9:30           ` 回复: " gaoliming
     [not found]           ` <163C48FE4529CC02.8231@groups.io>
2020-10-10  3:35             ` gaoliming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR11MB1573D9E5FC927D6B7E9BC4B191310@CY4PR11MB1573.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox