Open-source News

Mirai Malware for Linux Double Down on Stronger Chips  CrowdStrike

New ‘pymafka’ malicious package drops Cobalt Strike on macOS, Windows, Linux  Security Boulevard

How Memory Allocation Works on Linux  MUO - MakeUseOf

Last week the rolling-release openSUSE Tumbleweed switched to the new GCC 12 as the default system compiler and rebuilt its package set under this annual feature upgrade to the GNU Compiler Collection. For those curious here are some benchmarks before and after that GCC 12 transition for openSUSE Tumbleweed.

'Psychonauts 2' is coming to macOS and Linux next week  NME

'Psychonauts 2' is coming to macOS and Linux next week  NME

SDxCentral 2-Minute Weekly Wrap: OpenSSF, Linux Foundation Want to Replace C, C++  SDxCentral

While Mesa's RADV open-source Radeon Vulkan driver continues seeing a lot of activity on a near daily basis by developers from Valve, Red Hat, Google, and other independent contributors, AMD continues with AMDVLK as their official open-source Vulkan driver derived from their internal, closed-source Vulkan driver for Windows and Linux. Out today is AMDVLK 2022.Q2.2 as the latest open-source snapshot of this Vulkan driver...

The power of a story. I first wrote about this 7 years ago in a series I titled Lessons from a Two Year Old. But it is a reality as old as time itself – humans are wired for stories. We enjoy listening to them, telling them, and they help us to relate to others and to remember things. 

And everyone has a story to tell – many of which haven’t been told yet. 

Our own Mark Miller is working on sharing the previously untold stories of the people in open source. He has a unique gift for pulling stories out of people and showcasing what made each person who they are today and how their journey resulted in some of the top open source projects of all time. Each person is making a positive difference in our world, and each one has their own unique journey.

Mark will be sharing these stories in our upcoming, aptly named podcast, The Untold Stories of Open Source. It will be formally launched at the Open Source Summit North America and OpenSSF Day in June, but you are in luck and he has soft-launched with his first episode, telling the story of Brian Behlendorf, General Manager of the OpenSSF. But, Brian had quite the journey before his role at OpenSSF and that story is now being told. 

Like myself, Brian was coming of age when PCs were being introduced to the world, Oregon Trail was the game of choice (okay, it was about the only game), and the Internet was still a project at the National Science Foundation. Brian’s parents worked in the science and technology field – they even met at IBM. His father was a COBOL programmer, which gave Brian a look into the world of programming. Imagining a life of coding in basements, away from people, is why he decided against majoring in computer science. I can relate – we both started college in the fall of 1991, and, I too, decided against majoring in computer science because I envisioned a future of myself, a computer, a pot of coffee, and little social interaction. 

The Internet was just getting introduced to the world in 1991 – and Brian, like all incoming freshmen at the University of California – Berkeley, received an email address. With this, he connected with others who shared a common interest in R.E.M. and 4AD and the rave scene around San Francisco. He built a mailing list around this shared interest. Yada…yada… The first issue of Wired magazine mesmerizes Brian in 1993.

Turns out one of the friends Brian met in his music community was working at Wired to get it – well wired. It started as a print newsletter (ironically). His friend, Jonathan, reached out and hired Brian for $100/week to help them get back issues online. Unlike today’s iconic, stunning design, it was black text on a white background. 

Besides just digitizing previously published content, Brian helped produce digital-only content. A unique approach back then. It was one of the first ad-supported websites – hotwired.com. Brian jokes, “I like to say I put the first ad-banner on the web, and I have been apologizing for it ever since.” 

As Brian worked on the content, he had a vision of publishing books online. But, turns out, back then publishers didn’t have the budgets to devote to web content. But bigger brands, looking to advertise on Hotwired, did, and they needed to have a website to point to.  So he joined Organic, a web design firm, as CTO at the ripe age of 22. They build the websites for some of the first advertisers on Hotwired like Club Med, Volvo, Saturn cars, Levis, Nike, and others. 

Back then, Wired and the sites Organic built all ran on a web server software developed by students at the University of Illinois, in the same lab that developed the NCSA Mosaic browser. Long before the term open source was coined, software running the web almost always included the source code. Brian notes there was an unwritten code (pun intended) that if you find a bug, you were morally obligated to fix it and push the code upline so that everyone had it. He and a group of students started working on further developing the browser. Netscape bought the software, which halted ongoing student support for the browser. Although the code remains open. Brain and others kept updating the code, and they decided to change the name since it was a new project. Because it was a group of patches, they chose the name Apache Web Server (get it – a patchy server). It now runs an estimated 60% of all web servers in the world. 

As interesting as Brian’s story is to this point – I really just scratched the surface. Mark’s first episode of the podcast shares the rest, from founding Collab.net to a medical records system in Rwanda to working at the White House to his roles at Hyperledger and now OpenSSF and more.

Okay – I have said too much. No real spoilers. You can listen to the full episode now on Spotify. (more platforms coming soon). 

Mark has been recording and stitching together episodes all year. I look forward to listening. Look for the formal launch, and several new episodes, at Open Source Summit North America and OpenSSF Day on June 20, 2022.

The post Linux Foundation Podcast Series: “The Untold Stories of Open Source” appeared first on Linux Foundation.

FreeBSD 13.1 is out for everything from PowerPC to x86-64  The Register

Microsoft Warns Rise in XorDdos Malware Targeting Linux Devices  The Hacker News

Fedora will keep around its legacy BIOS support that was decided earlier this month after a proposal to deprecate legacy BIOS support to focus resources on UEFI-only booting. However, Fedora will be relying more on the community to maintain that legacy boot support and as such the Fedora BIOS Boot SIG (Special Interest Group) is now established...

Since Ubuntu 20.10 there has been Active Directory integration in the Ubiquity installer while now it looks like the latest effort by Canonical on enhancing the Ubuntu desktop for the enterprise is around Microsoft Azure Active Directory (Azure AD) integration...

While the kernel-side Intel AMX support landed in Linux 5.16 and KVM support for AMX in Linux 5.17, other Linux patches around Advanced Matrix Extensions (AMX) remain floating around. One important patch-set was updated this week for ensuring proper power management on AMX-enabled processors, coming with Xeon Scalable "Sapphire Rapids" this year...

Linux Patches Updated For Better Power Management On AMX "Sapphire Rapids" Servers  Phoronix

Merged yesterday to the mainline X.Org Server for XWayland is the "-force-xrandr-emulation" option added for Valve's Gamescope / Steam Deck usage...

AMD has released a new version of AOMP, its LLVM/Clang compiler downstream where they stage their latest patches focused on OpenMP GPU offload support for their Radeon graphics cards / Instinct accelerators...

How to Securely Delete Files in Linux  groovyPost

How to rename a branch, delete a branch, and find the author of a branch in Git Agil Antony Fri, 05/20/2022 - 03:00 Register or Login to like Register or Login to like

One of Git's primary strengths is its ability to "fork" work into different branches.

If you're the only person using a repository, the benefits are modest, but once you start working with many other contributors, branching is essential. Git's branching mechanism allows multiple people to work on a project, and even on the same file, at the same time. Users can introduce different features, independent of one another, and then merge the changes back to a main branch later. A branch created specifically for one purpose, such as adding a new feature or fixing a known bug, is sometimes called a topic branch.

Once you start working with branches, it's helpful to know how to manage them. Here are the most common tasks developers do with Git branches in the real world.

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Rename a branch using Git

Renaming a topic branch is useful if you have named a branch incorrectly or you want to use the same branch to switch between different bugs or tasks after merging the content into the main branch.

Rename a local branch

1. Rename the local branch:

$ git branch -m <old_branch_name> <new_branch_name>

Of course, this only renames your copy of the branch. If the branch exists on the remote Git server, continue to the next steps.

2. Push the new branch to create a new remote branch:

$ git push origin <new_branch_name>

3. Delete the old remote branch:

$ git push origin -d -f <old_branch_name>Rename the current branch

When the branch you want to rename is your current branch, you don't need to specify the existing branch name.

1. Rename the current branch:

$ git branch -m <new_branch_name>

2. Push the new branch to create a new remote branch:

$ git push origin <new_branch_name>

3. Delete the old remote branch:

$ git push origin -d -f <old_branch_name>Delete local and remote branches using Git

As part of good repository hygiene, it's often recommended that you delete a branch after ensuring you have merged the content into the main branch.

Delete a local branch

Deleting a local branch only deletes the copy of that branch that exists on your system. If the branch has already been pushed to the remote repository, it remains available to everyone working with the repo.

1. Checkout the central branch of your repository (such as main or master):

$ git checkout <central_branch_name>

2. List all the branches (local as well as remote):

$ git branch -a

3. Delete the local branch:

$ git branch -d <name_of_the_branch>

To remove all your local topic branches and retain only the main branch:

$ git branch | grep -v main | xargs git branch -dDelete a remote branch

Deleting a remote branch only deletes the copy of that branch that exists on the remote server. Should you decide that you didn't want to delete the branch after all, you can re-push it to the remote, such as GitHub, as long as you still have your local copy.

1. Checkout the central branch of your repository (usually main or master):

$ git checkout <central_branch_name>

2. List all branches (local as well as remote):

$ git branch -a

3. Delete the remote branch:

$ git push origin -d <name_of_the_branch>Find the author of a remote topic branch using Git

If you are the repository manager, you might need to do this so you can inform the author of an unused branch that it should be deleted.

1. Checkout the central branch of your repository (such as main or master):

$ git checkout <central_branch_name>

2. Delete branch references to remote branches that do not exist:

$ git remote prune origin

3. List the author of all the remote topic branches in the repository, using the --format option along with special selectors (in this example, %(authorname) and %(refname) for author and branch name) to print just the information you want:

$ git for-each-ref --sort=authordate --format='%(authorname) %(refname)' refs/remotes

Example output:

tux  refs/remotes/origin/dev
agil refs/remotes/origin/main

You can add further formatting, including color coding and string manipulation, for easier readability:

$ git for-each-ref --sort=authordate \
--format='%(color:cyan)%(authordate:format:%m/%d/%Y %I:%M %p)%(align:25,left)%(color:yellow) %(authorname)%(end)%(color:reset)%(refname:strip=3)' \
refs/remotes

Example output:

01/16/2019 03:18 PM tux      dev
05/15/2022 10:35 PM agil     main

You can use grep to get the author of a specific remote topic branch:

$ git for-each-ref --sort=authordate \
--format='%(authorname) %(refname)' \
refs/remotes | grep <topic_branch_name>Get good at branching

There are nuances to how Git branching works depending on the point at which you want to fork the code base, how the repository maintainer manages branches, squashing, rebasing, and so on. Here are three articles for further reading on this topic:

• Explaining Git branches with a LEGO analogy, by Seth Kenlon
• My guide to using the Git push command safely, by Noaa Barki
• A guide to Git branching, by Kedar Vijay Kulkarni

Become an expert at the most common Git tasks for managing local and remote branches.

Image by:

Image by Erik Fitzpatrick. CC BY-SA 4.0

Git What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

A programmer's guide to GNU C Compiler Jayashree Hutt… Fri, 05/20/2022 - 03:00 Register or Login to like Register or Login to like

C is a well-known programming language, popular with experienced and new programmers alike. Source code written in C uses standard English terms, so it's considered human-readable. However, computers only understand binary code. To convert code into machine language, you use a tool called a compiler.

A very common compiler is GCC (GNU C Compiler). The compilation process involves several intermediate steps and adjacent tools.

Install GCC

To confirm whether GCC is already installed on your system, use the gcc command:

$ gcc --version

If necessary, install GCC using your packaging manager. On Fedora-based systems, use dnf:

$ sudo dnf install gcc libgcc

On Debian-based systems, use apt:

$ sudo apt install build-essential

After installation, if you want to check where GCC is installed, then use:

$ whereis gccSimple C program using GCC

Here's a simple C program to demonstrate how to compile code using GCC. Open your favorite text editor and paste in this code:

// hellogcc.c
#include
 
int main() {
        printf("Hello, GCC!\n");
return 0;
}

Save the file as hellogcc.c and then compile it:

$ ls
hellogcc.c

$ gcc hellogcc.c

$ ls -1
a.out
hellogcc.c

As you can see, a.out is the default executable generated as a result of compilation. To see the output of your newly-compiled application, just run it as you would any local binary:

$ ./a.out
Hello, GCC!Name the output file

The filename a.out isn't very descriptive, so if you want to give a specific name to your executable file, you can use the -o option:

$ gcc -o hellogcc hellogcc.c

$ ls
a.out  hellogcc  hellogcc.c

$ ./hellogcc
Hello, GCC!

This option is useful when developing a large application that needs to compile multiple C source files.

Programming and development Red Hat Developers Blog Programming cheat sheets Try for free: Red Hat Learning Subscription eBook: An introduction to programming with Bash Bash shell scripting cheat sheet eBook: Modernizing Enterprise Java Intermediate steps in GCC compilation

There are actually four steps to compiling, even though GCC performs them automatically in simple use-cases.

1. Pre-Processing: The GNU C Preprocessor (cpp) parses the headers (#include statements), expands macros (#define statements), and generates an intermediate file such as hellogcc.i with expanded source code.
2. Compilation: During this stage, the compiler converts pre-processed source code into assembly code for a specific CPU architecture. The resulting assembly file is named with a .s extension, such as hellogcc.s in this example.
3. Assembly: The assembler (as) converts the assembly code into machine code in an object file, such as hellogcc.o.
4. Linking: The linker (ld) links the object code with the library code to produce an executable file, such as hellogcc.

When running GCC, use the -v option to see each step in detail.

$ gcc -v -o hellogcc hellogcc.c Image by:

(Jayashree Huttanagoudar, CC BY-SA 4.0)

Manually compile code

It can be useful to experience each step of compilation because, under some circumstances, you don't need GCC to go through all the steps.

First, delete the files generated by GCC in the current folder, except the source file.

$ rm a.out hellogcc.o

$ ls
hellogcc.cPre-processor

First, start the pre-processor, redirecting its output to hellogcc.i:

$ cpp hellogcc.c > hellogcc.i

$ ls
hellogcc.c  hellogcc.i

Take a look at the output file and notice how the pre-processor has included the headers and expanded the macros.

Compiler

Now you can compile the code into assembly. Use the -S option to set GCC just to produce assembly code.

$ gcc -S hellogcc.i

$ ls
hellogcc.c  hellogcc.i  hellogcc.s

$ cat hellogcc.s

Take a look at the assembly code to see what's been generated.

Assembly

Use the assembly code you've just generated to create an object file:

$ as -o hellogcc.o hellogcc.s

$ ls
hellogcc.c  hellogcc.i  hellogcc.o  hellogcc.sLinking

To produce an executable file, you must link the object file to the libraries it depends on. This isn't quite as easy as the previous steps, but it's educational:

$ ld -o hellogcc hellogcc.o
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
ld: hellogcc.o: in function `main`:
hellogcc.c:(.text+0xa): undefined reference to `puts'

An error referencing an undefined puts occurs after the linker is done looking at the libc.so library. You must find suitable linker options to link the required libraries to resolve this. This is no small feat, and it's dependent on how your system is laid out.

When linking, you must link code to core runtime (CRT) objects, a set of subroutines that help binary executables launch. The linker also needs to know where to find important system libraries, including libc and libgcc, notably within special start and end instructions. These instructions can be delimited by the --start-group and --end-group options or using paths to crtbegin.o and crtend.o.

This example uses paths as they appear on a RHEL 8 install, so you may need to adapt the paths depending on your system.

$ ld -dynamic-linker \
/lib64/ld-linux-x86-64.so.2 \
-o hello \
/usr/lib64/crt1.o /usr/lib64/crti.o \
--start-group \
-L/usr/lib/gcc/x86_64-redhat-linux/8 \
-L/usr/lib64 -L/lib64 hello.o \
-lgcc \
--as-needed -lgcc_s \
--no-as-needed -lc -lgcc \
--end-group
/usr/lib64/crtn.o

The same linker procedure on Slackware uses a different set of paths, but you can see the similarity in the process:

$ ld -static -o hello \
-L/usr/lib64/gcc/x86_64-slackware-linux/11.2.0/ \
/usr/lib64/crt1.o /usr/lib64/crti.o \
hello.o /usr/lib64/crtn.o \
--start-group -lc -lgcc -lgcc_eh \
--end-group

Now run the resulting executable:

$ ./hello
Hello, GCC!Some helpful utilities

Below are a few utilities that help examine the file type, symbol table, and the libraries linked with the executable.

Use the file utility to determine the type of file:

$ file hellogcc.c
hellogcc.c: C source, ASCII text

$ file hellogcc.o
hellogcc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

$ file hellogcc
hellogcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb76b241d7d00871806e9fa5e814fee276d5bd1a, for GNU/Linux 3.2.0, not stripped

The use the nm utility to list symbol tables for object files:

$ nm hellogcc.o
0000000000000000 T main
                          U puts

Use the ldd utility to list dynamic link libraries:

$ ldd hellogcc
linux-vdso.so.1 (0x00007ffe3bdd7000)
libc.so.6 => /lib64/libc.so.6 (0x00007f223395e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2233b7e000)Wrap up

In this article, you learned the various intermediate steps in GCC compilation and the utilities to examine the file type, symbol table, and libraries linked with an executable. The next time you use GCC, you'll understand the steps it takes to produce a binary file for you, and when something goes wrong, you know how to step through the process to resolve problems.

Get a behind-the-scenes look at the steps it takes to produce a binary file so that when something goes wrong, you know how to step through the process to resolve problems.

Image by:

Opensource.com

Programming What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.