Podcasts about Microcode

DShield Traffic Analysis using ELK The "DShield SIEM" includes an ELK dashboard as part of the Honeypot. Learn how to find traffic of interest with this tool. https://isc.sans.edu/diary/DShield%20Traffic%20Analysis%20using%20ELK/31742 Zen and the Art of Microcode Hacking Google released details, including a proof of concept exploit, showing how to take advantage of the recently patched AMD microcode vulnerability https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking CVE-2024-56161 VIM Vulnerability An attacker may execute arbitrary code by tricking a user to open a crafted tar file in VIM https://github.com/vim/vim/security/advisories/GHSA-wfmf-8626-q3r3 Snil Mail Fake Ransom Note A copy cat group is impersonating ransomware actors. The group sends snail mail to company executives claiming to have stolen company data and threatening to leak it unless a payment is made. https://www.guidepointsecurity.com/blog/snail-mail-fail-fake-ransom-note-campaign-preys-on-fear/

Three Buddy Problem - Episode 34: We dig into the latest exploited Apple iPhone zero-day (USB Restricted Mode bypass), an AMD microcode flaw so serious it's not being fully disclosed, a barrage of Patch Tuesday updates, the helpless nature of trying to defend corporate networks, Russian threat actor movements, and fresh intel from Rapid7, Volexity, and Microsoft. Cast: Juan Andres Guerrero-Saade (https://twitter.com/juanandres_gs), Costin Raiu (https://twitter.com/craiu) and Ryan Naraine (https://twitter.com/ryanaraine).

Reminder: 7-Zip MoW The MoW must be added to any files extracted from ZIP or other compound file formats. 7-Zip does not do so by default unless you alter the default configuration. https://isc.sans.edu/diary/Reminder%3A%207-Zip%20%26%20MoW/31668 Apple Fixes 0-Day Apple released updates to iOS and iPadOS fixing a bypass for USB Restricted Mode. The vulnerability is already being exploited. https://support.apple.com/en-us/122174 AMD ZEN CPU Microcode Update An attacker is able to replace microcode on some AMD CPUs. This may alter how the CPUs function and Google released a PoC showing how it can be used to manipulate the random number generator. https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w Trimble Cityworks Exploited CISA added a recent Trimble Cityworks vulnerabliity to its list of exploited vulnerabilities. https://learn.assetlifecycle.trimble.com/i/1532182-cityworks-customer-communication-2025-02-06-docx/0? Google Tag Manager Skimmer Steals Credit Card Info Sucuri released a blog post with updates to the mage cart campaign. The latest version is injecting malicious code as part of the google tag manager / analytics code. https://blog.sucuri.net/2025/02/google-tag-manager-skimmer-steals-credit-card-info-from-magento-site.html

This episode is just over an hour, and probably a lot more exciting than the Ryzen 9000 launch, itself. Plus Josh had a really messy looking burger. You can't lose.We've got Intel microcode, AMD Ryzen 9k, when is an RTX 4070 a bit less ... it's a tight show. Recorded August 14, 2024.Timestamps:00:00 Intro03:27 Ryzen 9900X and 9950X performance22:28 No sign of new (rumored) RX 7000 SKUs24:04 Intel Battlemage engineering samples being tested27:21 Update your Intel microcode, but you have to use Intel defaults31:31 Those ai pins are being returned now, and they are e-waste36:14 New RTX 4070 variant with slower GDDR637:55 (in)Security Corner50:40 Gaming Quick Hits54:51 Picks of the Week1:04:58 Outro ★ Support this podcast on Patreon ★

On today's show we get another 2024 Season 4 update, find out who grabbed their first eNASCAR Coke Series win, see if Intel is addressing the Microcode issue, find out where we spent my money, wonder if you have the right mindset to race, tell you where iRacing is in the world and have you figured out what your career incident points are? So sit back, relax and join us on the iRacers Lounge Podcast. iRacers Lounge Podcast is available on iTunes and Apple's Podcasts app, Stitcher, TuneIn, Google Play Music, Spotify, Soundcloud, Podbean, Spreaker, Podbay, PodFanatic, Overcast, Amazon, and other podcast players. Sponsors: Hosts: Mike Ellis – twitter.com/MikeDeanEllis David Hall – www.twitch.tv/mixmage Greg Hecktus – twitter.com/froozenkaktus – www.twitch.tv/froozenkaktus Brian Maccubbin – www.twitch.tv/MacRubbinsRacin Kyle Pendygraft – twitter.com/LoudPedalGaming Tony Rochette – twitter.com/TonyRochette Tom Dreiling – Donnie Spiker – twitter.com/Spikerman19 Bobby Jonas – MacKenzie Stevens – https://twitter.com/MackStevens48 Justin Pearson – https://twitter.com/big7bang_ John Kerley – Brad Wrenn – https://twitter.com/bradwrenn Links: Facebook – www.facebook.com/iRacersLounge/ Twitter – twitter.com/iracerslounge Instagram – instagram.com/iracersloungepodcast/ Web (Show Notes) – iracerslounge.com/

We discuss the latest Zen 5 releases & discuss what's going wrong with Intel's Royal Core project. [SPON: Get 10% off Tasty Vite Ramen with code BROKENSILICON: https://bit.ly/3wKx6v1 ] [SPON: Use "brokensilicon“ at CDKeyOffer to get Win 11 Pro for $23: https://www.cdkeyoffer.com/cko/Moore11 ] 0:00 Growing Pains & YouTube Shorts (Intro Banter) 3:48 Microcode Distribution, Zen 5 Geomeans (Corrections) 6:17 R7 9700X & R5 9600X Release to Polarizing Reviews 20:58 Zen 5 Utilization & Pricing 33:12 Will Zen 6 be on AM5? WTF is up with 800 Series Mobos? 35:33 5900XT & 5800XT Reviews 40:12 Strix Power Scaling & AMD Kraken Whispers 48:54 Intel Reports Disastrous Q2 2024 Earnings 1:01:43 Beast Lake is Cancelled & Nova Lake is in TROUBLE 1:05:55 Intel 0x129 Microcode Update Tested 1:13:31 Nvidia Blackwell (is not) Delayed due to Design Flaws 1:16:08 Rogue River Forest, Lunar Lake Release Date, RDNA 4 Incoming (Wrap-Up) 1:27:34 GPU market Demands, GDDR6 RTX 5000 Variants, AI Cadence (Final RM) https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/loading-microcode-os.html https://www.techspot.com/review/2877-amd-ryzen-7-9700x/ https://www.techspot.com/review/2878-amd-ryzen-5-9600x/ https://www.tomshardware.com/pc-components/cpus/amd-ryzen-5-9600x-cpu-review https://www.phoronix.com/review/ryzen-9600x-9700x https://www.techpowerup.com/review/amd-ryzen-9-9700x-performance-smt-disabled/ https://www.tomshardware.com/pc-components/cpus/amds-ryzen-9-5900xt-ryzen-7-5800xt-launch-today-for-dollar349-and-dollar249-respectively-existing-ryzen-5000-is-less-expensive https://www.youtube.com/watch?v=11FWyDiT8bE https://www.youtube.com/watch?v=24x_EE_zN2o https://youtu.be/WyRb1rOZytw?si=ZQKhReOQthTHUVEz https://www.intc.com/financial-info https://www.youtube.com/watch?v=b6vQlvefGxk https://www.reuters.com/legal/intel-is-sued-by-shareholders-alleging-securities-fraud-2024-08-07/ https://youtube.com/live/igDHiEbKGwY?feature=share https://youtu.be/1bEv74JrHQo?si=sY7evVyoCwq8YhCl https://www.phoronix.com/review/intel-raptor-lake-0x129 https://youtu.be/SMballFEmhs?si=ZM615s6YtJS0k_V2 https://x.com/mooreslawisdead/status/1820735159085277494 https://www.semianalysis.com/p/nvidias-blackwell-reworked-shipment https://www.tomshardware.com/pc-components/gpus/nvidia-reportedly-selects-intel-foundry-services-for-chip-packaging-production-could-produce-over-300000-h100-gpus-per-month https://x.com/OneRaichu/status/1822671710015131772 https://www.pcmag.com/news/amid-layoffs-and-cpu-controversy-intel-postpones-innovation-event https://www.pcgamer.com/hardware/graphics-cards/nvidias-reportedly-scaling-back-rtx-40-series-production-by-as-much-as-50-in-preparation-for-the-blackwell-rtx-50-launch/ https://www.reuters.com/technology/nvidia-faces-us-doj-probe-over-complaints-rivals-information-reports-2024-08-02/ https://videocardz.com/newz/nvidia-geforce-rtx-4090d-with-48gb-and-rtx-4080-super-32gb-now-offered-in-china-for-cloud-computing https://www.gamesindustry.biz/xbox-one-update-failure-raises-awkward-questions-about-the-future-prospects-of-console-hardware https://videocardz.com/newz/sk-hynix-confirms-gddr7-memory-will-enter-mass-production-in-third-quarter https://videocardz.com/newz/intel-core-ultra-200v-lunar-lake-launches-september-3rd https://www.tweaktown.com/news/99792/amd-is-hosting-mysterious-gamescom-event-on-august-23-new-radeon-announcement-coming/index.html https://steamdeckhq.com/news/new-steamos-beta-update-desktop-image/

Join The Full Nerd gang as they talk about the latest PC building news. In this episode the gang covers the Ryzen 5 7600X & Ryzen 7 9700X reviews and discussions, the arrived of Intel's microcode patch, and more. And of course we answer your questions live! Links: - PCWorld's Ryzen 9000 review - https://www.youtube.com/live/MxOL56hjXW4?si=R6MLwi7gk8Tth6cg - Intel microcode fix - https://www.pcworld.com/article/2422028/first-bios-fixes-for-crashing-intel-processors-rolling-out.html Join the PC related discussions and ask us questions on Discord: https://discord.gg/SGPRSy7 Follow the crew on X: @GordonUng @BradChacos @MorphingBall @AdamPMurray ============= Follow PCWorld! Website: http://www.pcworld.com X: https://www.x.com/pcworld =============

Timestamps: 0:00 you should know this 0:09 Windows "Downdate" attacks 1:14 Apple's new EU app linking fees 2:28 Intel microcode patch update 4:33 QUICK BITS 4:40 GPT-4o impersonated testers' voice 5:38 SteamOS beta hints at general install 6:25 0.0.0.0 Day vulnerability patched 7:06 3 BILLION people's data exposed? 7:41 Solving fusion energy with mayonnaise News Sources: https://lmg.gg/N429n Learn more about your ad choices. Visit megaphone.fm/adchoices

Intel knickt ein. Nachdem das Unternehmen zuletzt einräumte, dass es bei aktuellen Prozessoren in der Vergangenheit Fertigungsprobleme gab und ein Fehler im Microcode für noch mehr Kopfzerbrechen bei den Kunden sorgt, hat sich der Konzern dazu entschlossen, die Garantie der betroffenen Prozessoren zu verlängern.

Join The Full Nerd gang as they talk about the latest PC hardware topics. In this episode the gang covers the AM5+ socket potentially showing up in microcode (and why you shouldn't freak out), the newly announced PCIe 7.0 spec, Qualcomm's latest Snapdragon X push, and more. And as always we answer your questions live! References: - https://www.pcworld.com/article/2284554/qualcomm-says-snapdragon-x-elite-kicks-intel-core-ultras-butt-too.html - https://www.tomshardware.com/pc-components/cpus/amd-may-have-a-new-platform-for-upcoming-ryzen-cpus - https://www.pcworld.com/article/2287853/pcie-7-0s-first-draft-could-arrive-in-2025-at-up-to-512gb-s.html Join the PC related discussions and ask us questions on Discord: https://discord.gg/SGPRSy7 Follow the crew on Twitter: @GordonUng @BradChacos @MorphingBall @AdamPMurray Follow PCWorld for all things PC! ------------------------------­---- SUBSCRIBE: http://www.youtube.com/subscription_center?add_user=PCWorldVideos TWITTER: https://www.twitter.com/pcworld WEBSITE: http://www.pcworld.com

Join The Full Nerd gang as they talk about the latest PC hardware topics. In this episode the gang covers Adam's time with the newest handheld gaming computer, the Asus ROG Ally, and how it compares to Valve's Steam Deck, updates to the Asus AMD motherboard situation, Intel's latest microcode update scare, and of course we answer your questions live! Buy The Full Nerd merch: https://crowdmade.com/collections/pcworld Join the PC related discussions and ask us questions on Discord: https://discord.gg/SGPRSy7 Follow the crew on Twitter: @GordonUng @BradChacos @MorphingBall @KeithPlaysPC @AdamPMurray Follow PCWorld for all things PC! ------------------------------­---- SUBSCRIBE: http://www.youtube.com/subscription_center?add_user=PCWorldVideos TWITCH: https://www.twitch.tv/PCWorldUS TWITTER: https://www.twitter.com/pcworld

In den Online-Nachrichten berichtet Achim Killer über Sicherheits-Updates. MacOS, iOS und Google's Browser Chrome brauchen dringend welche. Die gegen Prozessor-Bugs kommen meist automatisch per Betriebssystem-Update.

Rynek PC jest spadkobiercą 40 lat rozwoju który bardzo silnie związał użytkowników z “oprogramowaniem układowym”, którego nie sposób się pozbyć. Od BIOS po UEFI na binarnych fragmentach FW urządzeń peryferyjnych skończywszy, zawsze gdzieś w systemie czyha potencjalny cichy intruz.Nasuwają się więc pytania: “Czy jesteśmy skazani na Firmware”? Czy producenci sprzętu tworzą tajną lożę i chcą zawładnąć światem poprzez szpiegowanie nieświadomych użytkowników? W czyim interesie jest zaszywanie w krzemie instrukcji procesora weryfikujących podpis cyfrowy oprogramowania? Na te i podobne pytania postaramy się odpowiedzieć w tym odcinku podcastu Poziom Niżej.Prowadzący: Radosław Biernacki, Marcin Wojtas, Jan DąbrośHashtag: acpi, bios, coreboot, firmware, secureboot, uefi### Plan odcinka# 00:00 - Wprowadzenie# 04:56 - Czym jest firmware# 10:33 - Trochę historii - BIOS# 17:43 - Czas obecny - UEFI# 22:50 - EDK2# 28:30 - CSM - czyli UEFI potrafi w BIOS# 29:50 - Coreboot - KISS# 31:05 - Libreboot# 33:30 - Bootloader, czyli co następuje po…# 35:45 - RaspberryPi jako beneficjent otwartego firmware# 38:35 - Bootrom - czyli jak uruchamiają się nowoczesne procesory# 42:40 - Detale wczesnych etapów uruchomienia systemu# 45:40 - Microcode# 48:00 - Inicjalizacja (trening) RAM# 52:12 - Bootloader# 56:40 - Skąd firmware bierze sterowniki? (OptionROM)# 1:01:30 - Jak ładowany i uruchamiany jest kod kernela?# 1:03:18 - Dlaczego kelnerowi potrzebny jest opis sprzętu i środowiska?# 1:05:28 - Jak dokonywane są aktualizacje firmware?# 1:09:55 - ACPI# 1:17:25 - DeviceTree i “sprawa ARM”# 1:21:32 - System Management BIOS (SMBIOS)# 1:23:10 - Bezpieczeństwo, zaufanie i prywatność# 1:26:10 - SecureBoot i VerifiedBoot# 1:31:45 - TPM# 1:35:50 - Podsumowanie# 1:39:25 - Bonus ### Linki do materiałów dodatkowych:# 22:55 - Specyfikacja UEFI - https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf# 23:19 - Repozytorium EDK2 - https://github.com/tianocore/edk2# 27:07 - Implementacja "UEFI runtime services" w u-boot - https://source.denx.de/u-boot/u-boot/-/blob/master/lib/efi_loader/efi_runtime.c# 30:18 - Repozytorium i strona główna coreboot - https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master, https://www.coreboot.org/# 31:13 - Strona główna libreboot - https://libreboot.org/# 31:35 - Repozytorium FSP - https://github.com/intel/FSP# 33:14 - Repozytorium oreboot - https://github.com/oreboot/oreboot# 35:15 - Strona główna i repozytorium LinuxBoot - https://www.linuxboot.org/, https://github.com/linuxboot/linuxboot# 44:05 - IME - https://en.wikipedia.org/wiki/Intel_Management_Engine# 49:17 - Więcej o SPD(Serial Presence Detect) - https://en.wikipedia.org/wiki/Serial_presence_detect# 59:16 - 1:01:30 - Sterownik do uruchamiania instrukcji x86 na AArch64 https://github.com/ardbiesheuvel/X86EmulatorPkg# 1:04:23 - Opis "runtime services" w specyfikacji UEFI: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#page=308# 1:05:06 - Opis "EFI system table": https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#page=168# 1:11:46 - link do kernel.org i arch/arm/mach*: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm?h=master# 1:14:30 - Specyfikacja ACPI i główne koncepty: https://uefi.org/specs/ACPI/6.4/index.html + https://uefi.org/specs/ACPI/6.4/03_ACPI_Concepts/ACPI_Concepts.html#acpi-concepts# 1:15:20 - Specyfikacja AML: https://uefi.org/specs/ACPI/6.4/20_AML_Specification/AML_Specification.html# 1:21:40 - Specyfikacja SMBIOS - https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.6.0.pdf# 1:29:50 - Podcast Poziom Niżej #006 - "Bezpieczeństwo w krzemie zaklęte" - https://www.youtube.com/watch?v=kqaeyaH8jFs# 1:31:45 - Wpis dotyczący ataku na komunikacją SPI pomiędzy CPU a TPM - https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network

In this episode: C++, 8220, HeatDeath, Microsoft, Okta, Candiru, Intel as well as all the show wrap-ups from this week on the Security Weekly News! Visit https://www.securityweekly.com/swn for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/swn225

In this episode: C++, 8220, HeatDeath, Microsoft, Okta, Candiru, Intel as well as all the show wrap-ups from this week on the Security Weekly News! Visit https://www.securityweekly.com/swn for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/swn225

In this episode: C++, 8220, HeatDeath, Microsoft, Okta, Candiru, Intel as well as all the show wrap-ups from this week on the Security Weekly News!   Visit https://www.securityweekly.com/swn for all the latest episodes! Show Notes: https://securityweekly.com/swn225

The next generation of cybersecurity is here, and it's coming in the form of self-protecting data. Because of ransomware and all these threats that attack your sensitive data on a regular basis, something had to change to plug all the holes hackers found in your security system. So how does Keyavi stop hackers with a security system that doesn't focus on protecting your entire system? Jack Russo finds out from John Ferraro how giving the data the ability to protect itself resulted in a more superior data security model.

Wie zu erwarten war, hat Apple vergangene Woche im Rahmen der WWDC 2020 einen Architekturwechsel bekannt gegeben. Nach 15 Jahren geht der Konzern zurück zu ARM Prozessoren, diesmal aus eigenem Hause, und lässt Intel zurück. Warum? Hier ein paar Gründe. In der vergangenen Woche erhielt ich unzählige Fragen warum Apple eigentlich Intel den Rücken kehrt. Die Partnerschaft sei über 15 Jahre gut verlaufen, das hatte ich ja auch in einer Podcastfolge neulich dargestellt. Das mag grundsätzlich stimmen, es bröckelte aber durchaus seit Jahren. Die mangelnde Performance Den Hauptgrund haben wir hier bereits oft besprochen: Intels Fortschritte in die letzten Jahren waren marginal. Mittlerweile deklassiert AMD die Prozessoren von Intel in vielen Kategorien. Apple hat Handlungsbedarf - und der Schritt auf die eigenen Chips bringt Unabhängigkeit und ein Produkt, dass nicht mehr so einfach verglichen werden kann. In Sachen Komfort und Plattformunabhängigkeit bringt das für Kunden natürlich auch Nachteile. Nein zum iPhone Es gab in der letzten Woche viele Berichte rund um die Lage zwischen Apple und Intel, meiner Meinung nach wird dabei ein Punkt immer wieder vergessen. Steve Jobs schien Intel durchaus als Hardwarepartner für das iPhone an Bord holen zu wollen, die Verhandlungen sind offenbar gescheitert. So kaufte Apple PA Semi und stieg so in die Produktion eigener Chips ein. Was kam? Ist eine einzige Erfolgsgeschichte - Mit seinen Smartphoneprozessoren dominiert Apple den Markt. Skylake als Problem Einem neuen Interview zu Folge soll vor allem Skylake enorme Probleme gehabt haben. Apple soll in der Architektur extrem viele Bugs gefunden haben, die per Microcode ausgebügelt wurden. Damit hatte der Konzern enormen Aufwand. Und was 10% für Intel heißen Am Ende verliert Intel keinen besonders großen Kunden, die Anteile von Apple am Markt der Heimcomputer sind gering. Zudem bedient Intel deutlich andere Bereiche, wie den Servermarkt, wo Apple simpel keine Rolle spielt. Dennoch ist es ein großer Kunde mit Prestige - und es bleibt abzuwarten wie Apple sich im Segment der Prozessoren etabliert. Der Ruf nach ARM Prozessoren auch in anderen Systemen könnte lauter werden. ----- Wenn euch dieser Podcast gefallen hat, würden wir uns freuen, wenn ihr Apfeltalk unterstützen würdet. Einerseits könnt ihr uns auf iTunes bewerten – damit erhöht sich die Sichtbarkeit dieses Podcasts – oder uns andererseits auf Steady unterstützen. Förderer auf Steady erhalten die Apfeltalk SE sowie die Film und Serien Folgen immer bereits am Sonntag, alle anderen Hörer am Freitag. Außerdem sind alle Folgen werbefrei und ihr bekommt Zugriff auf unsere wöchentliche News-Zusammenfassung. Empfehlt uns auch gerne euren Freunden!

Bypassing macOS Synthetic Click Protection https://www.wired.com/story/apple-macos-bug-synthetic-clicks/ Intel Microcode Updates for Older Windows 10 Versions https://support.microsoft.com/en-us/help/4494454/kb4494454-intel-microcode-updates Fake AntiVirus Adds in Microsoft Games https://answers.microsoft.com/en-us/windows/forum/all/malvertising-attack-on-microsoft-games/ced7ab87-7e0e-422b-97b7-fbfaed2b68a0 GandGrab Shutting Down https://www.zdnet.com/article/gandcrab-ransomware-operation-says-its-shutting-down/

Bypassing macOS Synthetic Click Protection https://www.wired.com/story/apple-macos-bug-synthetic-clicks/ Intel Microcode Updates for Older Windows 10 Versions https://support.microsoft.com/en-us/help/4494454/kb4494454-intel-microcode-updates Fake AntiVirus Adds in Microsoft Games https://answers.microsoft.com/en-us/windows/forum/all/malvertising-attack-on-microsoft-games/ced7ab87-7e0e-422b-97b7-fbfaed2b68a0 GandGrab Shutting Down https://www.zdnet.com/article/gandcrab-ransomware-operation-says-its-shutting-down/

Lesley Carhart is the Principal Threat Analyst at Dragos Inc.. Lesley has been performing digital forensics and incident response on unconventional systems and advanced adversary attacks for over a decade. Lesley will be discussing her transition from IT security to OT security, DFIR in ICS - What is it like doing forensics in this environment? Firmware? Micro-code?, and much more! Full Show Notes: https://wiki.securityweekly.com/Episode603 Follow us on Twitter: https://www.twitter.com/securityweekly

Lesley Carhart is the Principal Threat Analyst at Dragos Inc.. Lesley has been performing digital forensics and incident response on unconventional systems and advanced adversary attacks for over a decade. Lesley will be discussing her transition from IT security to OT security, DFIR in ICS - What is it like doing forensics in this environment? Firmware? Micro-code?, and much more! Full Show Notes: https://wiki.securityweekly.com/Episode603 Follow us on Twitter: https://www.twitter.com/securityweekly

Google BGP Hijack via Russia https://twitter.com/thousandeyes/status/1062102171506765825 https://www.wsj.com/articles/google-internet-traffic-is-briefly-misdirected-through-russia-china-1542068392 Microcode Bootloader USB https://www.techpowerup.com/forums/threads/intel-microcode-boot-loader.248858/ Wordpress GDPR Tool Vulnerable https://www.wordfence.com/blog/2018/11/trends-following-vulnerability-in-wp-gdpr-compliance-plugin/

Google BGP Hijack via Russia https://twitter.com/thousandeyes/status/1062102171506765825 https://www.wsj.com/articles/google-internet-traffic-is-briefly-misdirected-through-russia-china-1542068392 Microcode Bootloader USB https://www.techpowerup.com/forums/threads/intel-microcode-boot-loader.248858/ Wordpress GDPR Tool Vulnerable https://www.wordfence.com/blog/2018/11/trends-following-vulnerability-in-wp-gdpr-compliance-plugin/

Some massive free software milestones this week, Intel's Microcode benchmark snafu, and Windows games for Steam on Linux confirmed, so we give it a test.

Some massive free software milestones this week, Intel's Microcode benchmark snafu, and Windows games for Steam on Linux confirmed, so we give it a test. Plus Venezuela ties its currency to a cryptocoin, and our reaction to Windows 95 getting stuffed inside an Electron app.

Some massive free software milestones this week, Intel's Microcode benchmark snafu, and Windows games for Steam on Linux confirmed, so we give it a test. Plus Venezuela ties its currency to a cryptocoin, and our reaction to Windows 95 getting stuffed inside an Electron app.

Some massive free software milestones this week, Intel's Microcode benchmark snafu, and Windows games for Steam on Linux confirmed, so we give it a test. Plus Venezuela ties its currency to a cryptocoin, and our reaction to Windows 95 getting stuffed inside an Electron app.

FreeBSD internship learnings, exciting developments coming to FreeBSD, running FreeNAS on DigitalOcean, Network Manager control for OpenBSD, OpenZFS User Conference Videos are here and batch editing files with ed. Headlines What I learned during my FreeBSD intership Hi, my name is Mitchell Horne. I am a computer engineering student at the University of Waterloo, currently in my third year of studies, and fortunate to have been one of the FreeBSD Foundation’s co-op students this past term (January to April). During this time I worked under Ed Maste, in the Foundation’s small Kitchener office, along with another co-op student Arshan Khanifar. My term has now come to an end, and so I’d like to share a little bit about my experience as a newcomer to FreeBSD and open-source development. I’ll begin with some quick background — and a small admission of guilt. I have been an open-source user for a large part of my life. When I was a teenager I started playing around with Linux, which opened my eyes to the wider world of free software. Other than some small contributions to GNOME, my experience has been mostly as an end user; however, the value of these projects and the open-source philosophy was not lost on me, and is most of what motivated my interest in this position. Before beginning this term I had no personal experience with any of the BSDs, although I knew of their existence and was extremely excited to receive the position. I knew it would be a great opportunity for growth, but I must confess that my naivety about FreeBSD caused me to make the silent assumption that this would be a form of compromise — a stepping stone that would eventually allow me to work on open-source projects that are somehow “greater” or more “legitimate”. After four months spent immersed in this project I have learned how it operates, witnessed its community, and learned about its history. I am happy to admit that I was completely mistaken. Saying it now seems obvious, but FreeBSD is a project with its own distinct uses, goals, and identity. For many there may exist no greater opportunity than to work on FreeBSD full time, and with what I know now I would have a hard time coming up with a project that is more “legitimate”. What I Liked In all cases, the work I submitted this term was reviewed by no less than two people before being committed. The feedback and criticism I received was always both constructive and to the point, and it commented on everything from high-level ideas to small style issues. I appreciate having these thorough reviews in place, since I believe it ultimately encourages people to accept only their best work. It is indicative of the high quality that already exists within every aspect of this project, and this commitment to quality is something that should continue to be honored as a core value. As I’ve discovered in some of my previous work terms, it is all too easy cut corners in the name of a deadline or changing priorities, but the fact that FreeBSD doesn’t need to make these types of compromises is a testament to the power of free software. It’s a small thing, but the quality and completeness of the FreeBSD documentation was hugely helpful throughout my term. Everything you might need to know about utilities, library functions, the kernel, and more can be found in a man page; and the handbook is a great resource as both an introduction to the operating system and a reference. I only wish I had taken some time earlier in the term to explore the different documents more thoroughly, as they cover a wide range of interesting and useful topics. The effort people put into writing and maintaining FreeBSD’s documentation is easy to overlook, but its value cannot be overstated. What I Learned Although there was a lot I enjoyed, there were certainly many struggles I faced throughout the term, and lessons to be learned from them. I expect that some of issues I faced may be specific to FreeBSD, while others may be common to open-source projects in general. I don’t have enough experience to speculate on which is which, so I will leave this to the reader. The first lesson can be summed up simply: you have to advocate for your own work. FreeBSD is made up in large part by volunteer efforts, and in many cases there is more work to go around than people available to do it. A consequence of this is that there will not be anybody there to check up on you. Even in my position where I actually had a direct supervisor, Ed often had his plate full with so many other things that the responsibility to find someone to look at my work fell to me. Admittedly, a couple of smaller changes I worked on got left behind or stuck in review simply because there wasn’t a clear person/place to reach out to. I think this is both a barrier of entry to FreeBSD and a mental hurdle that I needed to get over. If there’s a change you want to see included or reviewed, then you may have to be the one to push for it, and there’s nothing wrong with that. Perhaps this process should be easier for newcomers or infrequent contributors (the disconnect between Bugzilla and Phabricator definitely leaves a lot to be desired), but we also have to be aware that this simply isn’t the reality right now. Getting your work looked at may require a little bit more self-motivation, but I’d argue that there are much worse problems a project like FreeBSD could have than this. I understand this a lot better now, but it is still something I struggle with. I’m not naturally the type of person who easily connects with others or asks for help, so I see this as an area for future growth rather than simply a struggle I encountered and overcame over the course of this work term. Certainly it is an important skill to understand the value of your own work, and equally important is the ability to communicate that value to others. I also learned the importance of starting small. My first week or two on the job mainly involved getting set up and comfortable with the workflow. After this initial stage, I began exploring the project and found myself overwhelmed by its scale. With so many possible areas to investigate, and so much work happening at once, I felt quite lost on where to begin. Many of the potential projects I found were too far beyond my experience level, and most small bugs were picked up and fixed quickly by more experienced contributors before I could even get to them. It’s easy to make the mistake that FreeBSD is made up solely of a few rock-star committers that do everything. This is how it appears at face-value, as reading through commits, bug reports, and mailing lists yields a few of the same names over and over. The reality is that just as important are the hundreds of users and infrequent contributors who take the time to submit bug reports, patches, or feedback. Even though there are some people who would fall under the umbrella of a rock-star committer, they didn’t get there overnight. Rather, they have built their skills and knowledge through many years of involvement in FreeBSD and similar projects. As a student coming into this project and having high expectations of myself, it was easy to set the bar too high by comparing myself against those big committers, and feel that my work was insignificant, inadequate, and simply too infrequent. In reality, there is no reason I should have felt this way. In a way, this comparison is disrespectful to those who have reached this level, as it took them a long time to get there, and it’s a humbling reminder that any skill worth learning requires time, patience, and dedication. It is easy to focus on an end product and simply wish to be there, but in order to be truly successful one must start small, and find satisfaction in the struggle of learning something new. I take pride in the many small successes I’ve had throughout my term here, and appreciate the fact that my journey into FreeBSD and open-source software is only just beginning. Closing Thoughts I would like to close with some brief thank-you’s. First, to everyone at the Foundation for being so helpful, and allowing this position to exist in the first place. I am extremely grateful to have been given this unique opportunity to learn about and give back to the open-source world. I’d also like to thank my office mates; Ed: for being an excellent mentor, who offered an endless wealth of knowledge and willingness to share it. My classmate and fellow intern Arshan: for giving me a sense of camaraderie and the comforting reminder that at many moments he was as lost as I was. Finally, a quick thanks to everyone else I crossed paths with who offered reviews and advice. I appreciate your help and look forward to working with you all further. I am walking away from this co-op with a much greater appreciation for this project, and have made it a goal to remain involved in some capacity. I feel that I’ve gained a little bit of a wider perspective on my place in the software world, something I never really got from my previous co-ops. Whether it ends up being just a stepping stone, or the beginning of much larger involvement, I thoroughly enjoyed my time here. Recent Developments in FreeBSD Support for encrypted, compressed (gzip and zstd), and network crash dumps enabled by default on most platforms Intel Microcode Splitter Intel Spec Store Bypass Disable control Raspberry Pi 3B+ Ethernet Driver IBRS for i386 Upcoming: Microcode updater for AMD CPUs the RACK TCP/IP stack, from Netflix Voting in the FreeBSD Core Election begins today: DigitalOcean Digital Ocean Promo Link for BSD Now Listeners Running FreeNAS on a DigitalOcean Droplet Need to backup your FreeNAS offsite? Run a locked down instance in the cloud, and replicate to it The tutorial walks though the steps of converting a fresh FreeBSD based droplet into a FreeNAS Create a droplet, and add a small secondary block-storage device Boot the droplet, login, and download FreeNAS Disable swap, enable ‘foot shooting’ mode in GEOM use dd to write the FreeNAS installer to the boot disk Reboot the droplet, and use the FreeNAS installer to install FreeNAS to the secondary block storage device Now, reimage the droplet with FreeBSD again, to replace the FreeNAS installer Boot, and dd FreeNAS from the secondary block storage device back to the boot disk You can now destroy the secondary block device Now you have a FreeNAS, and can take it from there. Use the FreeNAS replication wizard to configure sending snapshots from your home NAS to your cloud NAS Note: You might consider creating a new block storage device to create a larger pool, that you can more easily grow over time, rather than using the boot device in the droplet as your main pool. News Roundup Network Manager Control for OpenBSD (Updated) Generalities I just remind the scope of this small tool: allow you to pre-define several cable or wifi connections let nmctl to connect automatically to the first available one allow you to easily switch from one network connection to an other one create openbox dynamic menus Enhancements in this version This is my second development version: 0.2. I've added performed several changes in the code: code style cleanup, to better match the python recommendations adapt the tool to allow to connect to an Open-wifi having blancs in the name. This happens in some hotels implement a loop as work-around concerning the arp table issue. The source code is still on the git of Sourceforge.net. You can see the files here And you can download the last version here Feedbacks after few months I'm using this script on my OpenBSD laptop since about 5 months. In my case, I'm mainly using the openbox menus and the --restart option. The Openbox menus The openbox menus are working fine. As explain in my previous blog, I just have to create 2 entries in my openbox's menu.xml file, and all the rest comes automatically from nmctl itself thanks to the --list and --scan options. I've not changed this part of nmctl since it works as expected (for me :-) ). The --restart option Because I'm very lazy, and because OpenBSD is very simple to use, I've added the command "nmctl --restart" in the /etc/apm/resume script. Thanks to apmd, this script will be used each time I'm opening the lid of my laptop. In other words, each time I'll opening my laptop, nmctl will search the optimum network connection for me. But I had several issues in this scenario. Most of the problems were linked to the arp table issues. Indeed, in some circumstances, my proxy IP address was associated to the cable interface instead of the wifi interface or vice-versa. As consequence I'm not able to connect to the proxy, thus not able to connect to internet. So the ping to google (final test nmctl perform) is failing. Knowing that anyhow, I'm doing a full arp cleanup, it's not clear for me from where this problem come from. To solve this situation I've implemented a "retry" concept. In other words, before testing an another possible network connection (as listed in my /etc/nmctl.conf file), the script try 3x the current connection's parameters. If you want to reduce or increase this figures, you can do it via the --retry parameter. Results of my expertise with this small tool Where ever I'm located, my laptop is now connecting automatically to the wifi / cable connection previously identified for this location. Currently I have 3 places where I have Wifi credentials and 2 offices places where I just have to plug the network cable. Since the /etc/apm/resume scripts is triggered when I open the lid of the laptop, I just have to make sure that I plug the RJ45 before opening the laptop. For the rest, I do not have to type any commands, OpenBSD do all what is needed ;-). I hotels or restaurants, I can just connect to the Open Wifi thanks to the openbox menu created by "nmctl --scan". Next steps Documentation The tool is missing lot of documentation. I appreciate OpenBSD for his great documentation, so I have to do the same. I plan to write a README and a man page at first instances. But since my laziness, I will do it as soon as I see some interest for this tool from other persons. Tests I now have to travel and see how to see the script react on the different situations. Interested persons are welcome to share with me the outcome of their tests. I'm curious how it work. OpenBSD 6.3 on EdgeRouter Lite simple upgrade method TL;DR OpenBSD 6.3 oceton upgrade instructions may not factor that your ERL is running from the USB key they want wiped with the miniroot63.fs image loaded on. Place the bsd.rd for OpenBSD 6.3 on the sd0i slice used by U-Boot for the kernel, and then edit the boot command to run it. a tiny upgrade The OpenBSD documentation is comprehensive, but there might be rough corners around what are probably edge cases in their user base. People running EdgeRouter Lite hardware for example, who are looking to upgrade from 6.2 to 6.3. The documentation, which gave us everything we needed last time, left me with some questions about how to upgrade. In INSTALL.octeon, the Upgrading section does mention: The best solution, whenever possible, is to backup your data and reinstall from scratch I had to check if that directive existed in the documentation for other architectures. I wondered if oceton users were getting singled out. We were not. Just simplicity and pragmatism. Reading on: To upgrade OpenBSD 6.3 from a previous version, start with the general instructions in the section "Installing OpenBSD". But that section requires us to boot off of TFTP or NFS. Which I don’t want to do right now. Could also use a USB stick with the miniroot63.fs installed on it. But as the ERL only has a single USB port, we would have to remove the USB stick with the current install on it. Once we get to the Install or Upgrade prompt, there would be nothing to upgrade. Well, I guess I could use a USB hub. But the ERL’s USB port is inside the case. With all the screws in. And the tools are neatly put away. And I’d have to pull the USB hub from behind a workstation. And it’s two am. And I cleaned up the cabling in the lab this past weekend. Looks nice for once. So I don’t want to futz around with all that. There must be an almost imperceptibly easier way of doing this than setting up a TFTP server or NFS share in five minutes… Right? iXsystems Boise Technology Show 2018 Recap OpenZFS User Conference Slides & Videos Thank you ZFS ZSTD Compression Pool Layout Considerations ZFS Releases Helping Developers Help You ZFS and MySQL on Linux Micron OSNEXUS ZFS at Six Feet Up Flexible Disk Use with OpenZFS Batch editing files with ed what’s ‘ed’? ed is this sort of terrifying text editor. A typical interaction with ed for me in the past has gone something like this: $ ed help ? h ? asdfasdfasdfsadf ? Basically if you do something wrong, ed will just print out a single, unhelpful, ?. So I’d basically dismissed ed as an old arcane Unix tool that had no practical use today. vi is a successor to ed, except with a visual interface instead of this ? surprise: Ed is actually sort of cool and fun So if Ed is a terrifying thing that only prints ? at you, why am I writing a blog post about it? WELL!!!! On April 1 this year, Michael W Lucas published a new short book called Ed Mastery. I like his writing, and even though it was sort of an april fool’s joke, it was ALSO a legitimate actual real book, and so I bought it and read it to see if his claims that Ed is actually interesting were true. And it was so cool!!!! I found out: how to get Ed to give you better error messages than just ? that the name of the grep command comes from ed syntax (g/re/p) the basics of how to navigate and edit files using ed All of that was a cool Unix history lesson, but did not make me want to actually use Ed in real life. But!!! The other neat thing about Ed (that did make me want to use it!) is that any Ed session corresponds to a script that you can replay! So if I know Ed, then I can use Ed basically as a way to easily apply vim-macro-like programs to my files. Beastie Bits FreeBSD Mastery: Jails -- Help make it happen Video: OpenZFS Basics presented by George Wilson and Matt Ahrens at Scale 16x back in March 2018 DragonFlyBSD’s IPFW gets highspeed lockless in-kernel NAT A Love Letter to OpenBSD New talks, and the F-bomb Practical UNIX Manuals: mdoc BSD Meetup in Zurich: May 24th BSD Meetup in Warsaw: May 24th MeetBSD 2018 Tarsnap Feedback/Questions Seth - First time poudriere Builder Farhan - Why we didn't go FreeBSD architech - Encryption Feedback Dave - Handy Tip on setting up automated coredump handling for FreeBSD Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Larry and Chris (and Marisa) fill a little time between bits.  Enjoy!

This is it, another Microcode to tide you over before our next full length episode! A reminder, we have an album for sale. You can, ironically, support all this free content by purchasing it! (https://goo.gl/tX14FB) You can also help us out by reviewing us on iTunes and telling your friends! (https://goo.gl/xwiQnx) Victrola is brought to you by the fine folks at Austin's ColdTowne Theater. Written by and Starring Michael Jastroch, Bryan Roberts, Lance Gilstrap, Cortnie Jones, Jericho Thorp and Molly Moore! Produced by Michael Jastroch, with additional editing by Dalton Allen - in collaboration with our good friends at ColdTowne Theater (http://ColdTowneTheater.com). http://victrolapod.com http://coldtownetheater.com

This is it, another Microcode to tide you over before our next full length episode! A reminder, we have an album for sale. You can, ironically, support all this free content by purchasing it! (https://goo.gl/tX14FB) You can also help us out by reviewing us on iTunes and telling your friends! (https://goo.gl/xwiQnx) Victrola is brought to you by the fine folks at Austin's ColdTowne Theater. Written by and Starring Michael Jastroch, Bryan Roberts, Lance Gilstrap, Cortnie Jones, Jericho Thorp and Molly Moore! Produced by Michael Jastroch, with additional editing by Dalton Allen - in collaboration with our good friends at ColdTowne Theater (http://ColdTowneTheater.com). http://victrolapod.com http://coldtownetheater.com

This is it, another Microcode to tide you over before our next full length episode! A reminder, we have an album for sale. You can, ironically, support all this free content by purchasing it! (https://goo.gl/tX14FB) You can also help us out by reviewing us on iTunes and telling your friends! (https://goo.gl/xwiQnx) Victrola is brought to you by the fine folks at Austin's ColdTowne Theater. Written by and Starring Michael Jastroch, Bryan Roberts, Lance Gilstrap, Cortnie Jones, Jericho Thorp and Molly Moore! Produced by Michael Jastroch, with additional editing by Dalton Allen - in collaboration with our good friends at ColdTowne Theater (http://ColdTowneTheater.com). http://victrolapod.com http://coldtownetheater.com

This is it, another Microcode to tide you over while we slave away on the March episode! A reminder, we have an album for sale. You can, ironically, support all this free content by purchasing it! (https://goo.gl/tX14FB) You can also help us out by reviewing us on iTunes and telling your friends! (https://goo.gl/xwiQnx) Victrola is brought to you by the fine folks at Austin's ColdTowne Theater. Written by and Starring Michael Jastroch, Bryan Roberts, Lance Gilstrap, Cortnie Jones, Jericho Thorp and Molly Moore! Produced by Michael Jastroch, with additional editing by Dalton Allen - in collaboration with our good friends at ColdTowne Theater (http://ColdTowneTheater.com). http://victrolapod.com http://coldtownetheater.com

This is it, another Microcode to tide you over while we slave away on the March episode! A reminder, we have an album for sale. You can, ironically, support all this free content by purchasing it! (https://goo.gl/tX14FB) You can also help us out by reviewing us on iTunes and telling your friends! (https://goo.gl/xwiQnx) Victrola is brought to you by the fine folks at Austin's ColdTowne Theater. Written by and Starring Michael Jastroch, Bryan Roberts, Lance Gilstrap, Cortnie Jones, Jericho Thorp and Molly Moore! Produced by Michael Jastroch, with additional editing by Dalton Allen - in collaboration with our good friends at ColdTowne Theater (http://ColdTowneTheater.com). http://victrolapod.com http://coldtownetheater.com

Intel zieht Microcode-Updates für Prozessoren zurück Die Probleme mit den Prozessorsicherheitslücken Meltdown und Spectre reißen nicht ab: Intel rät davon ab, die zuvor bereitgestellten CPU-Microcode-Updates einzuspielen, die zum Schließen der Sicherheitslücke Spectre Variante 2 nötig sind. Laut Intel-Blog hat man mittlerweile die Ursache für plötzliche Neustarts nach dem Einspielen der Updates gefunden. Erst nach weiteren Tests will man die überarbeiteten Microcode-Updates freigeben. Snowden-App Haven kaum mit deutschem Recht vereinbar Die Android-App Haven hat einen prominenten Paten: Edward Snowden. Die Software verwandelt ein Smartphone in eine Überwachungswanze, die Bewegungen und andere Auffälligkeiten registriert, Unterhaltungen mitschneidet und alles fotografiert, was vor die Kamera läuft. Gedacht ist die App für Dissidenten oder Investigativ-Journalisten, die sicher sein wollen, dass ihre Wohnung oder die Tasche nicht heimlich durchsucht wurden. Leider kann die App genauso gut von Hobby-Schnüfflern, Spannern und paranoiden Ehepartnern missbraucht werden. Der Einsatz in Deutschland, so die Einschätzung der c't, ist aufgrund der engen Datenschutz-Vorschriften rechtlich höchst problematisch. Ein Viertel der Deutschen bleibt im digitalen Abseits 81 % der Bundesbürger sind online – ein Plus von zwei Prozentpunkten gegenüber 2016. Dies geht aus der Studie der Initiative D21 hervor. 6 % bewegen sich allerdings nur Minimal Online. Die Gruppe der Offliner liegt bei 19 %. Die Teilhabe an der Gesellschaft sei jedoch zunehmend an die digitale Welt gebunden. Menschen, die sich diese nicht erschließen könnten, würden "von entscheidenden gesellschaftlichen und wirtschaftlichen Entwicklungen ausgegrenzt", so die Studie. Netflix boomt weiter Trotz Preiserhöhungen hält der Ansturm auf den Online-Video-Dienst an. Im abgelaufenen Geschäftsjahr 2017 verdiente Netflix 559 Millionen Dollar und damit fast dreimal so viel wie im Vorjahr. Bei Anlegern kamen die Zahlen sehr gut an. Die Marke konnte erstmals den Börsenwert von 100 Milliarden Dollar knacken. Diese und alle weiteren aktuellen Nachrichten finden sie auf heise.de

We review Meltdown and Spectre responses from various BSD projects, show you how to run CentOS with bhyve, GhostBSD 11.1 is out, and we look at the case against the fork syscall. This episode was brought to you by Headlines More Meltdown Much has been happened this week, but before we get into a status update of the various mitigations on the other BSDs, some important updates: Intel has recalled the microcode update they issued on January 8th. It turns out this update can cause Haswell and Broadwell based systems to randomly reboot, with some frequency. (https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/) AMD has confirmed that its processors are vulnerable to both variants of Spectre, and the the fix for variant #2 will require a forthcoming microcode update, in addition to OS level mitigations (https://www.amd.com/en/corporate/speculative-execution) Fujitsu has provided a status report for most of its products, including SPARC hardware (https://sp.ts.fujitsu.com/dmsp/Publications/public/Intel-Side-Channel-Analysis-Method-Security-Review-CVE2017-5715-vulnerability-Fujitsu-products.pdf) The Register of course has some commentary (https://www.theregister.co.uk/2018/01/12/intel_warns_meltdown_spectre_fixes_make_broadwells_haswells_unstable/) If new code is needed, Intel will need to get it right: the company already faces numerous class action lawsuits. Data centre operators already scrambling to conduct unplanned maintenance will not be happy about the fix reducing stability. AMD has said that operating system patches alone will address the Spectre bounds check bypass bug. Fixing Spectre's branch target injection flaw will require firmware fixes that AMD has said will start to arrive for Ryzen and EPYC CPUs this week. The Register has also asked other server vendors how they're addressing the bugs. Oracle has patched its Linux, but has told us it has “No comment/statement on this as of now” in response to our query about its x86 systems, x86 cloud, Linux and Solaris on x86. The no comment regarding Linux is odd as fixes for Oracle Linux landed here (https://linux.oracle.com/errata/ELSA-2018-4006.html) on January 9th. SPARC-using Fujitsu, meanwhile, has published advice (PDF) revealing how it will address the twin bugs in its servers and PCs, and also saying its SPARC systems are “under investigation”. Response from OpenBSD: (https://undeadly.org/cgi?action=article;sid=20180106082238) 'Meltdown, aka "Dear Intel, you suck"' (https://marc.info/?t=151521438600001&r=1&w=2) Theo de Raadt's response to Meltdown (https://www.itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html) That time in 2007 when Theo talked about how Intel x86 had major design problems in their chips (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2) OpenBSD gets a Microcode updater (https://marc.info/?l=openbsd-cvs&m=151570987406841&w=2) Response from Dragonfly BSD: (http://lists.dragonflybsd.org/pipermail/users/2018-January/313758.html) The longer response in four commits One (http://lists.dragonflybsd.org/pipermail/commits/2018-January/627151.html) Two (http://lists.dragonflybsd.org/pipermail/commits/2018-January/627152.html) Three (http://lists.dragonflybsd.org/pipermail/commits/2018-January/627153.html) Four (http://lists.dragonflybsd.org/pipermail/commits/2018-January/627154.html) Even more Meltdown (https://www.dragonflydigest.com/2018/01/10/20718.html) DragonflyBSD master now has full IBRS and IBPB support (http://lists.dragonflybsd.org/pipermail/users/2018-January/335643.html) IBRS (Indirect Branch Restricted Speculation): The x86 IBRS feature requires corresponding microcode support. It mitigates the variant 2 vulnerability. If IBRS is set, near returns and near indirect jumps/calls will not allow their predicted target address to be controlled by code that executed in a less privileged prediction mode before the IBRS mode was last written with a value of 1 or on another logical processor so long as all RSB entries from the previous less privileged prediction mode are overwritten. Speculation on Skylake and later requires these patches ("dynamic IBRS") be used instead of retpoline. If you are very paranoid or you run on a CPU where IBRS=1 is cheaper, you may also want to run in "IBRS always" mode. IBPB (Indirect Branch Prediction Barrier): Setting of IBPB ensures that earlier code's behavior does not control later indirect branch predictions. It is used when context switching to new untrusted address space. Unlike IBRS, IBPB is a command MSR and does not retain its state. DragonFlyBSD's Meltdown Fix Causing More Slowdowns Than Linux (https://www.phoronix.com/scan.php?page=article&item=dragonfly-bsd-meltdown&num=1) NetBSD HOTPATCH() (http://mail-index.netbsd.org/source-changes/2018/01/07/msg090945.html) NetBSD SVS (Separate Virtual Space) (http://mail-index.netbsd.org/source-changes/2018/01/07/msg090952.html) Running CentOS with Bhyve (https://www.daemon-security.com/2018/01/bhyve-centos-0110.html) With the addition of UEFI in FreeBSD (since version 11), users of bhyve can use the UEFI boot loader instead of the grub2-bhyve port for booting operating systems such as Microsoft Windows, Linux and OpenBSD. The following page provides information necessary for setting up bhyve with UEFI boot loader support: https://wiki.freebsd.org/bhyve/UEFI Features have been added to vmrun.sh to make it easier to setup the UEFI boot loader, but the following is required to install the UEFI firmware pkg: # pkg install -y uefi-edk2-bhyve With graphical support, you can use a vnc client like tigervnc, which can be installed with the following command: # pkg install -y tigervnc In the case of most corporate or government environments, the Linux of choice is RHEL, or CentOS. Utilizing bhyve, you can test and install CentOS in a bhyve VM the same way you would deploy a Linux VM in production. The first step is to download the CentOS iso (for this tutorial I used the CentOS minimal ISO): http://isoredirect.centos.org/centos/7/isos/x8664/CentOS-7-x8664-Minimal-1708.iso I normally use a ZFS Volume (zvol) when running bhyve VMs. Run the following commands to create a zvol (ensure you have enough disk space to perform these operations): # zfs create -V20G -o volmode=dev zroot/centos0 (zroot in this case is the zpool I am using) Similar to my previous post about vmrun.sh, you need certain items to be configured on FreeBSD in order to use bhyve. The following commands are necessary to get things running: ``` echo "vfs.zfs.vol.mode=2" >> /boot/loader.conf kldload vmm ifconfig tap0 create sysctl net.link.tap.uponopen=1 net.link.tap.uponopen: 0 -> 1 ifconfig bridge0 create ifconfig bridge0 addm em0 addm tap0 ifconfig bridge0 up ``` (replace em0 with whatever your physical interface is). There are a number of utilities that can be used to manage bhyve VMs, and I am sure there is a way to use vmrun.sh to run Linux VMs, but since all of the HowTos for running Linux use the bhyve command line, the following script is what I use for running CentOS with bhyve. ``` !/bin/sh General bhyve install/run script for CentOS Based on scripts from pr1ntf and lattera HOST="127.0.0.1" PORT="5901" ISO="/tmp/centos.iso" VMNAME="centos" ZVOL="centos0" SERIAL="nmda0A" TAP="tap1" CPU="1" RAM="1024M" HEIGHT="800" WIDTH="600" if [ "$1" == "install" ]; then Kill it before starting it bhyvectl --destroy --vm=$VMNAME bhyve -c $CPU -m $RAM -H -P -A -s 0,hostbridge -s 2,virtio-net,$TAP -s 3,ahci-cd,$ISO -s 4,virtio-blk,/dev/zvol/zroot/$ZVOL -s 29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT -s 30,xhci,tablet -s 31,lpc -l com1,/dev/$SERIAL -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd $VMNAME kill it after bhyvectl --destroy --vm=$VMNAME elif [ "$1" == "run" ]; then Kill it before starting it bhyvectl --destroy --vm=centos bhyve -c $CPU -m $RAM -w -H -s 0,hostbridge -s 2,virtio-net,$TAP -s 4,virtio-blk,/dev/zvol/zroot/$ZVOL -s 29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT -s 30,xhci,tablet -s 31,lpc -l com1,/dev/$SERIAL -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd $VMNAME & else echo "Please type install or run"; fi ``` The variables at the top of the script can be adjusted to fit your own needs. With the addition of the graphics output protocol in UEFI (or UEFI-GOP), a VNC console is launched and hosted with the HOST and PORT setting. There is a password option available for the VNC service, but the connection should be treated as insecure. It is advised to only listen on localhost with the VNC console and tunnel into the host of the bhyve VM. Now with the ISO copied to /tmp/centos.iso, and the script saved as centos.sh you can run the following command to start the install: # ./centos.sh install At this point, using vncviewer (on the local machine, or over an SSH tunnel), you should be able to bring up the console and run the CentOS installer as normal. The absolutely most critical item is to resolve an issue with the booting of UEFI after the installation has completed. Because of the path used in bhyve, you need to run the following to be able to boot CentOS after the installation: # cp -f /mnt/sysimage/boot/efi/EFI/centos/grubx64.efi /mnt/sysimage/boot/efi/EFI/BOOT With this setting changed, the same script can be used to launch your CentOS VM as needed: # ./centos.sh run If you are interested in a better solution for managing your Linux VM, take a look at the various bhyve management ports in the FreeBSD ports tree. Interview - newnix architect - @newnix (https://bsd.network/@newnix) News Roundup GhostBSD 11.1 - FreeBSD for the desktop (https://distrowatch.com/weekly.php?issue=20180108#ghostbsd) GhostBSD is a desktop oriented operating system which is based on FreeBSD. The project takes the FreeBSD operating system and adds a desktop environment, some popular applications, a graphical package manager and Linux binary compatibility. GhostBSD is available in two flavours, MATE and Xfce, and is currently available for 64-bit x86 computers exclusively. I downloaded the MATE edition which is available as a 2.3GB ISO file. Installing GhostBSD's system installer is a graphical application which begins by asking us for our preferred language, which we can select from a list. We can then select our keyboard's layout and our time zone. When it comes to partitioning we have three main options: let GhostBSD take over the entire disk using UFS as the file system, create a custom UFS layout or take over the entire disk using ZFS as the file system. UFS is a classic file system and quite popular, it is more or less FreeBSD's equivalent to Linux's ext4. ZFS is a more advanced file system with snapshots, multi-disk volumes and optional deduplication of data. I decided to try the ZFS option. Once I selected ZFS I didn't have many more options to go through. I was given the chance to set the size of my swap space and choose whether to set up ZFS as a plain volume, with a mirrored disk for backup or in a RAID arrangement with multiple disks. I stayed with the plain, single disk arrangement. We are then asked to create a password for the root account and create a username and password for a regular user account. The installer lets us pick our account's shell with the default being fish, which seemed unusual. Other shells, including bash, csh, tcsh, ksh and zsh are available. The installer goes to work copying files and offers to reboot our computer when it is done. Early impressions The newly installed copy of GhostBSD boots to a graphical login screen where we can sign into the account we created during the install process. Signing into our account loads the MATE 1.18 desktop environment. I found MATE to be responsive and applications were quick to open. Early on I noticed odd window behaviour where windows would continue to slide around after I moved them with the mouse, as if the windows were skidding on ice. Turning off compositing in the MATE settings panel corrected this behaviour. I also found the desktop's default font (Montserrat Alternates) to be hard on my eyes as the font is thin and, for lack of a better term, bubbly. Fonts can be easily adjusted in the settings panel. A few minutes after I signed into my account, a notification appeared in the system tray letting me know software updates were available. Clicking the update icon brings up a small window showing us a list of package updates and, if any are available, updates to the base operating system. FreeBSD, and therefore GhostBSD, both separate the core operating system from the applications (packages) which run on the operating system. This means we can update the core of the system separately from the applications. GhostBSD's core remains relatively static and minimal while applications are updated using a semi-rolling schedule. When we are updating the core operating system, the update manager will give us the option of rebooting the system to finish the process. We can dismiss this prompt to continue working, but the wording of the prompt may be confusing. When asked if we want to reboot to continue the update process, the options presented to us are "Continue" or "Restart". The Continue option closes the update manager and returns us to the MATE desktop. The update manager worked well for me and the only issue I ran into was when I dismissed the update manager and then wanted to install updates later. There are two launchers for the update manager, one in MATE's System menu and one in the settings panel. Clicking either of these launchers didn't accomplish anything. Running the update manager from the command line simply caused the process to lock up until killed. I found if I had dismissed the update manager once, I'd have to wait until I logged in again to use it. Alternatively, I could use a command line tool or use the OctoPkg package manager to install package updates. Conclusions Most of my time with GhostBSD, I was impressed and happy with the operating system. GhostBSD builds on a solid, stable FreeBSD core. We benefit from FreeBSD's performance and its large collection of open source software packages. The MATE desktop was very responsive in my trial and the system is relatively light on memory, even when run on ZFS which has a reputation for taking up more memory than other file systems. FreeBSD Looks At Making Wayland Support Available By Default (https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-Wayland-Availability) There's an active discussion this week about making Wayland support available by default on FreeBSD. FreeBSD has working Wayland support -- well, assuming you have working Intel / Radeon graphics -- and do have Weston and some other Wayland components available via FreeBSD Ports. FreeBSD has offered working Wayland support that is "quite usable" for more than one year. But, it's not too easy to get going with Wayland on FreeBSD. Right now those FreeBSD desktop users wanting to use/develop with Wayland currently need to rebuild the GTK3 tool-kit, Mesa, and other packages with Wayland support enabled. This call for action now is about allowing the wayland=on to be made the default. This move would then allow these dependencies to be built with Wayland support by default, but for the foreseeable future FreeBSD will continue defaulting to X.Org-based sessions. The FreeBSD developers mostly acknowledge that Wayland is the future and the cost of enabling Wayland support by default is just slightly larger packages, but that weight is still leaner than the size of the X.Org code-base and its dependencies. FreeBSD vote thread (https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111906.html) TrueOS Fliped the switch already (https://github.com/trueos/trueos-core/commit/f48dba9d4e8cefc45d6f72336e7a0b5f42a2f6f1) fork is not my favorite syscall (https://sircmpwn.github.io/2018/01/02/The-case-against-fork.html) This article has been on my to-write list for a while now. In my opinion, fork is one of the most questionable design choices of Unix. I don't understand the circumstances that led to its creation, and I grieve over the legacy rationale that keeps it alive to this day. Let's set the scene. It's 1971 and you're a fly on the wall in Bell Labs, watching the first edition of Unix being designed for the PDP-11/20. This machine has a 16-bit address space with no more than 248 kilobytes of memory. They're discussing how they're going to support programs that spawn new programs, and someone has a brilliant idea. “What if we copied the entire address space of the program into a new process running from the same spot, then let them overwrite themselves with the new program?” This got a rousing laugh out of everyone present, then they moved on to a better design which would become immortalized in the most popular and influential operating system of all time. At least, that's the story I'd like to have been told. In actual fact, the laughter becomes consensus. There's an obvious problem with this approach: every time you want to execute a new program, the entire process space is copied and promptly discarded when the new program begins. Usually when I complain about fork, this the point when its supporters play the virtual memory card, pointing out that modern operating systems don't actually have to copy the whole address space. We'll get to that, but first — First Edition Unix does copy the whole process space, so this excuse wouldn't have held up at the time. By Fourth Edition Unix (the next one for which kernel sources survived), they had wisened up a bit, and started only copying segments when they faulted. This model leads to a number of problems. One is that the new process inherits all of the parent's process descriptors, so you have to close them all before you exec another process. However, unless you're manually keeping tabs on your open file descriptors, there is no way to know what file handles you must close! The hack that solves this is CLOEXEC, the first of many hacks that deal with fork's poor design choices. This file descriptors problem balloons a bit - consider for example if you want to set up a pipe. You have to establish a piped pair of file descriptors in the parent, then close every fd but the pipe in the child, then dup2 the pipe file descriptor over the (now recently closed) file descriptor 1. By this point you've probably had to do several non-trivial operations and utilize a handful of variables from the parent process space, which hopefully were on the stack so that we don't end up copying segments into the new process space anyway. These problems, however, pale in comparison to my number one complaint with the fork model. Fork is the direct cause of the stupidest component I've ever heard of in an operating system: the out-of-memory (aka OOM) killer. Say you have a process which is using half of the physical memory on your system, and wants to spawn a tiny program. Since fork “copies” the entire process, you might be inclined to think that this would make fork fail. But, on Linux and many other operating systems since, it does not fail! They agree that it's stupid to copy the entire process just to exec something else, but because fork is Important for Backwards Compatibility, they just fake it and reuse the same memory map (except read-only), then trap the faults and actually copy later. The hope is that the child will get on with it and exec before this happens. However, nothing prevents the child from doing something other than exec - it's free to use the memory space however it desires! This approach now leads to memory overcommittment - Linux has promised memory it does not have. As a result, when it really does run out of physical memory, Linux will just kill off processes until it has some memory back. Linux makes an awfully big fuss about “never breaking userspace” for a kernel that will lie about memory it doesn't have, then kill programs that try to use the back-alley memory they were given. That this nearly 50 year old crappy design choice has come to this astonishes me. Alas, I cannot rant forever without discussing the alternatives. There are better process models that have been developed since Unix! The first attempt I know of is BSD's vfork syscall, which is, in a nutshell, the same as fork but with severe limitations on what you do in the child process (i.e. nothing other than calling exec straight away). There are loads of problems with vfork. It only handles the most basic of use cases: you cannot set up a pipe, cannot set up a pty, and can't even close open file descriptors you inherited from the parent. Also, you couldn't really be sure of what variables you were and weren't editing or allowed to edit, considering the limitations of the C specification. Overall this syscall ended up being pretty useless. Another model is posixspawn, which is a hell of an interface. It's far too complicated for me to detail here, and in my opinion far too complicated to ever consider using in practice. Even if it could be understood by mortals, it's a really bad implementation of the spawn paradigm — it basically operates like fork backwards, and inherits many of the same flaws. You still have to deal with children inheriting your file descriptors, for example, only now you do it in the parent process. It's also straight-up impossible to make a genuine pipe with posixspawn. (Note: a reader corrected me - this is indeed possible via posixspawnfileactionsadddup2.) Let's talk about the good models - rfork and spawn (at least, if spawn is done right). rfork originated from plan9 and is a beautiful little coconut of a syscall, much like the rest of plan9. They also implement fork, but it's a special case of rfork. plan9 does not distinguish between processes and threads - all threads are processes and vice versa. However, new processes in plan9 are not the everything-must-go fuckfest of your typical fork call. Instead, you specify exactly what the child should get from you. You can choose to include (or not include) your memory space, file descriptors, environment, or a number of other things specific to plan9. There's a cool flag that makes it so you don't have to reap the process, too, which is nice because reaping children is another really stupid idea. It still has some problems, mainly around creating pipes without tremendous file descriptor fuckery, but it's basically as good as the fork model gets. Note: Linux offers this via the clone syscall now, but everyone just fork+execs anyway. The other model is the spawn model, which I prefer. This is the approach I took in my own kernel for KnightOS, and I think it's also used in NT (Microsoft's kernel). I don't really know much about NT, but I can tell you how it works in KnightOS. Basically, when you create a new process, it is kept in limbo until the parent consents to begin. You are given a handle with which you can configure the process - you can change its environment, load it up with file descriptors to your liking, and so on. When you're ready for it to begin, you give the go-ahead and it's off to the races. The spawn model has none of the flaws of fork. Both fork and exec can be useful at times, but spawning is much better for 90% of their use-cases. If I were to write a new kernel today, I'd probably take a leaf from plan9's book and find a happy medium between rfork and spawn, so you could use spawn to start new threads in your process space as well. To the brave OS designers of the future, ready to shrug off the weight of legacy: please reconsider fork. Enable ld.lld as bootstrap linker by default on amd64 (https://svnweb.freebsd.org/changeset/base/327783) Enable ld.lld as bootstrap linker by default on amd64 For some time we have been planning to migrate to LLVM's lld linker. Having a man page was the last blocking issue for using ld.lld to link the base system kernel + userland, now addressed by r327770. Link the kernel and userland libraries and binaries with ld.lld by default, for additional test coverage. This has been a long time in the making. On 2013-04-13 I submitted an upstream tracking issue in LLVM PR 23214: [META] Using LLD as FreeBSD's system linker. Since then 85 individual issues were identified, and submitted as dependencies. These have been addressed along with two and a half years of other lld development and improvement. I'd like to express deep gratitude to upstream lld developers Rui Ueyama, Rafael Espindola, George Rimar and Davide Italiano. They put in substantial effort in addressing the issues we found affecting FreeBSD/amd64. To revert to using ld.bfd as the bootstrap linker, in /etc/src.conf set WITHOUTLLDBOOTSTRAP=yes If you need to set this, please follow up with a PR or post to the freebsd-toolchain mailing list explaining how default WITHLLDBOOTSTRAP failed for your use case. Note that GNU ld.bfd is still installed as /usr/bin/ld, and will still be used for linking ports. ld.lld can be installed as /usr/bin/ld by setting in /etc/src.conf WITH_LLD_IS_LLD=yes A followup commit will set WITHLLDIS_LD by default, possibly after Clang/LLVM/lld 6.0 is merged to FreeBSD. Release notes: Yes Sponsored by: The FreeBSD Foundation Followup: https://www.mail-archive.com/svn-src-all@freebsd.org/msg155493.html *** Beastie Bits BSDCAN2017 Interview with Peter Hessler, Reyk Floeter, and Henning Brauer (https://undeadly.org/cgi?action=article;sid=20171229080944) video (https://www.youtube.com/watch?v=e-Xim3_rJns) DSBMD (https://freeshell.de/~mk/projects/dsbmd.html) ccc34 talk - May contain DTraces of FreeBSD (https://media.ccc.de/v/34c3-9196-may_contain_dtraces_of_freebsd) [scripts to run an OpenBSD mirror, rsync and verify])(https://github.com/bluhm/mirror-openbsd) Old School PC Fonts (https://int10h.org/oldschool-pc-fonts/readme/) Feedback/Questions David - Approach and Tools for Snapshots and Remote Replication (http://dpaste.com/33HKKEM#wrap) Brian - Help getting my FreeBSD systems talking across the city (http://dpaste.com/3QWFEYR#wrap) Malcolm - First BSD Meetup in Stockholm happened and it was great (http://dpaste.com/1Z9Y8H1) Brad - Update on TrueOS system (http://dpaste.com/3EC9RGG#wrap) ***