Re: Plain dm-crypt
On 29 Oct 2015 6:24 am, wrote: > > Actually, plain dm-crypt has one distinct advantage to LUKS, and that is one of plausible deniability. In some countries, you can be court-ordered to decrypt the contents of a device if it can be proven that encrypted contents exist. With LUKS, there is no denying it; with plain dm-crypt and its lack of an encryption header, the device could just as well have been overwritten with random data. > > I boot my OS off of an encrypted thumb drive in libreboot using "cryptomount -a (usb0)", -a already means "all". Having to indicate usb0 manually is already a proof that you have an unmarked cryptocontainer. Moreover this line exactly illustrates my point: what is usb0 depends on other plugged device and even his fast they are and may vary from boot to boot. I'm not quite convinced you can deny this line plausibly >so UUIDs don't matter to me at all. I understand that for most users, this will not be the case, but I'm sure that there are enough of us out there who could really make use of this feature. > > Also, for those like myself who want this feature for reasons of plausible deniabilty, patching it ourselves is not an option, as going to that length to include the feature would indicate that we are most likely using it, thus throwing plausible deniability out the window. In other words, to keep it plausible, it would have to be a stock feature across the board. > > Chris > > > On 2015-10-27 11:10, Vladimir 'phcoder' Serbinenko wrote: >> >> There are patches for it but they will not be integrated as plain dm-crypt >> has no advantages compared to LUKS and cannot be configured reliably when >> device names change as they have no UUID >> Le 27 oct. 2015 8:20 AM, a écrit : >> >>> Hello; >>> I apologize if this question has already been asked. A web search didn't >>> turn anything up. Are there any plans to include plain dm-crypt support in >>> a future version of grub? >>> >>> Thank you. >>> Chris >>> >>> ___ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> https://lists.gnu.org/mailman/listinfo/grub-devel >>> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
Yes, it happens when booting from grub from UEFI firmware: I tested it on X-Gene. Cheers, Stefano On Thu, 29 Oct 2015, Fu Wei wrote: > Hi Stefano, > > I have tried my grub on Foundation model, but I did not get this > error, I guess that is the UEFI problem ? > > On 1 October 2015 at 00:00, Stefano Stabellini > wrote: > > Hi Fu, > > > > I backported your patches to the CentOS aarch64 grub2 rpm. I am testing > > it on X-Gene with EFI firmware. It works fine when booting Xen, but > > booting native kernels (no Xen) doesn't work anymore. Grub prints > > > > error: out of memory. > > > > Press any key to continue... > > > > grub is still able to continue and load Linux, but then the kernel fails > > to boot with "Cannot open root device", even though the grub config is > > still same as before and the rootfs (which is xfs) hasn't changed. > > Reverting the patches solved the problem. > > > > Do you have any ideas on what is causing the issue? Maybe the initramfs > > hasn't been properly loaded? > > > > > > Thanks, > > > > Stefano > > > > > > On Tue, 8 Sep 2015, Fu Wei wrote: > >> Hi Vladimir, > >> > >> Do you have any suggestion on this patchset? > >> Do I need to improve anything? > >> > >> Great thanks for your help. > >> > >> On 4 August 2015 at 16:34, Fu Wei wrote: > >> > Hi Vladimir, > >> > > >> > this patchset follows all your comment of v2 patchset. > >> > Do you have any suggestion on this patchset? > >> > > >> > Great thanks for your help. > >> > > >> > > >> > On 23 July 2015 at 13:16, wrote: > >> >> From: Fu Wei > >> >> > >> >> - This adds support for the Xen boot on ARM specification for arm64. > >> >> > >> >> - Add and export some accessor functions of "loaded" flag and > >> >> grub_linux_get_fdt function in include/grub/arm64/linux.h for xen > >> >> boot. > >> >> > >> >> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm > >> >> to load different binaries for xen boot. > >> >> Introduce xen_module to load common or custom module for xen boot. > >> >> > >> >> - This Xen boot support is a separated module for aarch64, > >> >> but reuse the existing code of devicetree in linux module. > >> >> > >> >> - Add the support of xen_hypervisor, xen_linux and xen_initrd > >> >> in util/grub.d/20_linux_xen.in > >> >> > >> >> - Add the introduction of all xen boot commands in docs/grub.texi > >> >> > >> >> - The example of this support is >> >> AArch64 the Foundation FVP model> > >> >> > >> >> https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB > >> >> > >> >> Changelog: > >> >> v3: create separate module for xen boot: xen_boot > >> >> create separate commands for different types of module > >> >> delete order-dependent for commands of xen module > >> >> simplify the code > >> >> > >> >> v2: remove the patches which have been accepted. > >> >> according to Vladimir's suggestion, change the command manes > >> >> and relevant code: > >> >> multiboot-->xen_hypervisor > >> >> module-->xen_module > >> >> improve the option parsing support for xen_hypervisor/xen_module > >> >> commands. > >> >> add a patch for adding xen_hypervisor/xen_module support > >> >> in util/grub.d/20_linux_xen.in. > >> >> update docs/grub.texi patch for the new command names. > >> >> > >> >> v1: The first version upstream patchset to grub-devel mailing list > >> >> > >> >> > >> >> Fu Wei (4): > >> >> arm64: Add and export some accessor functions for xen boot > >> >> arm64: Add xen_boot module file > >> >> * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 > >> >> arm64: Add the introduction of xen boot commands in docs/grub.texi > >> >> > >> >> docs/grub.texi| 56 > >> >> grub-core/Makefile.core.def | 7 + > >> >> grub-core/loader/arm64/linux.c| 13 + > >> >> grub-core/loader/arm64/xen_boot.c | 685 > >> >> ++ > >> >> include/grub/arm64/linux.h| 6 +- > >> >> util/grub.d/20_linux_xen.in | 16 +- > >> >> 6 files changed, 779 insertions(+), 4 deletions(-) > >> >> create mode 100644 grub-core/loader/arm64/xen_boot.c > >> >> > >> >> -- > >> >> 1.8.3.1 > >> >> > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > > >> > Fu Wei > >> > Software Engineer > >> > Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch > >> > Ph: +86 21 61221326(direct) > >> > Ph: +86 186 2020 4684 (mobile) > >> > Room 1512, Regus One Corporate Avenue,Level 15, > >> > One Corporate Avenue,222 Hubin Road,Huangpu District, > >> > Shanghai,China 200021 > >> > >> > >> > >> -- > >> Best regards, > >> > >> Fu Wei > >> Software Engineer > >> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch > >> Ph: +86 21 61221326(direct) > >> Ph: +86 186 2020 4684 (mobile) > >> Room 1512, Regus One Corporate Avenue,Level 15, > >> One Corporate Avenue,222 Hubin Road,Huangpu District, > >> Shanghai,China 200021 > >> >
Re: [PATCH v3 1/4] arm64: Add and export some accessor functions for xen boot
On 23.07.2015 07:16, fu@linaro.org wrote:
> From: Fu Wei
>
> Add accessor functions of "loaded" flag in
> grub-core/loader/arm64/linux.c.
>
> Export accessor functions of "loaded" flag and
> grub_linux_get_fdt function in include/grub/arm64/linux.h.
>
> Purpose: Reuse the existing code of devicetree in linux module.
>
> Signed-off-by: Fu Wei
> ---
> grub-core/loader/arm64/linux.c | 13 +
> include/grub/arm64/linux.h | 6 +-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
> index 987f5b9..cf6026e 100644
> --- a/grub-core/loader/arm64/linux.c
> +++ b/grub-core/loader/arm64/linux.c
> @@ -48,6 +48,19 @@ static grub_addr_t initrd_end;
> static void *loaded_fdt;
> static void *fdt;
>
> +/* The accessor functions for "loaded" flag */
> +int
> +grub_linux_get_loaded (void)
> +{
> + return loaded;
> +}
> +
> +void
> +grub_linux_set_loaded (int loaded_flag)
> +{
> + loaded = loaded_flag;
> +}
> +
Accessor functions are usually useless in GRUB. We have no public API to
respect. So it only adds clutter. Also "loaded" flag is static for а
good reason: it's specific to linux.c. I'm going to move fdt part to
fdt.c and have uniform interface for both linux and xen.
> static void *
> get_firmware_fdt (void)
> {
> diff --git a/include/grub/arm64/linux.h b/include/grub/arm64/linux.h
> index 65796d9..20058f3 100644
> --- a/include/grub/arm64/linux.h
> +++ b/include/grub/arm64/linux.h
> @@ -43,10 +43,14 @@ struct grub_arm64_linux_kernel_header
> };
>
> /* Declare the functions for getting dtb and checking/booting image */
> -void *grub_linux_get_fdt (void);
> grub_err_t grub_arm64_uefi_check_image (struct grub_arm64_linux_kernel_header
> *lh);
> grub_err_t grub_arm64_uefi_boot_image (grub_addr_t addr, grub_size_t size,
> char *args);
>
> +/* Export the accessor functions for gettin dtb and "loaded" flag */
> +void EXPORT_FUNC (*grub_linux_get_fdt) (void);
> +int EXPORT_FUNC (grub_linux_get_loaded) (void);
> +void EXPORT_FUNC (grub_linux_set_loaded) (int loaded_flag);
> +
EXPORT_* are necessary only for core. Not for modules.
> #endif /* ! GRUB_LINUX_CPU_HEADER */
>
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 2/4] arm64: Add xen_boot module file
Committed without the xen_module command. Its argument parsing was
non-trivial and I don't quite get what its intent is. Can you resubmit?
On 23.07.2015 07:16, fu@linaro.org wrote:
> From: Fu Wei
>
> grub-core/loader/arm64/xen_boot.c
>
> - This adds support for the Xen boot on ARM specification for arm64.
> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm
> to load different binaries for xen boot;
> Introduce xen_module to load common or custom module for xen boot.
> - This Xen boot support is a separated module for aarch64,
> but reuse the existing code of devicetree in linux module.
>
> Signed-off-by: Fu Wei
> ---
> grub-core/Makefile.core.def | 7 +
> grub-core/loader/arm64/xen_boot.c | 685
> ++
> 2 files changed, 692 insertions(+)
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index a6101de..796f7e9 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -1648,6 +1648,13 @@ module = {
> };
>
> module = {
> + name = xen_boot;
> + common = lib/cmdline.c;
> + arm64 = loader/arm64/xen_boot.c;
> + enable = arm64;
> +};
> +
> +module = {
>name = linux;
>x86 = loader/i386/linux.c;
>xen = loader/i386/xen.c;
> diff --git a/grub-core/loader/arm64/xen_boot.c
> b/grub-core/loader/arm64/xen_boot.c
> new file mode 100644
> index 000..33a65dd
> --- /dev/null
> +++ b/grub-core/loader/arm64/xen_boot.c
> @@ -0,0 +1,685 @@
> +/*
> + * GRUB -- GRand Unified Bootloader
> + * Copyright (C) 2014 Free Software Foundation, Inc.
> + *
> + * GRUB is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * GRUB is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with GRUB. If not, see
Re: [edk2] [grub PATCH] efinet: disable MNP background polling
On 14.10.2015 17:39, Seth Goldberg wrote: > > >> On Oct 14, 2015, at 4:08 AM, Daniel Kiper wrote: >> >>> On Wed, Oct 14, 2015 at 05:19:32AM +, Ye, Ting wrote: >>> Hi all, >>> >>> If I understand the issue correctly, I don't quite agree that UEFI >>> spec is imprecise about SNP constraints described as following. >>> The "constraint" described here is that the grub should use attribute >>> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage >>> is clearly described in page 184, chapter 6.3 >>> EFI_BOOT_SERVICES.OpenProtocol(). >>> >>> EXCLUSIVEUsed by applications to gain exclusive access to a >>> protocol interface. >>>If any drivers have the protocol interface opened with an >>> attribute of BY_DRIVER, >>>then an attempt will be made to remove them by calling the >>> driver's Stop() function. >>> >>> The grub code should not assume that the SNP is not occupied by other >>> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to >>> be more precise, use OpenProtocolInformation() to check whether SNP is >>> already opened by other driver, then decide whether need to use EXCLUSIVE >>> to disconnect the other drivers. This is the typical usage for all UEFI >>> protocol, not particular constraints to SNP protocol. >> >> Looks good! Great! However, it looks that we still have a problem if somebody >> opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI >> spec. >> Sadly we do not have a control on other stuff and one day our approach may >> fail >> because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does >> it mean that migration to MNP is one sensible solution for our problems? As >> I know >> this is huge overhaul, so, we should think twice before choosing that way. > > >Then it is fortunate that when I wrote the MNP implementation that we ship > with Oracle Solaris 11.2, that I tested it on many thousands of systems as > well as on new UEFI implementations at the UEFI Plugfest ;). > Can you please point to the patch you used? I think the only sane solution judging from what I have read so far is to use MNP as far as possible and fallback to current code if MNP fails > --S > > > >> >> Daniel >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > . > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/3] ieee1275: ofdisk dangling pointer
On Mon, Oct 26, 2015 at 05:43:36PM -0400, Eric Snowberg wrote: > Within commit: 87ec3b7fa9061f470616ed927fc140e995831c00 - > "Don't continue to query block-size if disk doesn't have it.??? > a dangling pointer was introduced. > > Fix dangling pointer issue in grub_ofdisk_open where devpath is freed > and then used again within the call to grub_ofdisk_get_block_size. This > solves many memory corruption issues we were seeing. > > Signed-off-by: Eric Snowberg Please CC me too if you repost patches on grub-devel. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Be File System identified as bfs
> As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script > 83haiku to fail. > 12 befs|befs_be) debug "$partition is a BeFS partition" ;; Looks like this is a simple one-line change. befs|befs_be is a name used by old driver which had to be removed signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 3/4] * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64
> +if [ "x$machine" != xaarch64 ]; then > + multiboot_cmd="multiboot" > + module_linux_cmd="module" > + module_initrd_cmd="module --nounzip" > +else > + multiboot_cmd="xen_hypervisor" > + module_linux_cmd="xen_linux" > + module_initrd_cmd="xen_initrd" > +fi > + Please do not hardcode an assumption that grub-mkconfig is executed on the same machine as GRUB is booted. I know that we have instances of such assumption in some cases but we'd like to eliminate them. Alternatives: - Check arch on boot time - Check that new xen commands are supported (define a new feature) Please add xen_* aliases on x86 as well signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Plain dm-crypt
On 2015-10-29 08:49, Vladimir 'phcoder' Serbinenko wrote: -a already means "all". Having to indicate usb0 manually is already a proof that you have an unmarked cryptocontainer. Moreover this line exactly illustrates my point: what is usb0 depends on other plugged device and even his fast they are and may vary from boot to boot. I'm not quite convinced you can deny this line plausibly No, since I type the line in manually every time, it is not located anywhere for it to be discovered and need denying. I know my system very well. I know if I put one USB drive into a slot, it will be named (USB0). If I plug more than one USB drive into the system, I know what they will be named based on their physical locations. Look, you can't presume to know my setup better than I do and then try to convince me that I don't require this feature. I understand if it won't be included, but don't hold it out because you think people are too stupid to know how to use it, or worse, because you think people are too stupid to know that they don't need it. There are people who want this feature for good reasons and have the know-how to be able to utilize it. Why can't you just accept that? Chris On 2015-10-27 11:10, Vladimir 'phcoder' Serbinenko wrote: There are patches for it but they will not be integrated as plain dm-crypt has no advantages compared to LUKS and cannot be configured reliably when device names change as they have no UUID Le 27 oct. 2015 8:20 AM, a écrit : Hello; I apologize if this question has already been asked. A web search didn't turn anything up. Are there any plans to include plain dm-crypt support in a future version of grub? Thank you. Chris ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Be File System identified as bfs
29.10.2015 18:12, Vladimir 'φ-coder/phcoder' Serbinenko пишет: As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script 83haiku to fail. 12 befs|befs_be) debug "$partition is a BeFS partition" ;; Looks like this is a simple one-line change. befs|befs_be is a name used by old driver which had to be removed It still needs to handle case when grub-probe or grub-mount are not available and blkid returns befs. It is probably easier to map grub bfs to befs in 50mounted-tests, this avoids confusion with Linux bfs. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 3/4] * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64
29.10.2015 18:25, Vladimir 'φ-coder/phcoder' Serbinenko пишет: +if [ "x$machine" != xaarch64 ]; then + multiboot_cmd="multiboot" + module_linux_cmd="module" + module_initrd_cmd="module --nounzip" +else + multiboot_cmd="xen_hypervisor" + module_linux_cmd="xen_linux" + module_initrd_cmd="xen_initrd" +fi + Please do not hardcode an assumption that grub-mkconfig is executed on the same machine as GRUB is booted. I know that we have instances of such assumption in some cases but we'd like to eliminate them. Alternatives: - Check arch on boot time This makes it even more difficult for os-prober to parse grub.cfg. We need some alternative before going this route. - Check that new xen commands are supported (define a new feature) Please add xen_* aliases on x86 as well Yes, that's better. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Be File System identified as bfs
On 29 Oct 2015 8:51 pm, "Andrei Borzenkov" wrote: > > 29.10.2015 18:12, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > >> >>> As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script >>> 83haiku to fail. >>> >> 12 befs|befs_be) debug "$partition is a BeFS partition" ;; >> Looks like this is a simple one-line change. befs|befs_be is a name used >> by old driver which had to be removed >> >> > It still needs to handle case when grub-probe or grub-mount are not available and blkid returns befs. It is probably easier to map grub bfs to befs in 50mounted-tests, this avoids confusion with Linux bfs. > > Would work as well. In any case it seems that we agree that it's better to fix it on os-prober side. Then it's up to their maintainers to decide which way to go. I don't know their code will enough to have an opinion > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
