opensource.google.com

Menu

Google Blocks is now Open Source

Tuesday, July 16, 2024

In 2017, we shared Google Blocks with the world as a simple, easy and fun way to create 3D objects and scenes, using the new wave of VR headsets of the day.

We were thrilled to see the surprising, inventive and beautiful assets you all put together with Google Blocks, and continue to be impressed by the enthusiasm of the community.



We now wish to share the code behind Google Blocks, allowing for novel and rich experiences to emerge from the creativity and passion of open source contributors such as the Icosa Foundation, who have already been doing wonderful work with Tilt Brush, which we open-sourced in 2021.


"We're thrilled to see Blocks join Tilt Brush in being released to the community, allowing another fantastic tool to grow and evolve. We can't wait to take the app to the next level as we have done with Open Brush." 
– Mike Nisbet, Icosa Foundation

What’s Included

The open source archive of the Blocks code can be found at: https://github.com/googlevr/blocks

Please note that Google Blocks is not an actively developed product, and no pull requests will be accepted. You can use, distribute, and modify the Blocks code in accordance with the Apache 2.0 License under which it is released.

The currently published version of Google Blocks will remain available in digital stores for users with supported VR headsets. If you're interested in creating your own Blocks experience, please review the build guide and visit our github repo to access the source code.

Thank you all for coming on this journey with us so far, we can’t wait to see where you take Blocks from here.

By Ian MacGillivray – Software Engineer, on behalf of the Google Blocks team.

Bounds Checking Flexible Array Members

Tuesday, July 9, 2024

Buffer overflows are the cause of many security issues, and are a persistent thorn in programmers' sides. C is particularly susceptible to them. The advent of sanitizers mitigates some security issues by automatically inserting bounds checking, but they're not able to do so in all situations—in particular for flexible array members, because their size is known only at runtime.

The size of a flexible array member is typically opaque to the compiler. The alloc_size attribute on malloc() may be used for bounds checking flexible array members within the same function as the allocation. But the attribute's information isn't carried with the allocated object, making it impossible to perform bounds checking elsewhere.

To mitigate this drawback, Clang and GCC are introducing1 the counted_by attribute for flexible array members.


Specifying a flexible array member's element count

The number of elements allocated for a flexible array member is frequently stored in another field within the same structure. When applied to the flexible array member, the counted_by attribute is used by the sanitizer—enabled by -fsanitize=array-bounds—by explicitly referencing the field that stores the number of elements. The attribute creates an implicit relationship between the flexible array member and the count field enabling the array bounds sanitizer to verify flexible array operations.

There are some rules to follow when using this feature. For this structure:

struct foo {
	/* ... */
	size_t count; /* Number of elements in array */
	int array[] __attribute__((counted_by(count)));
};
  • The count field must be within the same non-anonymous, enclosing struct as the flexible array member.
  • The count field must be set before any array access.
  • The array field must have at least count number of elements available at all times.
  • The count field may change, but must never be larger than the number of elements originally allocated.

An example allocation of the above structure:

struct foo *foo_alloc(size_t count) {
  struct foo *ptr = NULL;
  size_t size = MAX(sizeof(struct foo),
                    offsetof(struct foo, array[0]) +
                        count * sizeof(p->array[0]));

  ptr = calloc(1, size);
  ptr->count = count;
  return ptr;
}

Uses for fortification

Fortification (enabled by the _FORTIFY_SOURCE macro) is an ongoing project to make the Linux kernel more secure. Its main focus is preventing buffer overflows on memory and string operations.

Fortification uses the __builtin_object_size() and __builtin_dynamic_object_size() builtins to try to determine if input passed into a function is valid (i.e. "safe"). A call to __builtin_dynamic_object_size() generally isn't able to take the size of a flexible array member into account. But with the counted_by attribute, we're able to calculate the size and improve safety.


Uses in the Linux kernel

The counted_by attribute is already in use in the Linux kernel, and will be instrumental in catching issues like integer overflows, which led to a heap buffer overflow. We want to expand its use to more flexible array members, and enforce its use in the future.


Conclusion

The counted_by attribute helps address a long-standing fortification road block where the memory bounds of a flexible array member couldn't be determined by the compiler, thus making Linux, and other hardened applications, less exploitable.

1In Clang v18.0.0 and GCC v15.0.0.

By Bill Wendling, Staff Software Engineer

Google Open Source Peer Bonus program recognizes first group of 2024 recipients

Monday, June 24, 2024

We are excited to announce the first group of winners for the 2024 Google Open Source Peer Bonus Program! This program is designed to recognize open source contributors who have been nominated by Google employees for their exceptional contributions to open source projects.

It is worth reiterating the importance of open source to solving real-world problems for everyone. Open collaboration via open source allows for increased innovation and sustainability and provides infrastructure that countless projects and companies rely on. It is also important to note that oftentimes, open source progress made by the work of contributors and maintainers is overlooked. To the recipients of this award: whether this work is a part of your salaried role or a free time passion project, we hope that this small token of appreciation for your commitment spurs you to continue this work.

This cycle’s Open Source Peer Bonus Program received 159 nominations and the 130 winners reside in 25 different countries with work spanning 78 projects. As always, this reflects the program’s global reach and just a fraction of the enormous impact of open source software.

We would like to extend our congratulations to the winners! Included below are those who have agreed to be named publicly.

Winner

Open Source Project

Brandon Roberts

Analogjs

Matthieu Riegler

Angular

Thomas Laforge

Angular Challenges OSS project

Sergio Sastre

AOSP and Android-screenshot-testing-playground

Dongjoon Hyun

Apache Spark

Ellie Huxtable

Atuin

Fabian Meumertzheim

Bazel

Mark Friedman

Blockly

Kevin O'Reilly

CAPEv2

Ed Page

cargo

Daniel Olabemiwo

chakraUI - Vue

Sylvain Hellegouarch

chaostoolkit

Himanshu Singh

Charty

Daniel Kolesa

Chimera Linux

Helmut Januschka

Chromium

Botond Ballo

clangd

Best Ibitoye-Rotimi

ClassroomIO.com

Vamsi Avula

CLI Mate

Dinko Osrecki

Cloud SQL Node.js Connector

Kevin Petit

clvk

Max Heller

Comprehensive Rust

Derek McGowan

containerd

Toru Komatsu

containerd/runwasi

Pierre Rousselin

Coq

Pierre Roux

Coq

Chris O'Haver

CoreDNS

Daniel Stenberg

curl

Pokey Rule

Cursorless

Martin Prpic

cvelint

Jerry Gamblin

cvelint-action

Simon Binder

Dart

Niraj Kumar

Data Ingestion Framework (DIF)

David Vallejo

Data Layer Helper

Hajime Hoshi

Ebitengine

Dario Nieuwenhuis

Embassy

Hans de Goede

Fedora IPU6 camera support

Kate Hsuan

Fedora IPU6 camera support

Lukas Klingsbo

Flame

Alex Li

Flutter

Bartek Pacia

Flutter

Dario Klepoch

Flutter TensorFlow Lite Plugin

Richard Rausch

flutter/flutter - clean up memory leaks

Kostiantyn Sokolovskyi

flutter/flutter - clean up memory leaks

Jaydip Gabani

Gatekeeper

Qiusheng Wu

geemap

Sam James

Gentoo Hardened

Sean Liao

Go

Quim Muntal

Go

Rhys Hiltner

Go

Nick Ripley

Go

Felix Geisendörfer

Go

Cuong Manh Le

Go

Dominik Honnef

Go

Tomislav Turek

Go Linux nftables package

Mauri de Souza Meneguzzo

golang/go

KJ Tsanaktsidis

Google Protobuf

Viktor Blomqvist

Gopls, the Go language server

Antoine Tollenaere

gRPC

Jay Lee

gRPC-rs

Ridwan Hoq

GUAC

Naveen Srinivasan

GUAC

Marco Rizzi

GUAC

Jonathan Behrens

image-rs/image-png

Kilian Schulte

Jaspr

Kevin Hannon

JobSet

Yuya Nishihara

Jujutsu VCS (jj)

Diego Calleja

kernelnewbies.org

Kai-Hsun Chen

kuberay

Filip Křepinský

Kubernetes

David Eads

Kubernetes

Marko Mudrinić

Kubernetes

Yuki Iwai

Kueue

Dmytro Liubarskyi

LangChain4j

Iryna Liubarska

LangChain4j

Volodymyr Agafonkin

Leaflet

Yuan Tong

libavif

Laurent Pinchart

libcamera

Eli Schwartz

liblc3

Jason Gunthorpe

Linux Kernel

Christian Brauner

Linux Kernel

Jan Kara

Linux Kernel

Kuniyuki Iwashima

Linux Kernel

Sebastien Anceau

linuxloops and brunch

Yifan Zhu

llvm-libc

Anton Korobeynikov

llvm/llvm-project

Pierre-Yves David

Mercurial

Marcus Ilgner

MockK

Palak Sharma

moja-global/ui-library

Pony Cui

MPFlutter

Jim Crist-Harif

msgspec

Amadeusz Winogrodzki

next-firebase-auth-edge

Amarachi Johnson-Ubah

Open Terms Archive

Mehdi Saligane

OpenFASOC

Franco Fichtner

OPNsense core

Justin Nguyen

Oppia

Remko Popma

PicoCLI

Andres Freund

postgres

Caitlin Hudon

R-Ladies Austin, Data Mishaps Night (data + ML community online organizing)

Thulio Ferraz Assis

rules_python

Ignas Anikevicius

rules_python

Fridtjof Stoldt

Rust / Clippy

Caleb Zulawski

rust-lang/portable-simd

Dmitry Dygalo

Schemathesis

Pratim Bhosale

SurrealDB

Geoff Rich

SvelteKit

Lonami (unknown)

Telethon

Mayank Raunak

TensorFlow

Svetlana Novikova

The Good Docs Project

Saul Pwanson

VisiData

Etienne Dilocker

Weaviate

Mitsunari Shigeo

xbyak

Tomáš Janoušek

XMonad

Lasse Collin

xz

Zeeshan Ali Khan

zbus


We are incredibly proud of all of the nominees for their outstanding contributions to open source, and we look forward to seeing even more amazing contributions in the remainder of 2024 and years to come!

By Mike Bufano, Google Open Source Peer Bonus Program Lead

.