-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP 645-human-readable-uefi-secure-boot-key-enrollment-menu #149
base: dasharo
Are you sure you want to change the base?
WIP 645-human-readable-uefi-secure-boot-key-enrollment-menu #149
Conversation
0de6ca7
to
10c2fe6
Compare
3a038b0
to
be95d53
Compare
eff2ef1
to
aaa71f9
Compare
76092d3
to
004460d
Compare
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
Most commits were not accepted as verified. I will try to fix it now/ |
441b34c
to
13edd18
Compare
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
|
||
// There is AsciiStrnToUnicodeStrS function to do that but it | ||
// can't be used in place and allocating another | ||
// AllocateZeroPool(100) fails with EFI_OUT_OF_RESOURCES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If AllocateZeroPool(100) return EFI_OUT_OF_RESOURCES then everything should simply fall apart. There are plenty of places where AllocateZeroPool is used, so there must be something wrong going on here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, that was an hypothesis i had because the certificate entries were not wrong, the list was not rendered at all, even the help
on the right side. I copied the usage of AllocateZeroPool
from this function, including the GOTO statement and figured that GOTO must be causing the rendering to be skipped. I should have stated that it is just a hypothesis, I did not confirm that was the cause of the error.
Either way it works fine now. Should I rewrite this using AsciiStrnToUnicodeStrS and a second buffer instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philipandag Yes, let's try that
14c8a3b
to
798523f
Compare
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
Outdated
Show resolved
Hide resolved
2c80d9c
to
16be91a
Compare
e8109af
to
071648b
Compare
@philipandag can you squash some of these commits? This will make dealing with this after merging (e.g. rebasing, resolving conflics) much easier down the line |
d22b913
to
19439bd
Compare
Squashed where it made sense. It seems that squashing broke the verification so another rebase is coming... |
247fa70
to
265a269
Compare
77bb1c7
to
65398da
Compare
8eccede
to
6b645e4
Compare
Signed-off-by: Filip Golas <[email protected]>
58764c5
to
c8bce61
Compare
Signed-off-by: Filip Lewinski <[email protected]>
f69624d
to
ecf3f5e
Compare
if ((QuestionId == KEY_SECURE_BOOT_PK_OPTION)){ | ||
CloseEnrolledFile (Private->FileContext); | ||
|
||
GetVariable2 (EFI_PLATFORM_KEY_NAME, &gEfiGlobalVariableGuid, (VOID **)&Pk, NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Pk
even needed here? I think (VOID **)&PkList
should work just as good.
PkList = (EFI_SIGNATURE_LIST *)Pk; | ||
Pk = NULL; | ||
|
||
UINTN cnSize = 100; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why this is set to 100?
X509GetCommonName()
can return the required size by passing NULL as CommonName
, that size could be then used to allocate the buffers and X509GetCommonName()
can then be repeated with CommonName
set to allocated buffer.
Alternatively, this length can be set to whatever fits in GUI (e.g. if multi-line name could impact test automation), but then we would have to somehow mark when the rest was truncated, e.g. by appending ...
at the end, but then it may skip the important parts after generic company name.
No description provided.