cross-distro

cross-distro@lists.linaro.org

1 participants
149 discussions

Fw: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states

by Wookey

This arrived on a few distro-specific lists, but it seems to me to be very much a cross-distro sort of problem. So reposting here to make people aware. There has been a fair amount of discussion following this initial mail and a more concrete and juristiction-agnostic proposal is promised. Take a look at, say https://lists.ubuntu.com/archives/ubuntu-devel/2026-March/thread.html#43515 to follow discussion so far. ----- Forwarded message from Aaron Rainbolt <arraybolt3(a)gmail.com> ----- From: Aaron Rainbolt <arraybolt3(a)gmail.com> Date: Sun, 1 Mar 2026 14:48:00 -0500 To: xdg(a)lists.freedesktop.org Cc: debian-devel(a)lists.debian.org, devel(a)lists.fedoraproject.org, ubuntu-devel(a)lists.ubuntu.com, debian-legal(a)lists.debian.org, legal(a)lists.fedoraproject.org, adrelanos(a)whonix.org Subject: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states List-Id: <debian-devel.lists.debian.org> Given that this is related to legal stuff, I should preface this by saying I am not a lawyer. Recently, a new law was passed in California that requires OS vendors to provide some limited info about a user's age via an API that application distribution websites and application stores can use. [1] Colorado seems to be working on a similar law. [2] The law will go into effect January 1, 2027, it is no longer a draft. I do quite a bit of work with an OS vendor (working with the Kicksecure [3] and Whonix [4] projects), and we aren't particularly interested in blocking everyone in California and Colorado from using our OSes, so we're currently looking into how to implement an API that will comply with the laws while also not being a privacy disaster. Given that other distributions are also investigating what to do with this, and the law requires us to make a "good faith effort to comply with [the] title, taking into consideration available technology", I figured it would be a good idea to bring the issue here. At its core, the law seems to require that an "operating system" (I'm guessing this would correspond to a Linux distribution, not an OS kernel or userland) request the user's age or date of birth at "account setup". The OS is also expected to allow users to set the user's age if they didn't already provide it (because the OS was installed before the law went into effect), and it needs to provide an API somewhere so that app stores and application distribution websites can ask the OS "what age bracket does this user fall into?" Four age brackets are defined, "< 13", ">= 13 and < 16", ">= 16 and < 18", and ">= 18". It looks like the API also needs to not provide more information than just the age bracket data. A bunch of stuff is left unclear (how to handle servers and other CLI-only installs, how to handle VMs, whether the law is even applicable if the primary user is over 18 since the law ridiculously defines a user as "a child" while also defining "a child" as anyone under the age of 18, etc.), but that's what we're given to deal with. The most intuitive place to put this functionality would be, IMO, AccountsService. The main issue with that is that stable-release distributions, and distributions based upon them, would be faced with the issue of how to get an updated version of AccountsService integrated into their software repositories, or how to backport the appropriate code. The law goes into effect on January 1, 2027, Debian Bookworm is going to be supported by ELTS until July 30, 2033, and we don't yet know if Debian will care enough about California's laws to want to backport a new feature in AccountsService into Debian Bookworm (or even Trixie). Distributions based on Debian (such as Kicksecure and Whonix) may still want to comply with the law though, so something using AccountsService-specific APIs would be frustrating. Requiring a whole separate daemon for the foreseeable future just for an age verification API would also be annoying. Another place the functionality could go is xdg-desktop-portal. This one is a bit non-ideal for a couple of reasons; for one, the easiest place to put the call would be in the Account portal, which returns more information than the account's age bracket. This could potentially be considered non-compliant with the law, as it states that the operating system shall "[s]end only the minimum amount of information necessary to comply with this title". This also comes with the backporting disadvantages of an AccountsService-based implementation. For this reason, I'd like to propose a "hybrid" approach; introduce a new standard D-Bus interface, `org.freedesktop.AgeVerification1`, that can be implemented by arbitrary applications as a distro sees fit. AccountsService could implement this API so that newer versions of distros will get the relevant features for free, while distros with an AccountsService too old to contain the feature can implement it themselves as a stop-gap solution. Taking inspiration from the File Manager D-Bus interface [5], I think something like the following might work: <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> <node name="/org/freedesktop/AgeVerification1"> <interface name="org.freedesktop.AgeVerification1"> <method name="SetAge"> <arg type="s" name="User" direction="in"/> <arg type="u" name="YearsOfAge" direction="in"/> </method> <method name="SetDateOfBirth"> <arg type="s" name="User" direction="in"/> <arg type="s" name="Date" direction="in"/> </method> <method name='GetAgeBracket'> <arg type="s" name="User" direction="in"/> <arg type="u" name="AgeBracket" direction="out"/> </method> </interface> </node> * The 'User' argument would, in all instances, be expected to be the UNIX account username of the user in question. This user account must not be a system account (i.e. its UID must fall between UID_MIN and UID_MAX as defined by /etc/login.defs). If a user is specified that does not exist or whose UID is out of range, these methods will return the error 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. If the specified user is not the same as the user making the method call, and the user making the method call is not root, these methods will return the error 'org.freedesktop.AgeVerification1.Error.PermissionDenied'. * The 'YearsOfAge' argument of the 'SetAge' method should be an unsigned integer specifying the age of the user in years at the time of the method call. (The law specifically allows providing simply an age value rather than a birth date if desired.) * The 'Date' argument of the 'SetDateOfBirth' method should be a string in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on which the user was born. If the argument is invalid, the method will return the error 'org.freedesktop.AgeVerification1.Error.InvalidDate'. * The 'AgeBracket' output argument of the 'GetAgeBracket' method will be an unsigned integer between 1 and 4 inclusive, where 1 indicates that the user is under 13 years old, 2 indicates that the user is at least 13 and under 16 years old, 3 indicates that the user is at least 16 and under 18 years old, and 4 indicates that the user is 18 years old or older. If no age has been configured for the user yet, the method will return the error 'org.freedesktop.AgeVerification1.Error.AgeUndefined'. I propose that the exact way in which age information is stored by the daemon should be left implementation-defined. For Kicksecure, the way we implement it will almost certainly store only the age bracket and require users to explicitly reconfigure their age once they are old enough to move from one age bracket to another. Other implementations may choose to store the date of birth or the age and date on which the age was set so that they can automatically update the age bracket as time passes. This interface will be provided *on the system bus* (NOT the session bus!), and the D-Bus service that provides these services should run as root. The file containing the user-to-age mappings should be owned by root and should not be world-readable, to prevent leaking the user's specific age to malicious applications. Some things I did think about when writing the above but ultimately decided to not propose: * Detailed permission gating for the 'GetAgeBracket' method. The only reason to do this would be for additional privacy, and privacy-conscious users can simply lie about their age or the age of the intended user. There isn't anything in the law (that I can tell) that prevents the user from just saying "I'm 18" when the prompt appears and going with it. This would also be really difficult to implement outside of the context of xdg-desktop-portal, and would probably only work with sandboxed apps if it was implemented that way. * UX for actually requesting the age from the user. IMO this is out of scope for FreeDesktop; individual distros should see to it that they prompt for the user's age or birth date at "account setup" (whatever that happens to be defined as for the distro in question), nudge the user to provide the information later on for existing installations, etc. Furthermore, this mechanism needs to work even on CLI-only installs and maybe even on server installs, depending on how one defines "general purpose computing device" (as specified by the law in question), so defining any specific UX is likely infeasible. (If this is required on servers, end-users will probably want to auto-provision the age information somehow, and specifying how to do that in a distribution-agnostic way is impossible given that Ubuntu uses cloud-init, Fedora uses Kickstart and Ignition, etc.) * Omitting the 'SetDateOfBirth' method. It can be lived without legally, but without the method, it becomes difficult for software that already records the user's date of birth to accurately implement automatic age bracket adjustment as time passes. This isn't a feature Kicksecure would use, but it's a feature some projects might be interested in. Thanks for taking a look at this. -- Aaron [1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=20252… [2] https://leg.colorado.gov/bill_files/110990/download [3] https://www.kicksecure.com/ [4] https://www.whonix.org/ [5] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/ ----- End forwarded message ----- Wookey -- Principal hats: Wookware, Debian http://wookware.org/ Matrix: @wookey:matrix.org

19 hours, 40 minutes

Are you trying to get back your lost wallet ? You need to be very careful

by elvisjimmy599＠gmail.com

I remember checking my wallet balance daily, feeling a mix of pride and relief. I’ve cracked the code to building real wealth. Then, without warning, the platform vanished. Wallet addresses went dead. Support channels disappeared, and my funds were gone in an instant. The emotional fallout was worse than the financial loss. Sleepless nights became the norm. Anxiety gnawed at me constantly. I replayed every decision in my head, blaming myself for being naive. I vowed never to trust anyone again, not influencers, not experts, not even my own judgment. But giving up wasn’t an option. I owed it to myself and to my future to fight back. So I began digging. I scoured Reddit threads, filed reports with blockchain analytics firms, and even contacted local authorities (though they offered little help). The more I searched, the more overwhelmed I became, lost in a labyrinth of technical jargon, dead ends, and predatory recovery services asking for upfront fees. Then, through a survivor’s forum, I stumbled upon WHISPERER HACKER RECOVERY. Skeptical but desperate, I reached out. What set them apart wasn’t just their expertise; it was their empathy. They didn’t make wild promises. Instead, they walked me through how crypto tracing works, what success looks like, and what realistic timelines are. No pressure. No false hope. Within weeks, their forensic team identified transaction trails linked to the scam wallet. Using on-chain analysis and coordination with exchanges, they flagged suspicious activity and initiated recovery protocols. It wasn’t magic, but it was methodical, transparent, and grounded in real blockchain intelligence. Today, I’m cautiously optimistic. While not all funds have been recovered yet, has already secured a significant portion and, more importantly, restored my sense of agency. I’m sleeping again. I’m healing. If you’ve been scammed, know this: you’re not alone, and you’re not foolish. Crypto fraud preys on hope, but that same hope can fuel your comeback. Don’t suffer in silence. I strongly advise you to get in touch with WHISPERER HACKER RECOVERY right away if you've fallen victim to a similar scam.via --WhatApp ; +44 (73 5 22, 191 25 Homepage>>whispershackerrecovery.com ....Mailbox;;info(a)whispershackerrecovery.com.

4 days, 20 hours

heads up regarding some v5.10 changes

by Ard Biesheuvel

Hello all, Just a note to whomever is subscribed to this list regarding some changes in v5.10 that may affect distros' kernel deployments: efivars ------- efivars is the ancient predecessor to efivarFs, that allows access to EFI variables via sysfs (but with some restrictions). This has been deprecated since before ARM even had UEFI support, and it is no longer going to be enabled going forward. EFI pstore has been rewritten to no longer rely on it, and on x86, the module is still available, but no longer gets loaded automatically. On !x86, it is no longer built at all. As far as I could figure out (and I did ask around as well), this is highly unlikely to regress anything, and on x86, the module can still be loaded manually if needed (or enabled as a builtin) deprecated crypto ----------------- Some crypto drivers have been made to depend on CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE, which is only available if the crypto AF_ALG socket API is enabled, as the algorithms are never used by the kernel itself. However, none of these ciphers are known to be relied upon by user space either (via AF_ALG), and so I strongly recommend the distros incorporate # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set into their v5.10+ kernel configs so that these deprecated algorithms are simply dropped from the build (the algos are arc4, tea, khazad, SEED and anubis, others may follow in the future, e.g., md4/5). Note that iwd/libell used to rely on the kernel's ecb(arc4) implementation, but this is no longer the case. kexec/kdump tools ----------- To make the kernel's PE/COFF header spec compliant, the stext symbol will be aligned to 64 KB regardless of the page size the kernel was built with. As far as I can tell looking at the debian source of the associated tooling, the symbol value of stext is used to infer the page size, so this will no longer work.

5 years, 4 months

AArch64 atomics, -moutline-atomics support in GCC

by Steve Capper

Hello cross-distro, I thought it a good idea to send an update on gcc support for LSE == Large System Extensions. These are a series of instructions introduced in Armv8.1 that allow one to atomically update values using a single instruction rather than as a sequence of: Load Exclusive + modify + store exclusive. This extension is optional, meaning that not all implementations support it. It has to be selected at runtime. As atomic operations are rather fundamental operations, existing mechanisms (such as ifunc resolvers) are not really suitable for runtime selection. glibc 2.28+ supports HWCAP_ATOMICS for runtime selection meaning .so's can be deployed in an "atomic" folder. The trouble with this approach is that it requires more building and testing work to deploy multiple .so's. Recently, in gcc 10, there is support for "-moutline-atomics". This flag prompts gcc to generate both exclusive monitor and LSE code for atomic operations and the pertinent routine is selected at runtime. The runtime selection process involves a conditional direct branch and has been found to only have a modest overhead. From gcc 10.1 upwards, -moutline-atomics is enabled by default (but can be disabled by -mno-outline-atomics) For those interested in backports of this functionality into older versions of gcc please see: GCC-8 aarch64: Add early clobber for aarch64_store_exclusive https://gcc.gnu.org/git?p=gcc.git;a=commit;h=512b0ffab3bc4f334cbb36c598192c… aarch64: Simplify LSE cas generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1bf932b1ab9002089ddd79d6453218… aarch64: Improve cas generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=369a4d6dd2df645f1870506d8dd6a5… aarch64: Improve swp generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5d8ff6f1ff2cef121dc33d954535fc… aarch64: Improve atomic-op lse generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=f557aa1a836377d49fdbd4e7cecb2e… aarch64: Remove early clobber from ATOMIC_LDOP scratch https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5497bc389dca6a992aaa063df30895… aarch64: Extend %R for integer registers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=c7ae64412b6c9c7b966f3c0ab8eaa5… aarch64: Implement TImode compare-and-swap https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1101198f3d099af0555d7202a2a00c… Aarch64: Fix shrinkwrapping interactions with atomics (PR92692) https://gcc.gnu.org/git?p=gcc.git;a=commit;h=0b65e477890b7fe7f47a3dd85975ab… aarch64: Tidy aarch64_split_compare_and_swap https://gcc.gnu.org/git?p=gcc.git;a=commit;h=eccc28184d58dc27232d6710dc44eb… aarch64: Add out-of-line functions for LSE atomics https://gcc.gnu.org/git?p=gcc.git;a=commit;h=06f8058a8368f79e2cbf4659db53b9… Add visibility to libfunc constructors https://gcc.gnu.org/git?p=gcc.git;a=commit;h=36579491fa01039694ad12e673ffe5… aarch64: Implement -moutline-atomics https://gcc.gnu.org/git?p=gcc.git;a=commit;h=ff54767725cd86e1d937cde50ec499… aarch64: Fix store-exclusive in load-operate LSE helpers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=4eaef24ba1f83ccfb54c9e473eb203… aarch64: Configure for sys/auxv.h in libgcc for lse-init.c https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5d44ad1e0a66651495ed964058cdd6… aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=163e0d03f2cdc80de4968c4be4694c… aarch64: Fix bootstrap with old binutils [PR93053] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=a69a60c4969cea06c1d44b5e3e4970… aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1dbd821ee74e6c234e61e25b0801a0… re PR target/90724 (ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve) https://gcc.gnu.org/git?p=gcc.git;a=commit;h=69472d76d2456a447f61bc539bd6fe… aarch64: Fix for PR target/94814 Backport of PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair https://gcc.gnu.org/git?p=gcc.git;a=commit;h=034dfe065033a846761b0a5c35fc86… aarch64: Force TImode values into even registers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=80c605c875fb394212164908151bf0… [AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0d2a937abf6ea0e03bfd7cb56c0f… GCC-9 aarch64: Extend %R for integer registers https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=Ea7ffe1da05df28c8dd5c1f5292b3… aarch64: Implement TImode compare-and-swap https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=53c1356515ac1357c341b59432696… [AArch64] Fix shrinkwrapping interactions with atomics (PR92692) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=Ea376dd471a3b006bc48945c1d9a2… aarch64: Tidy aarch64_split_compare_and_swap https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=43e46197c10daad6e0aee839c8526… aarch64: Add out-of-line functions for LSE atomics https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b36f6a808e5ce7484c1039458f2e3… aarch64: Implement -moutline-atomics https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9cf2784a69e126283c33fdbcfbf57… aarch64: Fix store-exclusive in load-operate LSE helpers https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bb9156ede009cfb572ab98c64288d… aarch64: Configure for sys/auxv.h in libgcc for lse-init.c https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c15ff4d0803ffd02fdb9147e82e88… aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=13f6d5ac48a7d55b41927849aeebc… aarch64: Fix bootstrap with old binutils [PR93053] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bfe912a35c0c39a623ba6e0066b60… aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=be64fc4cab7facee309447302b6ee… re PR target/90724 (ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=65709f4b93c74101440ab16bf4bdd… [AArch64] PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=470626394ab7779cb663258048da8… [AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b6dc99434abb6f5fa70ced8790bca… Cheers, -- Steve Capper IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

Bug on binutils 2.33 for aarch64 with A53 errata

by Guillaume Gardet

Hi, FYI, there is a bug on binutils 2.33 for aarch64 when --fix-cortex-a53-835769 and --fix-cortex-a53-843419 are used, which can lead to an invalid operation. The upstream bug report with a workaround is available at https://sourceware.org/bugzilla/show_bug.cgi?id=25210 Cheers, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 2 months

GRUB 2.04 release, armhf, stuff

by Leif Lindholm

Hi all, TL;DR, GRUB 2.04 is released, and the below is fixed in there, including one important bit for arm64. Around the dawn of time, I started working on a GRUB port to 32-bit ARM on UEFI. By the time we got to the linux loader, the EFI stub support was still being developed for the kernel - and the boot/runtime UEFI support wasn't merged yet. So I bodged up the existing loader I had put together for the GRUB U-Boot port to at least check it wasn't overwriting anything important, and put some info into the chosen node to tell Linux what it needed to do to boot in UEFI mode and that was that. UEFI on 32-bit ARM never took off, and hence the relevant GRUB port, but you could kind of use it with the bodged U-Boot loader. Then that mischievous scoundrel Alex Graf went and implemented some basic UEFI interfaces for U-Boot, and the long-buried sins of the past were brought to the surface for all to see. So, anyway, I had to provide a *real* linux loader for 32-bit ARM on UEFI, so I went and genericised the arm64 UEFI linux loader. Of course, this had some spectacular fallout in various parts of the GRUB source tree. Finally, this all got merged upstream in September 2018. However, the timing of the next GRUB release was not clear, so I set up a branch with the minimum amount of patches required to go on top of the Debian Buster 2.02 GRUB (so Debian wouldn't have to wait until 2021-22): https://git.linaro.org/people/leif.lindholm/grub.git/log/?h=debian-buster-a…. This roughly corresponds to cherry-picking upstream: a0e4ee533dc0c6a78ecc55e97ac0fb98755f7fe7 linux, efi, arm*, fdt: Break FDT extra allocation space out into a #define 9bfba354bbd9f1541b1e5593549809aa3e720992 loader/multiboot_mbi2: Use central copy of grub_efi_find_mmap_size() 9415914e0fb4d0e09f49431cfb591551bd20f63a loader/ia64/linux: Use central copy of grub_efi_find_mmap_size() ad2bebc6fc3d77e38294aaa824362a0851239703 loader/i386/linux: Use central copy of grub_efi_find_mmap_size() c79ebcd18cf3e208e9dda5e2ae008f76c92fe451 i386: Don't include lib/i386/reset.c in EFI builds a2f26adfef2fc8a7d7392c3704031df4624c67b0 efi: Restrict arm/arm64 linux loader initrd placement 77808dd66bda72ff14873bcd701ec25a0db1dfee arm: Delete unused efi support from loader/arm d0c070179d4d78c297364e41ece54fd7755c4b58 arm/efi: Switch to arm64 linux loader d24dd120864ed72a80d7bb9c0288c4f29934f79d arm64/linux/loader: Rename functions and macros and move to common headers bad144c60f664a83f5a7d3a014927bffaa2abbf1 efi: Add grub_efi_get_ram_base() function for arm64 8ec18d1a4c26129c0a018ee7a61739a929ee1a25 efi: Add central copy of grub_efi_find_mmap_size 9b37229f013db1b150082ac130be7c20b3db8cea commands/file: Use definitions from arm64/linux.h 40dc61ed75e08e7dc2951bdae5c59fecb15bbb72 commands/file: Use definitions from arm/linux.h 347210a5d5ce655b95315f320faa515afb723c11 efi/fdt: Set address/size cells to 2 for empty tree e93fd6b776a7e6cef36c445d00436e5a23cfeba5 fdt: Move prop_entry_size to fdt.h a244d9ebc7547f7ed373d9796a3bf186e7c035a1 arm: make linux.h safe to include for non-native builds cda033298680b6984044563b2ef6374a725b8aac arm: switch linux loader to linux_arm_kernel_header struct 7fd9722d0c5e9c5a85b782ef435c80085da308b2 arm64: align linux kernel magic macro naming with i386 ff1cf2548a3f33da19278829687d074ad746dd0a arm64: align linux kernel header struct naming with i386 7d36709d5e769eb49b41cca709bd64336b47ab4f i386: make struct linux_kernel_header architecture specific 3245f02d9d7274e942426541cf73dc73e7298f02 make GRUB_LINUX_MAGIC_SIGNATURE architecture-specific 8776e5a942582adaadc67865ed74cdd199e56a16 Make arch-specific linux.h include guards architecture unique 083c6e2455dcd4aafb6062d89fd6029dd3adddb6 arm64/efi: move EFI_PAGE definitions to efi/memory.h f826330683675f0deb55b58fd229afd7d65fb053 efi: change heap allocation type to GRUB_EFI_LOADER_CODE 91212e0aa07e704a61e4540c18a27f149f5e51c3 arm64 linux loader: improve type portability c5841ba7f0d14c193f20854e7e55b4f7ce9207d5 efi: Add GRUB_PE32_MAGIC definition 8c9465fac901caac6802d6872a1374518b001517 efi: move fdt helper library 4bc909bf89f5b4ff86c9e4e609d4fe0c11a66b0c Remove grub_efi_allocate_pages. dd5fde2df83c5c03b7ba04d2cc5b7be96de8da7b efi: refactor grub_efi_allocate_pages Additionally, I would strongly recommend cherry-picking the following two 2d55ffecbb966d3e42023729d8bbf3c21c59e049 configure: Disable arm movw/movt relocations for GCC 566b16a0dc23d72357d2d75b781d3c7895b8a234 arm64/efi: Fix grub_efi_get_ram_base() The latter sorts out a brainfart wreaking havoc on the arm64 port. But with that, both arm and arm64 actually respect the kernel's initrd placement rules (meaning you can actually boot on arm64 systems with tons of RAM, or large holes in the memory map). But as I said, GRUB 2.04 has been released, and if moving to that is an option, please do. My intent is to also bring RISC-V into the fold and use the same loader for all three. Anyway, if you got this far, have (another) cup of coffee. / Leif

6 years, 7 months

LuaJIT

by Andrew Wafaa

Hi All, Just as a heads up, there's a fork of LuJIT called unimaginatively LuaJIT2[0]. The progress of LuaJIT has been exceptionally slow, and getting patches merged has been difficult at best. This fork has numerous enhancements for both Arm and POWER. Regards, Andy 0 - https://github.com/openresty/luajit2

6 years, 7 months

Re: [edk2] [edk2-announce] ATTN: List Transition Begins Today

by Leif Lindholm

FYI: EDK2 development mailing list changing to devel(a)edk2.groups.io This will give us some better flexibility with regards to whitelisting non-subscribers and suchlike currently not possible through 01.org. On Wed, Apr 03, 2019 at 10:59:31AM -0500, stephano wrote: > tl;dr > If you're sending emails to this list, now would be a good time to switch > over to the new list: https://edk2.groups.io/g/devel > > > We will be transitioning to Groups.io today for our devel mailing list. At > some point today, this email will begin to bounce any incoming messages. > I'll be working on getting the archive of old emails uploaded to Groups.io. > When I have a timetable for the archives I'll update the new list. > > Cheers, > Stephano > _______________________________________________ > edk2-devel mailing list > edk2-devel(a)lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel

6 years, 11 months

shim crashes

by dann frazier

hey, Heads-up, while testing out arm64 SecureBoot in the QEMU virt model, I hit a couple bugs in shim that were causing it to crash: https://github.com/rhboot/shim/pull/173 https://github.com/rhboot/shim/pull/174 They are not arm64-specific, but happen to not escalate to crashes on x86 because of it's memory layout. -dann

6 years, 11 months

nouveau h/w acceleration is blacklisted by default in chromium 71+

by Ard Biesheuvel

Hello all, (cc'ing everybody who I think might care - please ignore if you don't) Chromium [as of 71] now defaults to software rendering when it detects the nouveau driver. This is bad for the ARM ecosystem, since it is the only driver we have for NVIDIA hardware, and it has fewer issues than AMD GPU drivers + hardware running on ARM systenms. https://lists.freedesktop.org/archives/nouveau/2019-January/031798.html It can be addressed by setting the 'ignore-gpu-blacklist' option, but this requires an explicit action from the user, which is unfortunate and undesirable. Is there any way we can influence this?

7 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro