Language Selection

English French German Italian Portuguese Spanish

Android

US Sanctions Against Chinese Android Phones, LWN Report on Eelo

Filed under
Android
  • A new bill would ban the US government from using Huawei and ZTE phones

    US lawmakers have long worried about the security risks posed the alleged ties between Chinese companies Huawei and ZTE and the country’s government. To that end, Texas Representative Mike Conaway introduced a bill last week called Defending U.S. Government Communications Act, which aims to ban US government agencies from using phones and equipment from the companies.

    Conaway’s bill would prohibit the US government from purchasing and using “telecommunications equipment and/or services,” from Huawei and ZTE. In a statement on his site, he says that technology coming from the country poses a threat to national security, and that use of this equipment “would be inviting Chinese surveillance into all aspects of our lives,” and cites US Intelligence and counterintelligence officials who say that Huawei has shared information with state leaders, and that the its business in the US is growing, representing a further security risk.

  • U.S. lawmakers urge AT&T to cut commercial ties with Huawei - sources

    U.S. lawmakers are urging AT&T Inc, the No. 2 wireless carrier, to cut commercial ties to Chinese phone maker Huawei Technologies Co Ltd and oppose plans by telecom operator China Mobile Ltd to enter the U.S. market because of national security concerns, two congressional aides said.

    The warning comes after the administration of U.S. President Donald Trump took a harder line on policies initiated by his predecessor Barack Obama on issues ranging from Beijing’s role in restraining North Korea to Chinese efforts to acquire U.S. strategic industries.

    Earlier this month, AT&T was forced to scrap a plan to offer its customers Huawei [HWT.UL] handsets after some members of Congress lobbied against the idea with federal regulators, sources told Reuters.

  • Eelo seeks to make a privacy-focused phone

    A focus on privacy is a key feature being touted by a number of different projects these days—from KDE to Tails to Nextcloud. One of the biggest privacy leaks for most people is their phone, so it is no surprise that there are projects looking to address that as well. A new entrant in that category is eelo, which is a non-profit project aimed at producing not only a phone, but also a suite of web services. All of that could potentially replace the Google or Apple mothership, which tend to collect as much personal data as possible.

Android Support Removed from Intel Graphics Driver Debugging Tool for Linux

Filed under
Android
Linux

For those unfamiliar with intel-gpu-tools, it's a collection of tools for GNU/Linux distribution that allows the debugging the official Intel graphics driver for Intel GPUs. Tools include a GPU hang dumping program, performance microbenchmarks for regression testing the DRM, as well as a performance monitor.

The latest release, intel-gpu-tools 1.21, adds quite a bunch of changes, including automatic loading of DRM modules when opening a DRM device, much-improved GPU quiescing code to more thoroughly flush pending work and old data, as well as production support for the Meson build system while automake is still kept around.

Read more

SBC kit runs Linux on a quad -A53 i.MX8M SoC

Filed under
Android
Linux

CompuLab released details and pricing for its “SBC-iMX8 Evaluation Kit.” The sandwich-style SBC includes an i.MX8M-based CL-SOM-iMX8 module, and provides WiFi, BT, GbE, USB 3.0, PCIe, HDMI 2.0, and more.

Earlier this week when we reported on CompuLab’s CL-SOM-iMX8 compute module, there were only a few details on the board’s SBC-iMX8 Evaluation Kit. Now, Compulab has posted a product page and a price, which for single units including the COM, start at $415.

Read more

Devices: Raspberry Pi and Android

Filed under
Android
Linux
Syndicate content

More in Tux Machines

Linux Kernel Development

  • New Sound Drivers Coming In Linux 4.16 Kernel
    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle. The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.
  • Varlink: a protocol for IPC
    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1. The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.
  • Statistics for the 4.15 kernel
    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall. This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.
  • A new kernel polling interface
    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance. On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

  • Another Face to Face: Email Changes and Crypto Policy
    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended. One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre
    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure. For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.
  • Addressing Meltdown and Spectre in the kernel
    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly. First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.
  • Is it time for open processors?
    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea. Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.
  • Notes from the Intelpocalypse
    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel. All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks. A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.

US Sanctions Against Chinese Android Phones, LWN Report on Eelo

  • A new bill would ban the US government from using Huawei and ZTE phones
    US lawmakers have long worried about the security risks posed the alleged ties between Chinese companies Huawei and ZTE and the country’s government. To that end, Texas Representative Mike Conaway introduced a bill last week called Defending U.S. Government Communications Act, which aims to ban US government agencies from using phones and equipment from the companies. Conaway’s bill would prohibit the US government from purchasing and using “telecommunications equipment and/or services,” from Huawei and ZTE. In a statement on his site, he says that technology coming from the country poses a threat to national security, and that use of this equipment “would be inviting Chinese surveillance into all aspects of our lives,” and cites US Intelligence and counterintelligence officials who say that Huawei has shared information with state leaders, and that the its business in the US is growing, representing a further security risk.
  • U.S. lawmakers urge AT&T to cut commercial ties with Huawei - sources
    U.S. lawmakers are urging AT&T Inc, the No. 2 wireless carrier, to cut commercial ties to Chinese phone maker Huawei Technologies Co Ltd and oppose plans by telecom operator China Mobile Ltd to enter the U.S. market because of national security concerns, two congressional aides said. The warning comes after the administration of U.S. President Donald Trump took a harder line on policies initiated by his predecessor Barack Obama on issues ranging from Beijing’s role in restraining North Korea to Chinese efforts to acquire U.S. strategic industries. Earlier this month, AT&T was forced to scrap a plan to offer its customers Huawei [HWT.UL] handsets after some members of Congress lobbied against the idea with federal regulators, sources told Reuters.
  • Eelo seeks to make a privacy-focused phone
    A focus on privacy is a key feature being touted by a number of different projects these days—from KDE to Tails to Nextcloud. One of the biggest privacy leaks for most people is their phone, so it is no surprise that there are projects looking to address that as well. A new entrant in that category is eelo, which is a non-profit project aimed at producing not only a phone, but also a suite of web services. All of that could potentially replace the Google or Apple mothership, which tend to collect as much personal data as possible.

today's howtos