Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

2020-10-02 Thread Malgorzata Kukiello
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  On Behalf Of gaoliming
Sent: Tuesday, September 29, 2020 3:13 AM
To: devel@edk2.groups.io; Kukiello, Malgorzata ; 
Rothman, Michael A 
Cc: Kinney, Michael D ; Wang, Jian J 
; Wu, Hao A ; Bi, Dandan 
; Liu, Zhiguang ; 'Oleksiy 
Yakovlev' ; 'Ard Biesheuvel' 
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+8761...@groups.io
>  代表 Malgorzata Kukiello
> 发送时间: 2020年9月28日 23:39
> 收件人: devel@edk2.groups.io; gaolim...@byosoft.com.cn
> 抄送: Kinney, Michael D ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan 
> ; Liu, Zhiguang ; 
> 'Oleksiy Yakovlev' ; 'Ard Biesheuvel' 
> 
> 主题: 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  On Behalf Of 
> gaoliming
> Sent: Friday, September 25, 2020 10:55 AM
> To: devel@edk2.groups.io; Kukiello, Malgorzata 
> 
> Cc: Kinney, Michael D ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan 
> ; Liu, Zhiguang ; 
> 'Oleksiy Yakovlev' ; 'Ard Biesheuvel' 
> 
> 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+8761...@groups.io
> >  代表 Malgorzata
> Kukiello
> > 发送时间: 2020年9月24日 18:22
> > 收件人: devel@edk2.groups.io
> > 抄送: Malgorzata Kukiello ; Michael D Kinney 
> > ; Jian J Wang ; 
> > Hao A Wu ; Dandan Bi ; 
> > Liming Gao ; Zhiguang Liu 
> > ; Oleksiy Yakovlev ; Ard 
> > Biesheuvel 
> > 主题: [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 
> > Cc: Michael D Kinney 
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Cc: Dandan Bi 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Oleksiy Yakovlev 
> > Cc: Ard Biesheuvel (ARM address) 
> >
> >  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 
> > int

Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

2020-09-28 Thread Malgorzata Kukiello
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  On Behalf Of gaoliming
Sent: Friday, September 25, 2020 10:55 AM
To: devel@edk2.groups.io; Kukiello, Malgorzata 
Cc: Kinney, Michael D ; Wang, Jian J 
; Wu, Hao A ; Bi, Dandan 
; Liu, Zhiguang ; 'Oleksiy 
Yakovlev' ; 'Ard Biesheuvel' 
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+8761...@groups.io
>  代表 Malgorzata Kukiello
> 发送时间: 2020年9月24日 18:22
> 收件人: devel@edk2.groups.io
> 抄送: Malgorzata Kukiello ; Michael D Kinney 
> ; Jian J Wang ; Hao 
> A Wu ; Dandan Bi ; Liming Gao 
> ; Zhiguang Liu ; 
> Oleksiy Yakovlev ; Ard Biesheuvel 
> 
> 主题: [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 
> Cc: Michael D Kinney 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Oleksiy Yakovlev 
> Cc: Ard Biesheuvel (ARM address) 
> 
>  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.
 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65683): https://edk2.groups.io/g/devel/message/65683
Mute This Topic: https://groups.io/mt/77176704/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

2020-09-24 Thread Laszlo Ersek
On 09/24/20 12:21, Malgorzata Kukiello wrote:
> 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 
> Cc: Michael D Kinney 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Oleksiy Yakovlev 
> Cc: Ard Biesheuvel (ARM address) 
> 
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 12 ++--
>  MdePkg/Include/Uefi/UefiSpec.h   |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

series
Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65569): https://edk2.groups.io/g/devel/message/65569
Mute This Topic: https://groups.io/mt/77056340/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-