The DMZ - 2018-08-15

« first day (2799 days earlier) ← previous day next day → last day (2073 days later) »

1:02 AM

Anyone know of any good online resources for learning FPGA development? E.g. information on whether to start with VHDL or Verilog (maybe SystemVerilog?), which boards are the easiest to start out with, etc. I'm just thinking of designing a simple PCIe-based hardware watchdog as a small project to learn FPGA dev.

5 hours later…

6:05 AM

yay, this is the spectre attack we have all been waiting for https://foreshadowattack.eu/ :
"Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects Virtual Machines (VMs), hypervisors (VMM), operating system (OS) kernel memory, and System Management Mode (SMM) memory."

Also: " The mitigations against Meltdown and Spectre are not effective against Foreshadow and Foreshadow-NG."

6:28 AM

So basically like another Meltdown?

It's more of a combination of Meltdown and Spectre if I understand correctly

and more powerful than Meltdown

Looks like it allows reading anything from L1.

possibly, yes

FPGA work tens to be highly specialized usually in signal processing or adaptive realtime controls. Perhaps starting out with CPLD (Complex Programmable Logic Device) might be easier as they tend to be simple digital logic gates

@this.josh Are there cheap CPLD systems with a PCIe interface?

@TomK. I wonder what kind of mitigations are necessary. It's a bit freaky since it doesn't require Spectre gadgets! Now how much longer until a vuln is published that fundamentally cannot be mitigated in any way with microcode or software?

6:31 AM

Not typically, but there may be a development board with a PCIe interface, expect to pay a lot for it

@this.josh Well that's a problem. There are some very cheap FPGAs on PCIe boards.

@forest that might be just it

@TomK. Well this one does say it can be mitigated.

Or at least, it says microcode updates / software updates are required.

I have to read through the intel whitepaper later

Their technical reports explain mitigations. Reading it now.

6:33 AM

ah okay

Since it attacks L1, it seems like individual cores are isolated from each other.

Or at least the exploit running on one core cannot retrieve L1 data from another.

Like these? fpgadeveloper.com/2014/03/…

> Therefore, mitigating Foreshadow-NG includes sanitizing PTEs, flushing the L1 cache when crossing protection boundaries, and modifying OS and hypervisor schedulers to prevent non-trusting VMs or processes from executing concurrently on sibling logical cores.

@this.josh Yeah looks like it, though those have way higher specs than I need.

gotta get to work, I'll take a look later on

bb

I gotta wonder what the perf impact of flushing L1 on each context switch would be...

sigh

We're so fucked.

6:50 AM

Do you have a link to very cheap FPGAs on PCIe boards?

I had one open a while ago for something like $150, can't find it atm.

Was a "beginner board" for education.

Anonymous

Shouldn't have closed the tab Forest FeelsBadMan

PCIe is an unusual interafce for a FPGA dev board, along with a FPGA board you will need a toolchain and library. FPGAs are often selected for their libraries over their raw features.

Doesn't Icarus Verilog have an open source toolchain / simulator and libraries?

Yes there is a tool chain, but I'm not sure what their library contains. A lot of FPGA value is in the IP cores that are in libraries provided by toolkits

Semiconductor intellectual property core

In electronic design a semiconductor intellectual property core, IP core, or IP block is a reusable unit of logic, cell, or integrated circuit (commonly called a "chip") layout design that is the intellectual property of one party. IP cores may be licensed to another party or can be owned and used by a single party alone. The term is derived from the licensing of the patent and/or source code copyright that exist in the design. IP cores can be used as building blocks within application-specific integrated circuit (ASIC) designs or field-programmable gate array (FPGA) logic designs. == History... ==

building a gigabit ethernet controler from scratch isn't easy so being ably to source that as a IP core, or a HDMI interface controller, or a PCIe interface controller, saves a lot of work.

7:08 AM

Yeah I've seen some IP cores on OpenCores.

It looks like you can hunt down many common pieces, github.com/enjoy-digital/litepcie

Yeah that's one I have open.

3 hours later…

Anonymous

9:52 AM

@Kepotx I fixed my RegEx issue.

Anonymous

(?!.*(0/24)).* - The important thing I've ever typed in my whole life.

11:09 AM

@forest git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/…

if VMs are used where users can install their own OS and/or kernel - think cloud infrastructures - you not only have to update but also have to deactivate hyper threading. word is that the performance loss is up to 50%

12:07 PM

@JourneymanGeek can you tell me, how we can get a sandbox?

Journeyman Geek

12:52 PM

@TomK. there's no formal sandbox on SE

1:24 PM

@JourneymanGeek but all the other kids have one :(

puzzling, code golf, worldbuilding

Journeyman Geek

They're the odd kids tho

I always thought we were the odd kids

Anonymous

Are we not the odd kids?

Anonymous

I am an odd kid.

highfive

Anonymous

1:28 PM

returns highfive

3:05 PM

Afternu

Finally back in Scotland after DefCon... So I can trust connectivity a bit more

hullo

i think @forest was there as well

Anonymous

4:01 PM

@RoryAlsop Afternoon Rory, how was it? :D

joelw.id.au/FPGA/CheapFPGADevelopmentBoards

2 hours later…

5:44 PM

@RoryAlsop I just use GSM with Tor. USB sticks are nice because they don't have DMA even if they do get compromised.

@TomK. I wonder how much that commit actually mitigates it.

> SMT (HyperThreading) control knobs, which allow to 'turn off' SMT by offlining the sibling CPU threads. The knobs are available on the kernel command line and at runtime via sysfs

Wait, doesn't Linux already let you toggle HT?

Or at least selectively disable individual cores (e.g. each virtual core)?

> Hypervisor protection by flushing L1 Data Cache on VMENTER.

This at least seems like it won't have that bad of a perf hit.

I bet grsecurity/PaX already has a low-perf impact mitigation :/

> + The Linux kernel contains a mitigation for this attack vector, PTE
+ inversion, which is permanently enabled and has no performance
+ impact. The kernel ensures that the address bits of PTEs, which are not
+ marked present, never point to cacheable physical memory space.

This is good. I wonder what attack disabling SMT actually mitigates then, since this appears to mitiate the userspace->userspace or userspace->kernelspace memory read attacks. Perhaps the high-performance loss is only for mitigating the SGX and hypervisor implementations?

@forest afaik, yes

I didn't have much time to read through the material today

still at work

Ah, that's good.

12 hour day today

For me at least. Gotta be a nightmare for VPS hosting companies.

yep

but I mean, everybody thought that perfomance losses would be crazy before the first spectre/meltdown patches, and in the end they weren't that bad

5:56 PM

But if the mitigation has no perf impact for regular systems, I can tolerate the occasional 50% perf drop on virtual machines (actually, I tend to run a VM on only a single core anyway with QEMU, so I could probably just lock it to that core and disable HT for that one physical core).

Eh, I dunno. For context switch-heavy workloads, they are pretty bad.

no, there should be a performance impact even for regular end user systems

but only up to 15% or something. but I have no idea where that number comes from

Hm, it says the PTE inversion has no perf impact.

I read it in an article where it literally said "word is performance loss will be up to 15%"

And that it fully mitigates the attack against the kernel from userspace.

yeah, might be BS then

5:59 PM

Well 15% stands out to me because that's the often-quoted HT perf boost.

So disabling HT would naturally reduce perf by 15% (for some workloads).

I think I read something like 15-50% for HT disabling

but I am really unsure. my head is kinda spinning

Yeah that sounds about right. Very job-dependent.

or was that for cache flushing?

no idea...

> + The system is protected by the kernel unconditionally and no further
+ action is required.

Under their mitigation selection guide when virtualization is not used.

So it looks like the fix is trivial and has no perf impact for bare metal!

hm

6:02 PM

It also looks like it requires ring 0 to attack in a guest. Take that Qubes!

nothing further?

and that is only kernel update?

Your stupid policy of giving every VM root screws your users once again!

@TomK. Looks like it.

weird. I thought that at least a bios update was needed as well..

but as I said.. head. spinning. work. no play. etc.

And if your VM guest also has the mitigations, then you are protected from everything but ring 0 attacks in the guest (i.e. you first have to pwn the guest and get kernelmode before it can read memory on the host).

I'll take another look tomorrow

leaving now. peace out

6:05 PM

peace

vusec.net/projects/tlbleed

Maybe this is what you were thinking wrt disabling HT?

6:19 PM

We'll have accurate information on L1TF available this evening in the customer portal, including info on limitations of the upstream mitigations that I haven't seen reported elsewhere

Tweeted by grsecurity on August 14, 2018 at 11:04 PM

sigh

4 hours later…

9:58 PM

Yay, got confirmation i was hired at Thalès. Got my dream job :3

« first day (2799 days earlier) ← previous day next day → last day (2073 days later) »

Transcript for

Aug '1815

The DMZ

A serious place where infosec is discussed PS we don't do hard...

404-errors moderate-anarchism pretending-to-work staring-into-the-abyss

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile