[PATCH] kern/efi/sb: Remove duplicate variables efi_shim_lock_guid
The variable efi_shim_lock_guid and the static variable
shim_lock_guid have the same GUID value, only the global
variable shim_lock_guid is retained.
Signed-off-by: Tianjia Zhang
---
grub-core/kern/efi/sb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/grub-core/kern/efi/sb.c b/grub-core/kern/efi/sb.c
index 96d237722..c52ec6226 100644
--- a/grub-core/kern/efi/sb.c
+++ b/grub-core/kern/efi/sb.c
@@ -42,7 +42,6 @@ grub_uint8_t
grub_efi_get_secureboot (void)
{
static grub_efi_guid_t efi_variable_guid = GRUB_EFI_GLOBAL_VARIABLE_GUID;
- static grub_efi_guid_t efi_shim_lock_guid = GRUB_EFI_SHIM_LOCK_GUID;
grub_efi_status_t status;
grub_efi_uint32_t attr = 0;
grub_size_t size = 0;
@@ -81,7 +80,7 @@ grub_efi_get_secureboot (void)
* variable doesn't have the runtime attribute set, we might as well
* honor that.
*/
- status = grub_efi_get_variable_with_attributes ("MokSBState",
&efi_shim_lock_guid,
+ status = grub_efi_get_variable_with_attributes ("MokSBState",
&shim_lock_guid,
&size, (void **) &moksbstate,
&attr);
/* If it fails, we don't care why. Default to secure. */
--
2.24.3 (Apple Git-128)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2.06 RELEASE PATCH v2 3/4] fs/xfs: Add bigtime incompat feature support
On Wed, May 12, 2021 at 05:46:15PM +0200, Javier Martinez Canillas wrote:
> From: Carlos Maiolino
>
> The XFS filesystem supports a bigtime feature to overcome y2038 problem.
> This patch makes the GRUB able to support the XFS filesystems with this
> feature enabled.
>
> The XFS counter for the bigtime enabled timestamps starts on 0, which
> translates to GRUB_INT32_MIN (Dec 31 20:45:52 UTC 1901) in the legacy
> timestamps. The conversion to unix timestamps is made before passing the
> value to other GRUB functions.
>
> For this to work properly, GRUB requires to access flags2 field in the
> XFS ondisk inode. So, the grub_xfs_inode structure has been updated to
> the full ondisk inode size.
s/the full ondisk inode size/cover full ondisk inode/?
> This patch is enough to make the GRUB work properly with files that have
> timestamps with values up to GRUB_INT32_MAX (Jan 19 03:14:07 UTC 2038).
This paragraph contradicts a bit what was said in the first paragraph...
> Any file with a timestamps bigger than this will overflow the counter,
> causing GRUB to show wrong timestamps. This is not really different than
> the current situation, since the timestamps in GRUB are 32-bit values.
Err... I think this is incorrect right now because the patch before this
one fixed the issue. So, this paragraph should be dropped. There is only
one question: are the changes here sufficient to have full XFS bigtime
support in the GRUB? I think they are...
> Signed-off-by: Carlos Maiolino
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes in v2:
> - Improve the commit message of patch #3 (dkiper).
> - Drop Reviewed-by tag from patch #3 (dkiper).
> _ Drop unrelated changes in patch #3 (dkiper).
>
> grub-core/fs/xfs.c | 63 +-
> 1 file changed, 51 insertions(+), 12 deletions(-)
>
> diff --git a/grub-core/fs/xfs.c b/grub-core/fs/xfs.c
> index 43023e03fb3..bcf281cf80d 100644
> --- a/grub-core/fs/xfs.c
> +++ b/grub-core/fs/xfs.c
> @@ -75,10 +75,15 @@ GRUB_MOD_LICENSE ("GPLv3+");
>XFS_SB_VERSION2_PROJID32BIT | \
>XFS_SB_VERSION2_FTYPE)
>
> +/* Inode flags2 flags */
> +#define XFS_DIFLAG2_BIGTIME_BIT 3
> +#define XFS_DIFLAG2_BIGTIME (1 << XFS_DIFLAG2_BIGTIME_BIT)
> +
> /* incompat feature flags */
> #define XFS_SB_FEAT_INCOMPAT_FTYPE (1 << 0)/* filetype in
> dirent */
> #define XFS_SB_FEAT_INCOMPAT_SPINODES (1 << 1)/* sparse inode
> chunks */
> #define XFS_SB_FEAT_INCOMPAT_META_UUID (1 << 2)/* metadata UUID */
> +#define XFS_SB_FEAT_INCOMPAT_BIGTIME(1 << 3)/* large timestamps
> */
>
> /*
> * Directory entries with ftype are explicitly handled by GRUB code.
> @@ -92,7 +97,8 @@ GRUB_MOD_LICENSE ("GPLv3+");
> #define XFS_SB_FEAT_INCOMPAT_SUPPORTED \
> (XFS_SB_FEAT_INCOMPAT_FTYPE | \
>XFS_SB_FEAT_INCOMPAT_SPINODES | \
> - XFS_SB_FEAT_INCOMPAT_META_UUID)
> + XFS_SB_FEAT_INCOMPAT_META_UUID | \
> + XFS_SB_FEAT_INCOMPAT_BIGTIME)
>
> struct grub_xfs_sblock
> {
> @@ -177,7 +183,7 @@ struct grub_xfs_btree_root
>grub_uint64_t keys[1];
> } GRUB_PACKED;
>
> -struct grub_xfs_time
> +struct grub_xfs_time_legacy
> {
>grub_uint32_t sec;
>grub_uint32_t nanosec;
> @@ -190,20 +196,23 @@ struct grub_xfs_inode
>grub_uint8_t version;
>grub_uint8_t format;
>grub_uint8_t unused2[26];
> - struct grub_xfs_time atime;
> - struct grub_xfs_time mtime;
> - struct grub_xfs_time ctime;
> + grub_uint64_t atime;
> + grub_uint64_t mtime;
> + grub_uint64_t ctime;
>grub_uint64_t size;
>grub_uint64_t nblocks;
>grub_uint32_t extsize;
>grub_uint32_t nextents;
>grub_uint16_t unused3;
>grub_uint8_t fork_offset;
> - grub_uint8_t unused4[17];
> + grub_uint8_t unused4[37];
> + grub_uint64_t flags2;
> + grub_uint8_t unused5[48];
> } GRUB_PACKED;
>
> -#define XFS_V2_INODE_SIZE sizeof(struct grub_xfs_inode)
> -#define XFS_V3_INODE_SIZE (XFS_V2_INODE_SIZE + 76)
> +#define XFS_V3_INODE_SIZE sizeof(struct grub_xfs_inode)
> +/* Size of struct grub_xfs_inode until fork_offset (included)*/
> +#define XFS_V2_INODE_SIZE (XFS_V3_INODE_SIZE - 92)
>
> struct grub_xfs_dirblock_tail
> {
> @@ -233,8 +242,6 @@ struct grub_xfs_data
>
> static grub_dl_t my_mod;
>
> -
> -
Could you drop this change?
> static int grub_xfs_sb_hascrc(struct grub_xfs_data *data)
> {
>return (data->sblock.version &
> grub_cpu_to_be16_compile_time(XFS_SB_VERSION_NUMBITS)) ==
> @@ -950,7 +957,6 @@ grub_xfs_mount (grub_disk_t disk)
>return 0;
> }
>
> -
Ditto...
> /* Context for grub_xfs_dir. */
> struct grub_xfs_dir_ctx
> {
> @@ -958,6 +964,39 @@ struct grub_xfs_dir_ctx
>void *hook_data;
> };
>
> +/* Bigtime inodes helpers */
> +
> +#define NSEC_PER_SEC 10L
> +#define XFS_BIGTIME_EPOCH_OFFSET (-(grub_int64_t)GRUB_INT32_MIN)
I think starting from here you forgot to take into account my comments...
> +static int grub_xfs_inode_has_bigtime(const struct grub_xfs_ino
Re: [2.06 RELEASE PATCH v2 4/4] fs/xfs: Add needsrepair incompat feature support
On Wed, May 12, 2021 at 05:46:16PM +0200, Javier Martinez Canillas wrote:
> The XFS now has an incompat feature flag to indicate that the filesystem
> needs to be repaired. The Linux kernel refuses to mount a filesystem that
> has it set and only the xfs_repair tool is able to clear that flag.
>
> The GRUB doesn't have the concept of mounting filesystems and just attempt
s/attempt/attempts/
> to read the files. But it does some sanity checking before attempting to
> read from a filesystem.
>
> Among the things which are tested, is if the super block only has set the
> incompatible features flags that are supported by GRUB. If it contains any
> flags that are not listed as supported, reading the XFS filesystem fails.
>
> Since the GRUB doesn't attempt to detect if the filesystem is inconsistent
> nor replays the journal, just ignore if a filesystem needs to be repaired.
This sentence does not parse well...
> For this reason, make it a best effort but print a debug message when the
s/but/and/
> XFS filesystem is accessed if should be repaired. That way, if the reading
s/is accessed if/accessed/
> or later booting fail, the user can figure out that may be related to this.
s/if the reading or later booting fail/if later reading or booting fails/
> Suggested-by: Eric Sandeen
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes in v2:
> - Improve commit message of patch #4 (dkiper).
> - Fix typo in debug message of patch #4 (dkiper).
>
> grub-core/fs/xfs.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/xfs.c b/grub-core/fs/xfs.c
> index bcf281cf80d..6056bf44e32 100644
> --- a/grub-core/fs/xfs.c
> +++ b/grub-core/fs/xfs.c
> @@ -84,6 +84,7 @@ GRUB_MOD_LICENSE ("GPLv3+");
> #define XFS_SB_FEAT_INCOMPAT_SPINODES (1 << 1)/* sparse inode
> chunks */
> #define XFS_SB_FEAT_INCOMPAT_META_UUID (1 << 2)/* metadata UUID */
> #define XFS_SB_FEAT_INCOMPAT_BIGTIME(1 << 3)/* large timestamps
> */
> +#define XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR (1 << 4) /* needs xfs_repair
> */
>
> /*
> * Directory entries with ftype are explicitly handled by GRUB code.
> @@ -98,7 +99,8 @@ GRUB_MOD_LICENSE ("GPLv3+");
> (XFS_SB_FEAT_INCOMPAT_FTYPE | \
>XFS_SB_FEAT_INCOMPAT_SPINODES | \
>XFS_SB_FEAT_INCOMPAT_META_UUID | \
> - XFS_SB_FEAT_INCOMPAT_BIGTIME)
> + XFS_SB_FEAT_INCOMPAT_BIGTIME | \
> + XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR)
>
> struct grub_xfs_sblock
> {
> @@ -307,6 +309,16 @@ static int grub_xfs_sb_valid(struct grub_xfs_data *data)
>return 0;
> }
>
> +static int
> +grub_xfs_sb_needs_repair (struct grub_xfs_data *data)
> +{
> + return ((data->sblock.version &
> + grub_cpu_to_be16_compile_time (XFS_SB_VERSION_NUMBITS)) ==
> + grub_cpu_to_be16_compile_time (XFS_SB_VERSION_5) &&
> + (data->sblock.sb_features_incompat &
> + grub_cpu_to_be32_compile_time
> (XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR)));
> +}
> +
> /* Filetype information as used in inodes. */
> #define FILETYPE_INO_MASK017
> #define FILETYPE_INO_REG 010
> @@ -922,6 +934,9 @@ grub_xfs_mount (grub_disk_t disk)
>if (!grub_xfs_sb_valid(data))
> goto fail;
>
> + if (grub_xfs_sb_needs_repair (data))
> +grub_dprintf ("xfs", "XFS filesystem needs repair, can lead to
> failures\n");
s/can lead to failures/boot may fail/
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2.06 RELEASE PATCH v2 3/4] fs/xfs: Add bigtime incompat feature support
Hello Daniel,
On 5/17/21 4:09 PM, Daniel Kiper wrote:
> On Wed, May 12, 2021 at 05:46:15PM +0200, Javier Martinez Canillas wrote:
>> From: Carlos Maiolino
>>
>> The XFS filesystem supports a bigtime feature to overcome y2038 problem.
>> This patch makes the GRUB able to support the XFS filesystems with this
>> feature enabled.
>>
>> The XFS counter for the bigtime enabled timestamps starts on 0, which
>> translates to GRUB_INT32_MIN (Dec 31 20:45:52 UTC 1901) in the legacy
>> timestamps. The conversion to unix timestamps is made before passing the
>> value to other GRUB functions.
>>
>> For this to work properly, GRUB requires to access flags2 field in the
>> XFS ondisk inode. So, the grub_xfs_inode structure has been updated to
>> the full ondisk inode size.
>
> s/the full ondisk inode size/cover full ondisk inode/?
>
Ok.
>> This patch is enough to make the GRUB work properly with files that have
>> timestamps with values up to GRUB_INT32_MAX (Jan 19 03:14:07 UTC 2038).
>
> This paragraph contradicts a bit what was said in the first paragraph...
>
>> Any file with a timestamps bigger than this will overflow the counter,
>> causing GRUB to show wrong timestamps. This is not really different than
>> the current situation, since the timestamps in GRUB are 32-bit values.
>
> Err... I think this is incorrect right now because the patch before this
> one fixed the issue. So, this paragraph should be dropped. There is only
> one question: are the changes here sufficient to have full XFS bigtime
> support in the GRUB? I think they are...
>
Yes, sorry about that. Originally Carlos' series had this patch before 1/4
and I re-arranged them in the series because made more sense to first add
the 64-bit support in GRUB core and then the XFS support. I'll drop this.
[snip]
>>
>> static grub_dl_t my_mod;
>>
>> -
>> -
>
Ok.
> Could you drop this change?
>
>> static int grub_xfs_sb_hascrc(struct grub_xfs_data *data)
>> {
>>return (data->sblock.version &
>> grub_cpu_to_be16_compile_time(XFS_SB_VERSION_NUMBITS)) ==
>> @@ -950,7 +957,6 @@ grub_xfs_mount (grub_disk_t disk)
>>return 0;
>> }
>>
>> -
>
> Ditto...
>
Ok.
>> /* Context for grub_xfs_dir. */
>> struct grub_xfs_dir_ctx
>> {
>> @@ -958,6 +964,39 @@ struct grub_xfs_dir_ctx
>>void *hook_data;
>> };
>>
>> +/* Bigtime inodes helpers */
>> +
>> +#define NSEC_PER_SEC 10L
>> +#define XFS_BIGTIME_EPOCH_OFFSET (-(grub_int64_t)GRUB_INT32_MIN)
>
> I think starting from here you forgot to take into account my comments...
>
Oh, I did indeed miss these comments... sorry, I'll fix them in v3.
Best regards, --
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] kern/efi/sb: Remove duplicate variables efi_shim_lock_guid
On Mon, May 17, 2021 at 08:57:30PM +0800, Tianjia Zhang wrote: > The variable efi_shim_lock_guid and the static variable > shim_lock_guid have the same GUID value, only the global > variable shim_lock_guid is retained. > > Signed-off-by: Tianjia Zhang Good catch! Thanks! Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Fix backspace in the username login prompt
On Tue, May 11, 2021 at 09:52:39AM +0300, Egor Ignatov wrote: > This patch fixes a bug when backspace key does not work in the > username login prompt. It allows backspace characters in the BIDI > visual line. Thus grub_gfxterm_putchar receives '\b' chars that > were previously ignored. > > Signed-off-by: Egor Ignatov > --- > > Did you test this patch with other BIDI type BN characters [1]? I am not > > You are right, I added a check to handle only backspace characters > > > convinced it works with them as expected. I think earlier version of your > > patch was more promising... > > Earlier versions of my patch included workaround for special case when > the password is longer than one line. This scenario is not very > realistic and I dont think it's worth complicating the codebase. > > Thank you for your response. > Let me know if you have any concerns about this version. Did you test your patch outside of username login prompt, e.g. CLI or menu entry editing? I am afraid your patch breaks at least these cases. Daniel > Egor > > grub-core/normal/charset.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/grub-core/normal/charset.c b/grub-core/normal/charset.c > index 4dfcc3107..8e7add1f8 100644 > --- a/grub-core/normal/charset.c > +++ b/grub-core/normal/charset.c > @@ -931,6 +931,8 @@ grub_bidi_line_logical_to_visual (const grub_uint32_t > *logical, > pop_stack (); > break; > case GRUB_BIDI_TYPE_BN: > + if (visual[visual_len].base == '\b') > + visual_len++; > break; > case GRUB_BIDI_TYPE_R: > case GRUB_BIDI_TYPE_AL: ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Hi Jan,
On Thu, May 13, 2021 at 12:35:25PM +0200, Jan Nieuwenhuizen wrote:
> Daniel Kiper writes:
>
> Hello Daniel,
>
> > May I ask you to try latest GRUB master git branch [1]? The GRUB 2.04
> > release is a few years old. We are going to release 2.06 soon.
>
> Sure. The bug is still there (see attached patch to reproduce using
> Guix):
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub
> starting phase `unpack'
> grub-2.06~rc1/
> [..]
> starting phase `configure'
> source directory: "/tmp/guix-build-grub-2.06-rc1.drv-0/grub-2.06~rc1"
> (relative from build: ".")
> build directory: "/tmp/guix-build-grub-2.06-rc1.drv-0/grub-2.06~rc1"
> configure flags: ("CC_FOR_BUILD=gcc"
> "CONFIG_SHELL=/gnu/store/v1g7f3p4f0851mywrla8qmr9hb8jgfjr-bash-minimal-5.0.16/bin/bash"
>
> "SHELL=/gnu/store/v1g7f3p4f0851mywrla8qmr9hb8jgfjr-bash-minimal-5.0.16/bin/bash"
> "--prefix=/gnu/store/753q8z0xa9ijap3p3phpsvns7287c7sn-grub-2.06-rc1"
> "--enable-fast-install" "--build=i686-unknown-linux-gnu" "--host=i586-pc-gnu"
> "PYTHON=true")
> [..]
> starting phase `build'
> [..]
> i586-pc-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -DGRUB_MACHINE_PCBIOS=1
> -DGRUB_MACHINE=I386_PC -m32 -nostdinc -isystem
> /gnu/store/q8af3pvwsknn132pl1nzrb5281i4pgij-gcc-cross-i586-pc-gnu-7.5.0-lib/lib/gcc/i586-pc-gnu/7.5.0/include
> -I../include -I../include -DGRUB_FILE=\"lib/i386/relocator.c\" -I. -I. -I..
> -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/
> -D_FILE_OFFSET_BITS=64 -std=gnu99 -Os -m32 -Wall -W -Wshadow -Wpointer-arith
> -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations
> -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args
> -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration
> -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar
> -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch
> -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label
> -Wunused-parameter -Wunused-value -Wunused-variable -Wwrite-strings
> -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls
> -Wmissing-prototypes -Wmissing-declarations -Wextra -Wattributes
> -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch
> -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast
> -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign
> -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2
> -march=i386 -mrtd -mregparm=3 -falign-jumps=1 -falign-loops=1
> -falign-functions=1 -freg-struct-return -mno-mmx -mno-sse -mno-sse2 -mno-sse3
> -mno-3dnow -msoft-float -fno-dwarf2-cfi-asm -mno-stack-arg-probe
> -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-ident
> -fno-stack-protector -Wtrampolines -Werror -ffreestanding -MT
> lib/i386/relocator_module-relocator.o -MD -MP -MF
> lib/i386/.deps-core/relocator_module-relocator.Tpo -c -o
> lib/i386/relocator_module-relocator.o `test -f 'lib/i386/relocator.c' || echo
> './'`lib/i386/relocator.c
> lib/i386/relocator64.S: Assembler messages:
> lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
> lib/i386/relocator64.S:74: Error: bad register name `%rax'
> lib/i386/relocator64.S:98: Error: bad register name `%rax'
> lib/i386/relocator64.S:132: Error: bad register name `%rip)'
> --8<---cut here---end--->8---
[...]
> > A patch should be prepared on top of latest GRUB master git branch [1].
>
> Sure, but well..
>
> https://lists.gnu.org/archive/html/bug-grub/2020-06/msg00013.html
>
> it was when I sent the report ;)
Sorry, I missed it...
> Luckily it still applied cleanly to current master.
Great!
> > And please use "git-send-email" to send the patch as Adrian said...
>
> Sure, sent separately to bug-grub.
I cannot find your updated patch. May I ask you to send it using
"git-send-email" to grub-devel@gnu.org?
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Daniel Kiper writes: Hello Daniel, [..] >> Sure, sent separately to bug-grub. > > I cannot find your updated patch. It's here: https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html > May I ask you to send it using "git-send-email" to grub-devel@gnu.org? (waiting with this for a bit, please ping if needed :) Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
