[HN Gopher] Twitter Client for UEFI
___________________________________________________________________
Twitter Client for UEFI
Author : gslin
Score : 144 points
Date : 2022-03-12 13:46 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| loloquwowndueo wrote:
| If this allows me to use "latest tweets" chronological view as
| default instead of the brain dead "home" view I'm totally setting
| up a laptop with this. The official twitter clients are more
| atrocious each day (spaces? Home by default? 95% promoted tweets
| in my timeline? List suggestions I don't care about?)
| jeromegv wrote:
| There are quite a few third party client who work quite well.
| xcambar wrote:
| Please complete your answer ;)
| [deleted]
| ctxc wrote:
| Didn't know what UEFI was, so here it is:
|
| " UEFI and BIOS are low-level software that starts when you boot
| your PC before booting your operating system, but UEFI is a more
| modern solution, supporting larger hard drives, faster boot
| times, more security features, and--conveniently--graphics and
| mouse cursors.
|
| The UEFI/BIOS loads when your computer starts up, and the BIOS is
| responsible for waking up your computer's hardware components,
| ensures they're functioning properly, and then runs the
| bootloader that boots Windows or whatever other operating system
| you have installed.
|
| You can configure various settings in the BIOS setup screen.
| Settings like your computer's hardware configuration, system
| time, and boot order are located here.
|
| The BIOS goes through a POST, or Power-On Self Test, before
| booting your operating system. It checks to ensure your hardware
| configuration is valid and working properly."
|
| Source: https://www.howtogeek.com/56958/htg-explains-how-uefi-
| will-r...
| shrimp_emoji wrote:
| kube-system wrote:
| Apple was using the precursor to UEFI (EFI) back when most
| windows boxes were still booting using BIOS derived from a
| rip off of a 1980s IBM.
| rvz wrote:
| It's because 95% of people do not care or don't like playing
| around with their computers or accessing the UEFI menu for
| sys-admin, netbooting, recovery, ransomware development or
| building their PCs.
|
| Apple does the same thing without the spooky UEFI menus on
| PCs, called _' Internet Recovery'_ which is still using EFI
| and is just like how netbooting works; and that _' just
| works'_.
| monocasa wrote:
| The filevault unlock screen interestingly enough is an EFI
| application, carefully constructed to look like the normal
| login screen. It's probably the most used EFI app that
| normal users interact with.
| silisili wrote:
| Thanks for this. I had a generally good idea about this, but
| despite seeing the word for many years, never actually knew
| what POST stood for before this comment. I'm not even sure I
| knew that it was an acronym...
| ComputerGuru wrote:
| If you're interested in learning further, I wrote up
| everything in the "regular" (pre-UEFI) boot process here and
| have been told it's a very good crash course on how your PC
| boots up: https://neosmart.net/wiki/mbr-boot-process/
| saghm wrote:
| Yeah, I always assumed it meant "post" as in "after", and it
| meant "after starting up" or something
| _HMCB_ wrote:
| What would be the purpose of this? A no-GUI client that's loaded
| before the OS?
| hackettma wrote:
| This sounds like a perfect command and control setup for malware.
| belkarx wrote:
| Exactly. My first thought was bootkit as standalone C2 would
| not be that useful
| p_l wrote:
| It's not really a good option, however SMM mode could be (you'd
| need to figure how to do network calls, though). The only thing
| changed by UEFI in this case is unified interface to register
| SMM components (You can have UEFI system with no SMM).
| sva_ wrote:
| This made me wonder if somebody got Doom to run under UEFI, and
| sure enough:
|
| https://github.com/Cacodemon345/uefidoom/
| MaceOutWindu wrote:
| was about to comment this. Now I have to find ridiculous things
| to run on uefi.
| bonzini wrote:
| UEFI is like the ugly son of MS-DOS and Windows. Anything that
| can run under MS-DOS with a DOS extender can run under UEFI.
|
| A friend of mine ported QEMU in order to run x86 boot ROMs on
| ARM systems.
| hackmiester wrote:
| That's... so absurd but so genius.
| WaitWaitWha wrote:
| /s Gather around children. Let me tell you a story from long long
| time ago.
|
| Two one eyed giants, Intel and Microsoft got together and decided
| that they should be in control of your machine, not the other
| half giants, like AMI, Award,Phoenix, DTK, and even a full giant
| but nobody cared about her, IBM.
|
| So they convinced everyone there was no space on the BIOS any
| more, and they had to shift much of the code outside onto a boot
| device, usually an HDD. 'Think about all the speed and ability to
| update quickly' they said to the peasants, and the local
| magistrates in the form of media gobbled it up, and continue to
| spread this news. There were some peasants that freaked out,
| pointed out the problem, but quickly were shouted down and jeered
| at by the crowd. 'We want faster! Stop spreading misinformation.'
|
| And, the two giant indeed forced the development of EFI then
| UEFI. There is nothing Unified about it. But, guess what? That
| was not good enough either, because some peasants figured it out
| how to manipulate the UEFI, and the two giant didn't like that.
| So they went back to the half giants and discussed what to do.
|
| And, lo they came up with an brand new idea! What if we put all
| this information into a chip, and make it hard to read! We will
| call it, BIOS! For good measure, for peasants that want more
| power, we will even throw in another one, and we will call it
| Baseboard Management Controller, but we will let you call that
| all kinds of different names! To make it even more entertaining,
| in larger cities where peasants are promoted to the rank of
| "enterprise", some host board adapters will also run OSes
| themselves for the fun of it.
|
| And this is how we got to today. When your computer runs, the
| BIOS with a full OS can be running, next to it, the BMC with a
| full OS could be running, on top of the BIOS you can have UEFI
| running, the HBA OSes running, and finally your very safe and
| secure OS running.
|
| /story
|
| I have taken artistic liberty (like UEFI most often runs on the
| same CPU,while BMC & HBA run on their own, and such), but the
| gist is true.
|
| An enterprise class host can be running many fully functional
| OSes, potentially with full network stack. This is why "zero
| trust" network implementation is so important.
| Sophira wrote:
| > and finally your very safe and secure OS running.
|
| That's the one running on the Intel Management Engine, right?
| Or at least Intel would like to believe that's the case.
|
| Jokes aside, I may be missing something. The BIOS came _way_
| before UEFI did. What am I missing here?
| BitLit wrote:
| File this project under: the engineers were so preoccupied with
| whether or not they could, they didn't stop to think about if
| they should.
| amelius wrote:
| I'm impressed when they have VirtualBox or qemu running in UEFI,
| sandboxing my real OS.
| masklinn wrote:
| Why would you want qemu running _in_ UEFI, rather than have
| qemu booted from UEFI? (more specifically run qemu on xen
| booted from UEFI, I think is what you 'd want).
| jakogut wrote:
| Practically speaking, QEMU needs a lot of OS functionality,
| such as scheduling, threading, virtual memory, and network,
| disk, and filesystem drivers, to be able to function. Xen
| does have these, but so does Linux, and KVM just exposes
| hardware virtualization as a module from Linux.
| eatonphil wrote:
| Anyone have a favorite guide/blog post/whatever for getting
| started with UEFI applications?
| stjohnswarts wrote:
| Not a tutorial but good info and keywords
| https://www.intel.com/content/dam/develop/external/us/en/doc...
|
| Also this might be helpful:
| https://pete.akeo.ie/2015/01/easily-create-uefi-applications...
|
| and if you choose edk2: https://www.tianocore.org/
| nih0 wrote:
| this is the bloat free software that i need in my life
| secondcoming wrote:
| TIL: It's possible for UEFI code to access the internet. What
| could possibly go wrong?
| p_l wrote:
| How did you think netbooting support works?
|
| UEFI made it quite simpler by making it so that network cards
| only have to bring a driver in OPROM instead of whole stack as
| before, and this allowed important improvements into boot
| process (like HTTPS instead of TFTP)
| secondcoming wrote:
| I thought that was the Intel ME thing. I've actually never
| used netboot.
| dheera wrote:
| Wasn't it always possible? If it can boot a full-blown OS that
| can access the internet, it has to be able to access the
| internet on its own.
| [deleted]
| smw wrote:
| I think your logic is faulty here. There were BIOSes with no
| ip stack for many years that could boot OSes that did have
| the ability to access the internet.
|
| Also, it's possible to remove the ip stack from most UEFI
| implementations?
|
| Now, it does need a network stack if it's going to _boot_ the
| other OS from the network.
| selfhoster11 wrote:
| PXE boot has been supported since before UEFI was a thing.
| rvz wrote:
| > TIL: It's possible for UEFI code to access the internet.
|
| Quite surprising to see lots of tech-oriented users here
| finally discovering UEFI having access to the internet after
| years of even the basics like "Internet Recovery" being used on
| Apple Macs or even sysadmins using netbooting on diskless
| systems.
|
| There is always a IP/Net stack section in the UEFI menu on
| nearly every modern PC which gives you this hint, but it isn't
| useful for the 95% of users, except for sysadmins, recovery,
| security and even malware writers.
|
| > What could possibly go wrong?
|
| Indeed. A lot can go wrong. I bet someone will do a Wordle
| clone in UEFI next.
| lizardactivist wrote:
| I get the feeling UEFI can never be entirely secure with the set
| of functionality it offers and thus huge surface it is exposing.
|
| Call me crazy, but security means doing only what is necessary
| and no more, in particular in this early part of starting up a
| computer system.
| ______-_-______ wrote:
| UEFI needs ~complete access to the machine so it can initialize
| hardware devices and pass control to the OS (which also has
| ~complete control of the hardware). How do you think sandboxing
| it would work, practically?
| profile53 wrote:
| What's scary about UEFI is that it has both direct hardware
| access and a massive attack surface: GUI, Ethernet stack,
| occasionally an 802.11 stack, etc.
| blibble wrote:
| customers want to be able to boot their machines off the
| network
|
| this would be difficult without a network stack
|
| if you're so inclined: you can remove unneeded modules from
| your UEFI firmware
| Filligree wrote:
| > if you're so inclined: you can remove unneeded modules
| from your UEFI firmware
|
| I'll bite.
|
| How, concretely, do I do this? What's the procedure to
| follow? How can I get the new BIOS image signed, so my
| motherboard will accept it?
| blibble wrote:
| there are plenty of forums dedicated to this, here is a
| guide to do exactly what I described above:
| https://www.win-raid.com/t3061f16-Guide-How-to-extract-
| inser...
|
| they don't need to be signed
|
| or you can dig through the manufacturers official
| documentation (often accessible behind NDA)
|
| don't blame me if you brick your hardware
| bayindirh wrote:
| > this would be difficult without a network stack
|
| This was possible with Ethernet cards with boot ROMs for
| more than two decades. Network booting via UEFI is
| nothing new, nothing revolutionary.
|
| I've been installing fleets of servers with PCI ethernet
| cards w/ boot ROMs a decade before. Token ring systems
| were booting from network two decades before.
| blibble wrote:
| what's the difference between having the code running in
| ring0 in a ROM vs the code running in ring0 from UEFI?
| perryizgr8 wrote:
| There's a huge difference. The network card does not need
| unrestricted access to the entire system.
| p_l wrote:
| There's less unrestricted access with UEFI than with old-
| fashioned option rom, especially with how you can 1)
| prevent loading of an option rom by banning its signature
| 2) register override for the device.
|
| Also, now there's much less code in option rom, leading
| to much more coherent system. Yes, it is easier to
| attack, but so is any system where you can expect a
| standard ABI&API vs. one where you need to randomly poke
| things.
| blibble wrote:
| it has it because the code running from its ROM is
| running in ring0
|
| exactly the same as the UEFI
| ikiris wrote:
| You do know how DMA works right?
| bayindirh wrote:
| When a boot ROM fires (it was via INT19 IIRC), the boot
| ROM runs, terminates and leaves the system. The size is
| smaller, it's not persistent, and it can't communicate
| with anything on the OS.
|
| When booted from the ROM, it just downloads pxelinux.0
| binary in most cases, and transfers control to it, and
| just vanishes.
|
| The UEFI is persistently running at the background, has
| communication pipes with the OS (some of it is visible
| via /sys/firmware/efi), and has much larger surface like
| direct access to disks and network stack via drivers (it
| can directly read your files and work on them via proper
| FS driver modules).
|
| There's also at least one open source sound driver too
| (https://github.com/Goldfish64/AudioPkg), so it can
| listen to your environment if it wants, at least in
| theory.
| p_l wrote:
| UEFI is not persistent by itself - anything that is
| persistent was also persistent on BIOS-based systems. The
| only remaining elements of UEFI that are accessible after
| ExitBootServices() call (done by OS during boot) is
| interface to edit NVRAM variables and a way to register
| so-called "capsules" (used, for example, for firmware
| updates.)
| blibble wrote:
| > The UEFI is persistently running at the background, has
| communication pipes with the OS
|
| this isn't true, it ceases running once it transfers
| execution
|
| you're thinking of the SMM, which is something else
| entirely
| bonzini wrote:
| SMM is also part of the firmware, it is set up by UEFI.
| p_l wrote:
| UEFI provides an interface to register code that runs in
| SMM, true.
|
| SMM being a requirement is a side effect of x86 history
| and platform design, not UEFI (which doesn't actually
| require SMM).
| hackmiester wrote:
| I don't think SMM requires UEFI, either, actually... I
| believe there have been BIOSes that initialized SMM also.
| p_l wrote:
| Indeed. SMM exists because it was unfeasible to require
| the OS to provide necessary power management features at
| a time when running DOS and unmodified Win2.x and Win3.x
| were crucial features.
|
| Thus 386SL was born, with SMM mode so that the firmware
| could hijack DOS without being stopped by accidental
| modification of interrupt table.
|
| A bunch of stuff was later loaded into SMM for various
| reasons, both more and less benign. Turion X2 CPUs used
| SMM resident handler to synchronise cpus when going into
| deeper sleep levels (iirc C3 required the SMM handler, C1
| and C2 were doable without, but C1E required it as well)
| blibble wrote:
| yes, the UEFI initialises the machine such that it is in
| a state that it can boot
|
| that's it's job
|
| it's not the fault of the UEFI as a standard or
| implementation that your processor manufacturer chose to
| require the SMM to have its firmware loaded to boot
|
| the UEFI also isn't suddenly persistent because there are
| other devices inside the machine that had firmware loaded
| into them (would you say the UEFI is persistent because
| it uploaded new third-party supplied microcode into the
| CPU?)
| mwcampbell wrote:
| > There's also at least one open source sound driver too
|
| Looking on the bright side, that means the firmware can
| potentially also talk to you if you can't see the screen.
| dijit wrote:
| > if you're so inclined: you can remove unneeded modules
| from your UEFI firmware
|
| this is so disingenuous as to be offensive.
|
| I'm not saying you're wrong, but the practical options
| for replacing a UEFI BIOS are vanishingly small.
|
| Also: booting over the network is a feature of a smaller
| ROM on a network card, that ROM usually had a much
| smaller surface area and had to be explicitly called as a
| boot option.
|
| Given the people who care _most_ about network boot are
| people running servers: IPMI /iDRAC/iLO are much stronger
| options for initiating network boot.
| jamiek88 wrote:
| It's so easy to do. Literally unchecking boxes on a gui.
| p_l wrote:
| The ROMs on NICs had _huge_ attack surfaces, as each rom
| had to implement enough network stack from scratch. Not
| to mention how buggy they were.
|
| There's a very good reason why iPXE is so often used for
| chainloading and why it has support for directly
| replacing the option rom of the card.
| blibble wrote:
| > this is so disingenuous as to be offensive.
|
| > I'm not saying you're wrong, but the practical options
| for replacing a UEFI BIOS are vanishingly small.
|
| what? you can download a GUI editor, click remove on the
| modules you don't want and then save it
|
| https://www.trishtech.com/2017/12/uefitool-view-and-edit-
| uef...
|
| I've done it
| dijit wrote:
| Cool tool, didn't know it existed but there are so many
| variations on UEFI bios's that I can't help but feel it
| will not universally work, and it depends a lot on things
| being compartmentalised.
|
| I also draw your attention to:
|
| > UEFITool is only meant for the advanced users who have
| all the knowledge needed to modify the UEFI BIOS files.
| Because of you make any mistake and flash the faulty file
| to your motherboard, it can turn the motherboard into a
| dead brick.
|
| Which is more worrying when you look at what is presented
| (just a bunch of UUIDs). Not exactly usable for average
| person who wants to minimise the attack surface of their
| machine.
|
| Given that _average_ people aren't networking booting,
| wouldn't it be wiser to have it enableable? Instead of on
| by default.
| lmz wrote:
| On my consumer grade motherboards netboot and the UEFI
| network stack is off by default. Network access code is
| still there though for purposes like online update
| (manually done).
| dataflow wrote:
| Does it not need a digital signature or something?
| bayindirh wrote:
| We've past this point with Intel ME, AMD's counterpart, and
| UEFI being an embedded OS which can run arbitrary binaries with
| free pass to everything on the system, almost ~10 years ago.
|
| The processors and the platform is so complex now, even with a
| secure UEFI, there are many points into the system both with
| add-on cards and your Ethernet port and bowels of the platform
| which has many controllers with Ring -1 (and deeper) access,
| where Ring 0 is the OS kernel level access.
| khaledh wrote:
| As demonstrated by MoonBounce:
| https://securelist.com/moonbounce-the-dark-side-of-uefi-firm...
| dmix wrote:
| > Due to its emplacement on SPI flash which is located on the
| motherboard instead of the hard disk, the implant is capable
| of persisting in the system across disk formatting or
| replacement
|
| Lovely, so you'd have to reflash the firmware to fix it.
| p_l wrote:
| Was already the issue with BIOSes, in an era with much less
| interest in firmware security.
| stjohnswarts wrote:
| Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should.
| nine_k wrote:
| Now imagine a whole working set of software, and some encrypted
| storage, running in UEFI, while the "real OS" with some games and
| office apps is only loaded to plausibly deny the real use.
| mwcampbell wrote:
| Has anyone implemented audio output on a modern x64 machine under
| UEFI, e.g. using the typical Realtek on-board audio? If so, I'd
| like to get a GUI with a screen reader working under UEFI
| sometime, both for the challenge of getting into bare-metal
| programming, and because as far as I know, nobody has made a PC
| boot process and firmware setup UI (what we used to call BIOS
| setup) accessible to blind people.
| p_l wrote:
| It would be very interesting project, because UEFI also puts
| emphasis on unified UI stack - yes, you can do stupid bling
| setup interface still, but there's somewhat unified UI toolkit
| available + standardised ways to create configuration options
| for devices.
|
| This way, a screenreader could hook into the UI toolkit and
| provide a good interface.
| poisonborz wrote:
| See this project: https://github.com/Goldfish64/AudioPkg
| shabier wrote:
| My only question is; why? Don't get me wrong, it is cool, but do
| people actually use it?
| cpach wrote:
| As for why: Probably because it's a cool hack.
|
| Does anyone actually use it? Probably not.
___________________________________________________________________
(page generated 2022-03-12 23:00 UTC)