Linux on the Lenovo Y740 Legion (2019)

It’s easy.

No, really, it is. There’s a couple gotchas and some minor inconveniences (probably self-induced in my case), but provided you didn’t do anything particularly unusual with the system configuration at purchase, it should work.

First, I want to preface this with a brief overview of my configuration. I selected one with an NVMe SSD for its primary drive and a mechanical SATA drive for the secondary. I did not select one with Optane and with good reason, but I’ll get to that in a moment. All things considered, it’s a fairly banal, boring configuration with the exception of some of the features new to the 2019 lineup (notably the Corsair RGB keyboard and configurable fan LEDs). Interestingly, the behavior of this system’s EFI isn’t especially novel or noteworthy. It just works.

Caveat emptor: The configuration I discuss in this post may not work for you. I made decisions specific to how I wanted to use this system and performed some tasks manually to avoid overwriting defaults that shipped with the laptop. I’m also using Arch and other distros may present challenges specific to the software they ship or the utilities they package. Always back up any important files and do not perform these steps if you’re unwilling to lose data. I didn’t, but I’d only just gotten the laptop a couple days prior. Had I been using it for some months, I might have performed these steps differently. Some may also question why I didn’t perform a clean install of Windows; I considered it, but I didn’t feel the need to do so.

Now to the meat of the process: Before I started, I made certain to have available two USB sticks (both bootable): One with the Arch ISO image, and the other with a bootable Windows 10 installation via the Media Creation Toolkit. The latter was in my pile of tools in the event things went south and I needed to reinstall completely.

When booting to Linux on the Y740, you’ll note that the NVMe drive is not visible from Linux. This appears to be due to the storage configuration in BIOS. By default, it’s set to Intel’s Rapid Storage Technology; switching it to AHCI resolves the issue. One of the curious things to note when changing this configuration is the ominous warning that applying a different setting will delete all data on attached disks. I found this isn’t the case, but this is also why I’d recommend against selecting a model with Optane installed. I’m not certain on this point–you should certainly do your own research–but I believe with Optane installed, BIOS transparently configures it as a drive cache. Changing this on such a system may cause data corruption which is possibly what the warning implies. (The help text for this setting also mentions it’s specifically for Optane-equipped systems, hence my speculation.)

Once the drives were configured to use AHCI, the NVMe disk was accessible via Arch, and I proceeded to image it to the mechanical storage drive (using dd, of course). This image was then moved to permanent storage on my other systems in the event I did something incredibly stupid.

I look at it this way: If I didn’t have it available, I can almost guarantee I probably would have done something stupid. Always keep a backup!

(Speaking of stupid: This section is somewhat intentionally out of order but necessary for the story to flow; read below for potential video issues, because you will encounter them.)

Now, at this point, I had two choices. My initial thought was to partition the drives accordingly, and reinstall Windows completely. This would have been the ideal situation, but I wanted to save some time (and use the system in its stock state, minus some annoying cruft like McAfee). So, the next choice was to shrink the volumes on the SSD and the storage drive to roughly half. I gave Windows somewhat more storage, because it’s Windows, and because I plan to use this as a casual gaming system in addition to doing work. Doing so is easy enough: To resize the NTFS volumes, go to Computer Management -> Storage -> Disk Management. Then, you’re only a reboot away from getting started.

This is the easy part.

With the partitions resized, and a USB stick in hand, I feverishly pressed F12 to bring up the boot device selection screen–and promptly noticed that the USB stick wasn’t anywhere to be found. After unplugging it and putting it back in, BIOS appeared satisfied enough to present me with it, and off I went. I didn’t notice this with another stick I was using, and I had some difficulty replicating the problem. I’m not sure if this is a fault with the USB flash drive I had the Arch ISO written to or whether it’s just an idiosyncrasy of this BIOS. Either way, things appeared to work great…

Until the stick booted, that is.

Apparently the nouveau drivers that ship with Arch don’t work with the GeForce 2060 particularly well. I was greeted with what looked like vague video corruption and a line roughly one pixel high that appeared to be the bottom strip of whatever text was printed to the screen. Bummer. Rebooting, pressing F2, and getting into BIOS to examine whatever other configurations might help seemed to be my only salvation. Without much clue what else to pick, I noticed the graphics configuration had two states: Discrete graphics (that is the NVIDIA card) and “switchable graphics.” I knew from helping my girlfriend with her now-crippled Acer that the “switchable graphics” setting likely allowed the system to select between the integrated Intel UHD graphics on the CPU die and the discrete (NVIDIA) card; my theory at this point was to presume that doing so would allow Linux to boot up using the Intel chipset, hopefully avoiding the video corruption immediately after the kernel loaded up.

It worked, and from here we could progress.

The Arch installation was fairly pedestrian from this point: Setup the free space with partitions (I went with /boot and root on the SSD, although I should have left them merge–more on this in a moment–and the mechanical drive got a /storage mount point and swap), format as appropriate, install, configure, and… done!

Just kidding. That last part should be cry while you figure out how you want to setup your boot loader. You see, I’ve rarely used EFI systems outside virtualization. All of my systems are pre-2014-ish, and the one or two I’ve had the (dis)pleasure of poking at were all Windows machines. So, what are we to do?

(Aside: Wiping my girlfriend’s system and installing Linux would probably end with my face on a milk carton.)

First thing’s first: We need to figure out the time. No, I don’t mean how long the whole process had taken up to this point! I quite literally mean the time. One of the pain points dual booting Windows and Linux is how to handle the system clock. Once upon a time (sorry), Linux would begrudgingly chug along with the system clock configured to local time. This is a terrible idea, and I still have no idea why Windows insists, but fortunately, you can change Windows’ behavior easily enough. However, doing so requires the foresight to change this setting before getting started–something I didn’t have because I’m stupid and it only occurred to me when I got to the point of configuring the clock. Perhaps you’ll be luckier. You’re reading this after all!

Now, where were we? Oh, right! The bootloader. This is one of the deficiencies with using Linux on newer systems. Generally speaking, EFI, UEFI, or whatever your motherboard manufacturer has decided to call it, requires special attention that we Linux users haven’t had to give to boot loading since the 2000s. No, I wouldn’t use grub either–it does apparently have EFI support, but I have painful memories getting it working under VirtualBox with EFI enabled. Perhaps this is a VirtualBox-specific issue, but I’m inclined to believe we’re better off using tools designed for a specific purpose. In this case, rEFInd.

I won’t pretend to be a subject matter expert. I’ve never used rEFInd before. The Arch Linux wiki does have fantastic resources that can help you get started, but the thing I noticed with my particular configuration is that special attention had to be placed on configuring the OS declarations in esp/EFI/refind/refind.conf. If you’re following along at home, you should at least read this section on UEFI and the entry on rEFInd.

For my system, I did not follow the automatic installation with refind-install, because I didn’t want to overwrite the default EFI boot entry. Thus, I followed the manual installation process by copying rEFInd into the EFI system partition. Note that this alone is not enough to get rEFInd to work with the Y740’s BIOS. I’m not certain whether this is due to a step I’d skipped earlier in the installation or whether it’s an artifact of the manual install, but I found the only way the Lenovo BIOS would see rEFInd even if it’s in the EFI system partition is to configure the boot order via efibootmgr –bootorder 0004,0009,2001,2002,2003. I assume this should just work, but nothing I did would force the BIOS to recognize rEFInd (with the ID 0009). Changing the boot order did work, however, and with Windows (0004) as the primary–temporarily at least–and rEFInd (0009 on my system) as the secondary, I learned that BIOS had been forcibly configured to see rEFInd allowing me to change the UEFI boot order accordingly.

I also discovered that I could not get rEFInd to recognize the /boot/refind_linux.conf configuration. I’ve not investigated why, but I suspect it’s either due to my choice of partitioning (remember, I’m using a separate /boot and root!) or misunderstanding of rEFInd. However, configuring Arch via esp/EFI/refind/refind.conf has worked just fine. I should also note that by esp in the former example and above paragraphs, I mean the EFI System Partition. I mounted this (/dev/nvme0n1p1 on my system) to /boot/efi for ease of access. I’d suggest doing the same if you plan on going down this route.

Finalizing the Linux installation was relatively painless once the bootloader struggle was resolved, and I had NFS plus KDE working more or less out of the box. The system does quite well under Linux thusfar, although I’ve yet to configure wireless networking. I suspect the wireless NIC will work fine: I can see the card in ip link and the ridiculously named “Killer 1550i” cards are, as far as I know, simply rebranded Intel 9560NGW chips.

There is some unfinished business, and I’ve encountered at least one or two teething problems. First, this configuration doesn’t address secure boot. I was primarily focused on getting Linux working rather than working with secure boot. I’m hopeful this won’t be especially difficult, and from what I’ve read it appears the process is relatively straightforward. I’m planning on going the machine owner’s route with regards to kernel signing, with further plans to automate the process in a pacman hook. I’ve also noticed the wired network didn’t come up automatically in spite of being enabled via systemd (I prefer using systemd network configurations via /etc/systemd/network over NetworkManager), and there’s a large amount of i2c_hid spam in the journal. I suspect this may have something to do with some of the peripherals in the system (touchpad? wireless mouse?).

I’ll eventually write a part two once I get some of the remaining issues resolved, along with documenting whatever else I may encounter. If you’re using Linux and just bought one of these systems, please don’t feel overwhelmed with the installation process. Just be cautious, think things through, and have a plan of attack. Don’t forget to back things up, too. Oh, and as much as I don’t like Windows 10’s Microsoft account option, I would recommend logging in with one at least once because it ties the software license for that machine to your account. If you decide to reinstall Windows, this is a good thing, in my opinion!

No comments.
***

VPNs are No Panacea

I sometimes encounter the question “should I use a VPN?” with the inevitable shower of comments along the lines of “yes, it’ll make you more secure!” or “it’ll protect your privacy!” Occasionally, I see VPNs recommended as a solution against doxxing, such as when someone comments about their profession or business, competitors, or potential employers. Perhaps someone in industry has quipped about sending “anonymous” emails criticizing a particular organization or offered unsavory political opinions that would otherwise get them fired.

First, I should state that I am no security expert. I just happen to write software, and I have a vague curiosity into the world of information security. I enjoy reading the opinions of individuals who are considered experts in the field, and they almost uniformly warn of the same folly: VPNs are no panacea!

I think this advice is offered as therapeutic more than curative. In particular, it seems plausible users attracted to VPNs may place unwarranted trust in the software and provider, engaging in activities that suggest a degree of carelessness. Caution is nevertheless a desirable trait even under the warm embrace of cryptography. I’ll explain why.

A VPN may be useful to disguise your activity if you’re posting on Twitter, and you wish to avoid the danger of clicking on links that may be able to collate information about your activities or track usage behavior. VPNs may also provide some limited protection if you’re prone to torrenting your entertainment (up to a certain dollar amount, after which legal recourse against you becomes economically viable–maybe even necessary). However, even in the latter case, use of VPNs is of dubious utility, and they may not always keep you anonymous. Just this month (April 2019), NordVPN has been the subject of increased scrutiny over sending information to a series of unusual domains (billed as an anti-censorship strategy). Three months ago, NordVPN was also accused of tracking its users. None of this is surprising. Usage of a VPN is surrendering your privacy to a single firm (in most cases) in the hopes they will protect you from others doing naughty things with your browsing habits while simultaneously doing nothing of the sort themselves.

Nota bene: This behavior isn’t limited to NordVPN. They’re simply one of the most popular providers and therefore examined by more people with an equivalent increase in negative press. Regardless of intent, I find I can’t fault them for running analytic tracking on their user base: There are cases where traffic analysis (latency, throughput, timeouts, etc) may be useful for providing better quality-of-service and improving customer experience. In the event of an endpoint failure, I’m sure such analysis can be incredibly helpful re-routing packets toward other endpoints within a margin of acceptable latency. If the unusual domains their applications have directed traffic to this month is an anti-censorship countermeasure, I have to commend them for a bold strategy, even if it makes a few users nervous. To be clear: I neither endorse NordVPN nor am I overly critical of their decisions. I don’t care either way. I don’t use VPNs.

Now we can get to the meat of this discussion.

I believe the most important consideration as a user of a VPN service is to quantify your threat model. To illustrate, let’s take an example from earlier: For most people, doxxing isn’t a significant threat. Those at greatest risk often draw attention to themselves, either deliberately through their actions (whistle-blowers), or through online interactions (gaming, comments, etc.) that turn sour. Some may be victims of cyberstalking. In these cases, a VPN may be useless, because the victims often post sufficient information online to identify who they are, where they live, and numerous other details about their lives that a determined third party can piece together. Simply put: VPNs aren’t magic and they cannot protect you from yourself.

For most of us, our opinions and online interactions aren’t important or interesting enough to attract attention. If you think your opinions are interesting enough to be the target of a harassment campaign, then perhaps a VPN may be useful, but it isn’t the only tool you should rely on. To put it another way, if you’re afraid you might be identified online, you must firewall everything about your life that may be exposed through writing, your interactions with other people, and the media you post.

Ask yourself this question: What’s your threat model?

Most of the people I’ve spoken with who espouse the use of a VPN do so because they’re concerned about their identity being leaked, they may worry about employers identifying them online, they don’t want to become targets of harassment, or they simply wish to share politically unpopular opinions online that might draw the ire of one group or another (this may cross over into any of the prior points). As a free speech advocate, I can sympathize with their desire for further anonymity; losing your job because you’re the subject of a targeted harassment campaign is the antithesis of a free society. Neither should people be subject to hecklers or harassment, especially of the sort that crosses over from the online world to their front doorstep. Unfortunately, this is the world we live in.

A VPN isn’t going to provide unlimited protection against adversaries, and neither will a VPN protect users from disseminating information about themselves to interested but malevolent third parties. They can provide an additional layer of security when using Internet connections in a public location (airports, hotels, coffee shops, etc.), and they may be able to circumvent regional restrictions on entertainment or information (Google, YouTube, Netflix) by the state or licensing institutions. You should not expect a VPN to keep you completely anonymous, but they may be useful as part of a defense-in-depth strategy.

However, cautious use of the Internet can bring you 80% of the way toward a safer online presence. In particular: Don’t click links you don’t trust; avoid sharing secure information with services that are not offered via TLS (HTTPS); if you reply to an unknown third party via email, be cautious of using SMTP with your provider (this may divulge your client IP) and stick with the web or mobile interfaces; and don’t post information about yourself you don’t want publicly accessible. You may not have a choice in some cases, depending on your line of work, so this advice may not be applicable. I do believe it is broadly useful for the majority of people. Take heed.

There are limitations to VPNs that less technologically-inclined consumers may not be aware of. Key to understanding this is to understand the technology behind VPNs (typically IPsec with some authentication layer) and their history as a tool to extend company or school network boundaries off-premise, providing employees and students a means of connecting to internal services. It was never designed as a mechanism preventing the controlling institution (in this case the VPN provider) from classifying or logging traffic. Partial anonymity is a useful side effect but it wasn’t the design goal. Neither was complete security.

VPNs can have surprising utility if your adversary is intermediate tracking, or you don’t trust your ISP. Providers like Comcast have demonstrated this by injecting advertisements into sites their users visit, and others have been accused of using traffic analysis to track user behavior, possibly for targeted advertising. VPNs can protect against this threat by acting as a secure tunnel between your computer and your VPN provider’s endpoint.

Before I conclude this post, I should leave my readers with some particularly interesting tidbits of research that may be helpful in deciding whether your use case justifies paying for a commercial VPN. There was a paper written in 2016 titled “Characterization of Encrypted and VPN Traffic using Time-related Features.” This paper discusses techniques in traffic analysis to determine the protocol and type of traffic transmitted over encrypted connections, including VPNs, and could differentiate between VoIP, browsing, or streaming behaviors. There are other related papers including “Realtime Classification for Encrypted Traffic” (2010) and “Analyzing HTTPS Encrypted Traffic to Identify User’s Operating System, Browser, and Application” (2017); the latter describes attacks capable of defeating countermeasures intended to obfuscate payloads in transit. Although I cannot find it at this time, I also recall reading a paper that presented deep packet analysis techniques to defeat random noise injected into streams, successfully categorizing the encrypted traffic despite efforts to thwart would-be adversaries. This is an area of active research, and I expect with advancements in deep learning and greater access to GPUs capable of training neural networks tuned toward traffic analysis, VPNs may not present significant defense against adversaries that couldn’t already be achieved via other forms of encryption, e.g. TLS. Yes, I am aware of SNI-related information leaks due to how TLS presently works.

To put it more succinctly: You have to decide on your threat model.

No comments.
***

Remediation Service: Windows 10’s Dirty Secret

I don’t use Windows often. Much of my time is spent in Arch Linux except on the rare occasion I have an interest in doing something that requires Windows (typically gaming or Reason). Imagine my surprise when I booted in Windows about a week or two ago and started noticing a series of processes consuming a significant amount of disk bandwidth and appearing to scan the entirety of a) installed applications and b) everything in my user profile directory.

It turns out that sometime late last year (November 2018, possibly earlier), Microsoft released a series of patches for “reliability improvements” which include the “remediation service” that performs a few interesting tasks. Notably, this includes a service that “may compress files in your user profile directory to help free up enough disk space to install important updates.” If you’ve seen sedlauncher.exe in Windows Resource Monitor, it belongs to the remediation service and is the tool design to scan your user profile directory, presumably for files that may be candidates for compression.

sedlauncher.exe‘s malware-like behavior stems from the fact that a) it isn’t strictly launched when Windows Update requires additional space and b) it performs a thorough scan of everything in the user profile directories (pidgin chat logs, pictures, media, desktop files–everything). I assume this is because it is collating a list of files it would compress in the event Windows Update runs out of space based on some heuristic, but what perplexes me is that it is impossible to tell precisely how well a file will compress until the file is actually compressed. Yes, there’s a few heuristics you could apply (it is a file type known to compress well) but these don’t always hold true: Imagine a virtual machine image that contains a large number of compressed archives. VM images do compress well, generally, but only because the contents of the image aren’t typically compressed. But this also presents the question: Why scan for compression targets when there’s already plenty of disk space available to Windows Update? What exactly is this tool doing?

Most guides online direct visitors to one of two solutions: Remove the applicable updates or disable the Windows Remediation Service. The former isn’t a sustainable solution, because the updates will eventually be applied or because Windows’ stellar history of absolutely no security flaws (sarcasm) strongly suggests skipping updates isn’t wise. Curiously, the latter option–that is, disabling the culprit service–appears to be a foolhardy solution as well, because sedlauncher.exe returns, diligently, to its previous state of scanning everything it can access. It’s likely Windows Remediation Service scanners are launched via the task scheduler, but I’ve yet to find exactly where or how.

There is one particular solution that might work. Unlike most other core Windows tools, sedlauncher.exe is not contained in the Windows root. Instead, it resides under C:\Program Files\rempl. This rather bizarre choice suggests Microsoft has a keen interest in packaging this tool separately for other operating systems or wishes to disguise it as an installed application to keep it from prying eyes. You decide.

I’ve found renaming sedlauncher.exe to something else appears to work as a temporarily solution (but only temporary) with the appropriate caveats applied (exercise caution as this may break things). I expect it to be reinstalled with a future update, but for now it won’t be scanning my profile directory for files to assault. Whether this works in your case (or not) is left as an exercise to the reader, but be aware this may break other parts of Windows Update. I have no idea how deep the tendrils of this telemetry run into the dark recesses of Windows 10.

No comments.
***