Mentor organizations announced for Google Summer of Code 2023!

After careful review, we are pleased to announce that 172 open source projects have been selected for Google Summer of Code (GSoC) 2023! This year we are excited to welcome 18 new organizations for their first year as part of the program.

Please see our program site to view the complete list of GSoC 2023 accepted mentoring organizations. We invite you to learn more about each organization on their GSoC program page, which includes reading through the project ideas that they are looking for GSoC contributors to work on this year.

Are you interested in being a GSoC Contributor?

The 2023 GSoC program is open to students and to beginners in open source software development. Contributor applications will open on Monday, March 20, 2023 at 18:00 UTC with a deadline of Tuesday, April 4, 2023 18:00 UTC to submit your application (including your project proposal).

The most successful applications come from contributors who start preparing now. We can’t say this enough—if you want to significantly increase your chances of being selected as a 2023 GSoC contributor, we recommend you prepare and communicate early. Below are some tips for prospective GSoC contributors to accomplish before the application period begins March 20th:

• Watch our new ‘Introduction to GSoC’ video to see a quick overview of the program, and view our Community Talks or Org Highlight Videos to get inspired and learn more about some projects that contributors have worked on in the past.
• Check out the Contributor Guide and Advice for Applying to GSoC doc.
• Review the list of accepted organizations here. We recommend finding two to four that interest you and reading through their project ideas lists.
• As soon as you see an idea that sparks your interest, reach out to the organization via their preferred communication methods (listed on their org page on the GSoC program site). The earlier you start the conversation, the better your chances of being accepted as a GSoC contributor.
• Talk with the mentors and community to determine if this project idea is something you would enjoy working on during the program. Find a project that excites you, otherwise it may be a challenging summer for you and your mentor.
• Use the information you received during your communications with the mentors and other org community members to write up your proposal.

You can find more information about the program on our website which includes a full timeline of important dates. We also urge anyone interested in applying to read the FAQ and Program Rules and watch some of our other videos with more details about GSoC for contributors and mentors.

A hearty welcome—and thank you—to all of our mentor organizations! We look forward to working with all of you during Google Summer of Code 2023.

By Stephanie Taylor, Program Manager – Google Open Source Programs Office

Supporting DDR4 and DDR5 RDIMMs in open source DRAM security testing framework

In 2021, Google and Antmicro introduced a platform for testing DRAM memory chips against the unfortunate side effect of the physical shrinking of memory chips—the Rowhammer vulnerability. The platform was developed to propose a radical improvement over the “security through obscurity” approach that was predominant in the industry; as both Antmicro and Google believe that the open source approach to mitigating security threats is a way towards accelerating developments in the field.

The framework was originally developed in the context of securing consumer-facing devices, using off-the-shelf Digilent Arty (DDR3, Xilinx Series7 FPGA) and Xilinx ZCU104 (DDR4, Xilinx UltraScale+ FPGA) boards, then followed by a dedicated open hardware board from Antmicro that allowed work on custom LPDDR4 modules. The framework has since helped discover a new attack method named Blacksmith and continues to provide valuable insights into how the security of both edge device and data center memory can be improved.

In constant development since then, the project has welcomed two more major elements to the ecosystem in order to enable testing of DDR4 Registered Dual In-Line Memory Modules (RDIMM)—commonly used in data centers as well as the newer DDR5 standard and continues to provide useful data.

Memory testing for data center use cases

To extend the Rowhammer tester support from consumer-facing devices to shared-compute data center infrastructure, Antmicro developed the data center DRAM tester board. We adapted this open source hardware-test platform from the original LPDDR4 board to enable Rowhammer and other memory security experiments with DDR4 RDIMMs using a fully configurable, open source FPGA-based DDR controller.

The data center DRAM Xilinx Kintex-7 FPGA based test board features:

• DDR4 RDIMM connector
• 676 pins FPGA (compared to the 484 for the LPDDR version)
• RJ45 Gigabit Ethernet
• Micro-USB console
• HDMI output connector
• JTAG programming connector
• MicroSD card slot
• 12 MBytes QSPI Flash memory
• HyperRAM—external DRAM memory that can be used as an FPGA cache

It’s worth mentioning that the RDIMM DDR4 memory (as opposed to the custom LPDDR4 modules designed for the original project) are generic and available off-the-shelf. This makes it easier for security researchers to get started with data center memory security research compared to edge devices using LPDDR.

The Data Center DRAM Tester board design has now been upgraded into revision 1.2, which brings new features for implementing even more complex DRAM testing scenarios. The 1.2 boards support a Power over Ethernet (PoE) supply option so the board can act as a standalone network device with data exchange and power-cycling done over a single Ethernet cable. This simplifies integration of the board in DRAM testing clusters and custom runners capable of doing hardware-in-the-loop testing.

The new revision of the board will support hot-swapping of the DRAM module under test, which should speed up testing of multiple DRAM modules without the need to power-cycle the tester. Finally, the new revision of the board will include power-measurement circuitry so it will be possible to compare the peak and average power consumption of DRAM while working with different DRAM refresh scenarios.

We are also working on a custom enclosure design suitable for desktop and networked installations.

Extending open source testing to DDR5

With DDR5 quickly becoming the new standard for data center memory, Antmicro and Google’s Platforms teams also set out to develop a platform capable of interfacing with DDR5 memories, again directly from a low-cost FPGA without a dedicated hard block. The resulting DDR5 tester platform follows the structure of the data center DDR4 tester, while expanding on functionality of the Serial Presence Detection, which monitors the power supply states and system health, or adjusting the circuitry for a nominal IO voltage of 1.1V.

Data center DRAM testing is part of Google’s and Antmicro’s belief in security through transparency. Both hyperscalers and a growing number of organizations who operate their own data centers increasingly embrace this perspective, and there is great value in providing them with a scalable, customizable, commercially supported open source platform that will help in collaborative research and mitigation of emerging security issues.

Rowhammer attacks, security threats, and countermeasures remain an active research area. With Google, Antmicro continues to adjust the Rowhammer test platform to most recent developments, opening the way for researchers and memory vendors to more sophisticated testing methods to enable testing of state-of-the-art memories used in data centers. This work stems from and complements other open source activities the companies jointly lead as members of RISC-V International and CHIPS Alliance, aimed at making the hardware ecosystem more open, secure and collaborative. If you’re interested in open source solutions for DRAM security testing and memory controller development, or more broadly, FPGA and ASIC design and verification, don’t hesitate to reach out to Antmicro at contact@antmicro.com.

By Michael Gielda – Antmicro

Kickstarting your tech writing career with open source

After graduating from University in the midst of a pandemic, I knew that I wanted to be a tech writer, but I wasn’t sure how to start. Google Season of Docs was the perfect way to launch my career; it let me work on my own terms and led to me starting my own business and to subsequent tech writing jobs in open source. I am currently working as a tech writer at Google and volunteering for documentation-related open source projects.

Should you join an open source project?

The charm (and challenge) of open source is that the line between creators and users becomes blurred. Do you wish that your beloved tool had that one feature you really need? You can add it yourself! Other users might support your feature request and may even help you build it. Before you know it, you’re part of a wonderful community bound together by passion.

People join open source projects for many reasons:

• They believe in the vision of a project and want to help build it
• They want to build professional and technical skills
• They are motivated by the possibility of hundreds—or even thousands—of people using their work

Life in open source as a tech writer

Many contributors in open source come from a software engineering background. They are great at building software, but they sometimes struggle with documentation. Through Google Season of Docs, open source projects can hire technical writers to help them create much-needed content. These technical writers are likely the first person in the project working exclusively on educational content—which comes with ups and downs.

The fun parts

As an open source technical writer, you will often be in close contact with your users. Through researching user needs, technical writers develop more empathy for the struggles of the users. Many tech writers (myself included) find that this closeness helps them write better.

Contributing to open source also allows you to create documentation in different contexts. For example, you might have authored content in a CMS in the past—diving into an open source project gives you the opportunity to explore a docs-as-code workflow. Another circumstance could be that you wrote documentation in a different industry and you want to see what it’s like to document software. Changing up your writing routine helps you find more creative ways to tackle problems for the next project you work on.

The hard parts

Documentation quality can be quite variable in open source. While some pages might be really useful, others might be outdated, don’t follow the user workflow, or cover way too much information on one page. Making sense of the existing documentation landscape can feel like a daunting task.

Most open source projects suffer from gaps in the documentation. Since open source developers are so enmeshed with their code and the project, they have a lot of context, and suffer from the “curse of knowledge”. It’s hard for contributors, or anyone who has held a position for a while, to remember what it was like to be a beginner or new to a project. When developers write documentation, their brain auto-completes what is missing on the page.

Because many people work on open source for personal satisfaction, you might experience pushback from people who are protective of their documentation. I find it helpful to view pushback as an act of caring about documentation. Take a closer look at why you are receiving pushback:

• Do the developers have concerns about your technical understanding?
• Are they not ready to let go of their document?
• Do you have different ideas of who the user is and what their goals are?

Understanding developer concerns can help you reach the shared goal of improved documentation.

Succeeding in Google Season of Docs and beyond

These tips helped me make the most of my Google Season of Docs experience.

Gain clarity

Take time in the beginning of the project to really understand the software, the user’s needs, and your docs landscape. (I allocated one third of my entire project timeline to gaining clarity.) Talk to your project mentors, do user research, and perform a content audit—this will help you understand the current structure and identify weaknesses and gaps in the content.

Keep your community in the loop

Open source communities attract contributors from all over the world—which means communication is usually asynchronous and in writing. Transparent communication is a must to keep your users (and potential co-creators) engaged. When they know what’s going on, it’s easier for them to chip in.

Deal with pushbacks

Transparent communications and a solid documentation plan go a long way towards addressing concerns. It’s easier to receive support if your team knows what you’re doing.

Build a professional support network

Find other tech writers to geek out with, especially if you’re the only technical writer in your project. Groups like Write the Docs and The Good Docs project are good places to find like-minded people to brainstorm and learn with.

I hope you find a project that interests you and the bandwidth to participate in Google Season of Docs. It was a worthwhile experience for me, helped me advance in my career, and I hope the same for you.

P.S. You can find a detailed write up of my work for Season of Docs ‘21 on my website.

By Tina Luedtke, Technical Writer – Google

Configure your private clouds using the Google Cloud VMware Engine IaC Foundations repository

Introduction

Google Cloud VMware Engine is a Google-managed VMware platform that customers can use to run their VMware workloads on Google Cloud. VMware Engine private clouds consist of VMware ESXi clusters that are managed by Google. Customers manage the virtual infrastructure of private clouds using VMware vCenter and VMware NSX-T for software-defined networking. The GCVE IaC Foundations code guides customers to automate the configuration of several layers of the infrastructure and virtualization stack, using infrastructure as code. This includes the integration of platform logging and monitoring with the Google Cloud Operations Suite, configurations such as VM folders, permissions and VM deployments in vCenter and network configurations in NSX-T, including subnets, firewalls, and load balancers.

The use of infrastructure as code for a VMware Engine Private Cloud offers multiple benefits, including:

1. Providing consistent and repeatable deployment templates which can be reused across SDLC environments to reduce human error and shorten configuration times.
2. Enabling continuous integration using GitOps workflows to improve collaboration between engineers and increase reliability in the release process.
3. Offering version control of configuration templates to track changes in the infrastructure and a simple method to revert changes to a previous configuration.

Technical Details

The Google Cloud VMware Engine IaC Foundations Github repository contains Terraform modules and sample code for maintaining VMware Engine, vCenter and NSX-T configurations using infrastructure as code. The repository is structured as follows:

├── examples
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
├── modules
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
└── stages
    ├── 01-privatecloud
    ├── 02a-nsxt
    ├── 02b-vcenter
    ├── 03-vms
    └── 04-load-balancing

The modules directory contains the Terraform IaC modules for GCVE (vCenter & NSX-T) resource types. Each module has a corresponding example in the examples directory. Modules and examples are meant to be discrete and function as the building blocks for managing GCVE at scale.

The stages directory contains sample deployments composed from modules for each of the different stages of the foundational deployment. These stages should be executed in the order they are listed. Stages may also be delegated to different teams within an organization depending on organizational roles and responsibilities. As an example, there may be a team that manages vCenter, while a Networking team manages NSX-T and each team has their own code repository for configuration management.

The individual stages deploy the following components:

Stage	Deployed sample Component(s)
01-privatecloud	Google Cloud Monitoring & Logging integration for GCVE
02a-nsxt	Virtual machine network segment North / south firewall (gateway firewall) East / west firewall (distributed firewall)
02b-vcenter	vCenter resource pools & folders vCenter role assignments
03-vms	Virtual machines
04-load-balancing	NSX-T Load balancing

Deployment Walkthrough

To deploy the sample stages you will need to clone the gcve-iac-foundations repository and have Terraform 1.3.x or later installed.

To deploy the stages proceed in order in the stages directory from 01-privatecloud until 04-load-balancing. In each directory perform the following:

• Copy terraform.tfvars.example to terraform.tfvars and customize any values as necessary
• Run `terraform init`, `terraform plan` and `terraform apply`

Each of the stages and examples contain reference terraform.tfvars files which can be used in the initial stages to test deployment and later customized to meet specific requirements.

As an example, the following Terraform configuration can be used to configure the NSX-T distributed firewall:

dfw_policies = [
  {
    display_name    = "dfw_allow_policy"
    sequence_number = 1
    rules = [
      {
        action             = "ALLOW"
        destination_groups = ["10.123.1.0/24"]
        source_groups      = []
        direction          = "IN_OUT"
        display_name       = "dfw-allow-ssh"
        logged             = false
        services           = ["SSH"]
      },
      {
        action             = "ALLOW"
        destination_groups = ["10.123.2.0/23"]
        source_groups      = ["10.200.1.0-10.200.1.128"]
        direction          = "IN_OUT"
        display_name       = "dfw-allow-dns"
        logged             = false
        services           = ["DNS"]
      },
    ]
  },
<…snip…>
]

Apply the Terraform configuration from a terminal using

terraform init // initialize the provider and modules
terraform plan // validate the expected Terraform configuration on the console
terraform apply // deploy the configuration in NSX-T

Try it yourself

Whether you consider using VMware Engine for your VMware workloads or you actively use the service already, give it a try and clone the repository into your environment and go through the provided deployment examples and stages of the repository. Review if you can automate any processes that you perform manually today using infrastructure-as-code and improve your VMware operations using the content from the foundations repository.

We would like to get your feedback! If you encounter any issues or you have any feedback or suggestions for improvement, create an issue directly on the repository on Github. We would also like to encourage you to create pull requests to the main branch if you like to become an active contributor. To get started, review how to contribute on Github.

By Konrad Schieban and Jason Steenblik – Google Cloud

Acknowledgments:

Thank you to the following team members who made this solution possible: Kumari Renuka, Ashwin Naik, Leandro Carracedo, Eric Danan, and Umesh Kumhar from Google Cloud.

Mentor organization applications are open for Google Summer of Code 2023!

We are excited to announce that open source projects and organizations can now apply to participate as mentor organizations in the 2023 Google Summer of Code (GSoC) program. Applications for organizations will close on February 7, 2023 at 18:00 UTC.

As 2023 begins, so does our 19th year of Google Summer of Code! Last year, we had a few updates to the program that will continue for the 2023 program year. Our most noted change coming in 2023 is that we are expanding the program to be open to students and to beginners in open source software development. We are also continuing our increased flexibility in the length of the projects—offering 175 and 350-hour projects—and the ability to extend the program from the standard 12 weeks up to 22 weeks.

Does your open source project want to learn more about becoming a mentor organization? Visit the program site and read the mentor guide to learn what it means to be a mentor organization and how to prepare your community (hint: have plenty of excited, dedicated mentors and well thought out project ideas!).

We welcome all types of organizations and are very eager to involve first-timers with a 2023 goal of welcoming 30+ new orgs into GSoC. We encourage new organizations to get a referral from experienced organizations that think they would be a good fit to participate in GSoC.

The open source projects that participate in GSoC as mentor organizations do all kinds of interesting work in security, cloud, development tools, science, medicine, data, media, and more! Projects can range from being relatively new (about 2 years old) to well established projects that started over 20 years ago. We welcome open source projects big, small, and everything in between.

One thing to remember is that open source projects wishing to apply need to have a solid community; the goal of GSoC is to bring new contributors into established and welcoming communities. While you don’t have to have 50+ community members, the project also can’t have as few as three people.

You can apply to be a mentor organization for GSoC starting today on the program site. The deadline to apply is February 7, 2023 at 18:00 UTC. We will publicly announce the organizations chosen for GSoC 2023 on February 22nd.

Please visit the program site for more information on how to apply and review the detailed timeline for important deadlines. We also encourage you to check out the Mentor Guide, our new ‘Intro to Google Summer of Code’ video, and our short video on why open source projects are excited to be a part of the GSoC program.

Good luck to all open source mentor organization applicants!

By Stephanie Taylor, Program Manager – Google Open Source Programs Office