[HN Gopher] eBPF on Windows
___________________________________________________________________
eBPF on Windows
Author : praseodym
Score : 158 points
Date : 2021-05-10 17:35 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tptacek wrote:
| A fun detail of this work is that it uses a formal-methods-based
| verifier (designed outside of Microsoft) that accepts a wider
| range of programs than does the Linux verifier, which is itself
| kind of nightmare fuel.
|
| https://vbpf.github.io/assets/prevail-paper.pdf
|
| The verifier in this paper also has some biting limitations; for
| instance, you can't resize a packet in it, because they don't
| account for pointer invalidation. I wonder whether they've since
| implemented these verifier features, since they'd be problematic
| for compatibility otherwise.
|
| Additionally, the PREVAIL paper explicitly doesn't verify program
| termination, which is kind of a dealbreaker for kernel BPF.
| GordonS wrote:
| Wow, I'm really stoked to see this!
|
| This could be a game-changer for the infosec community in
| particular - now, if you want to get into internals, such as
| tracing file system and registry calls, you've got to write
| drivers. And drivers are very tricky to write, and it's very easy
| to miss corner cases - which can result in the dreaded BSOD.
| Plus, drivers need to go through a verification and signing
| process by Microsoft.
|
| Having access to that capability from user-mode, _without_ having
| to write drivers... that would be amazing.
| Someone1234 wrote:
| Everything you described is already available on Windows in
| userland via filters (FileSystemWatcher/ReadDirectoryChangesW,
| RegNotifyChangeKeyValue, et al). Obviously you can only monitor
| whatever lives in your security context.
|
| eBPF looks cool since it is a VM, that could have access to
| _more_ kernel structures (network?), but solving the issues you
| described is largely a solved problem on the platform.
| GordonS wrote:
| Nope, with FileSystemWatcher (and the Windows APIs it uses
| under the hood) you get minimal information - only using a
| driver can you get contextual information, such as the handle
| of the thread, process and user that made the call.
|
| And RegNotifyChangeKeyValue is only useful for watching a
| single, specific value - if you monitor a tree, it doesn't
| even tell you _what_ changed, only that _something_ matching
| the filter did. And as with file system changes, if you want
| to know which thread /process/user made the change, you need
| to use a driver.
| dd21223 wrote:
| It is really great to see that eBPF is causing an industry wide
| change instead of just a Linux one!
| morelisp wrote:
| I see we're now firmly on the "extend" step.
| therein wrote:
| Sounds like this time around they are going with embrace,
| import, extinguish.
| staticassertion wrote:
| No, this would just be embrace, they have not extended the ebpf
| capabilities. It would be "extend" if there were one way
| comparability, which doesn't seem to be the case.
| brendangregg wrote:
| Great news, I'm looking forward to analyzing performance on
| Windows with BPF! Given that PerfView and WPA also got flame
| graphs it'll start to feel like home. :-)
| srcmap wrote:
| From the architecture diagram, it looks like just network ebpf
| only.
|
| Does anyone know if it can profile file/disk io type
| activities?
| hs86 wrote:
| Here is a recent comment from Dropbox engineers about the state
| of tracing tooling on Linux compared to Windows:
| https://dropbox.tech/infrastructure/boosting-dropbox-upload-...
|
| Is their assessment correct? If so, how comes that we got DTrace
| in 2019 and now eBPF ported to Windows? Are they trying to
| consolidate all tooling into one platform?
| muststopmyths wrote:
| ETW (What netsh trace in the post uses underneath) has been
| around for 20+ years in Windows and is extremely powerful.
| However, Microsoft has always neglected the usability side of
| it. It's a bitch to set up and hard to interpret. Documentation
| is there, but scattered and hard to find easily.
|
| Most people here have probably seen Bruce Dawson's performance
| analysis and debugging posts. WPA/WPR are probably the only
| user-friendly (ish) ETW applications and even those are not
| that easy to use.
|
| So yeah, Windows has had powerful tracing and inspection tools
| for a while, but few people know how to use them well.
|
| As far as why they are doing DTrace and eBPF, I think both of
| those fill some holes that ETW doesn't. Mainly dynamic tracing
| and instrumentation, but I am sure there are other advantages I
| am not thinking of as well.
|
| They could have come up with another hopelessly complicated
| Microsoftie framework to do the same things, but it's probably
| a good thing that they didn't.
| coolspot wrote:
| And that is, kids, how MS Windows piece-by-piece was slowly
| transformed into a Linux distro.
| criddell wrote:
| I thought they agreed to not compete in the Unix world when
| they sold Xenix? Is it because SCO is dead that they can jump
| right into Linux?
| tptacek wrote:
| There's a lot of interesting stuff in this post, including a
| different architecture for verifying eBPF programs, so it's
| frustrating to see a bullshitting comment at the top of the
| thread. I don't like Windows either, but the virality of the
| eBPF (and dtrace) model is an interesting story that tells us
| stuff about what operating systems are going to look like 10
| years from now, and we need to do better than comments like
| this.
| dang wrote:
| " _Eschew flamebait. Avoid unrelated controversies and generic
| tangents._ " https://news.ycombinator.com/newsguidelines.html
|
| Comments like this one take threads in predictable,
| uninteresting directions, and--what's worse--they often get
| upvoted, accumulating mass at the top of the thread and choking
| out the specific interesting stuff.
|
| "Windows v Linux" is a classic example of a generic black hole,
| sucking passing spaceships into a state from which no light can
| emerge: https://hn.algolia.com/?dateRange=all&page=0&prefix=tru
| e&que....
|
| To be fair, this is a co-creation between the comment and the
| upvotes, and the upvotes are more to blame. But the idea of
| that guideline is to refrain from introducing black holes in
| the first place, so the spaceship can poke around something
| interesting in the vicinity without collapsing, screaming, into
| an irreversible fate.
|
| Related explanation here if anyone wants more:
| https://news.ycombinator.com/item?id=26894739. Note the point
| about diffs--that's key. Diffs are what's interesting!
| etaioinshrdlu wrote:
| I recently spun up a Windows EC2 server instance in aws,
| running the latest Windows, and was not impressed. The entire
| system is not very well set up for operation via SSH.
|
| SSH is not even enabled by default on ec2. You have to Remote
| Desktop in, run a bunch of commands to enable it, and even then
| I could never figure out how to get authorized_keys to work.
|
| Once you have SSH running, you can run commands via command
| prompt or powershell. Powershell is apparently pretty modern
| and well designed, but it's quite confusing if you're used to
| Unix.
|
| A few applications I tried to install came as MSI's and they
| could not be installed via the command line, requiring the
| graphical interface.
|
| It felt like a bad way to run a server. You want fast and
| lightweight remote access on a server, and you want
| scriptability. Windows was simply worse in this area.
|
| Even if Windows was 100% compatible with Linux apps (including
| the modern CUDA deep learning stack...), I don't know why one
| would ever want to run Windows on a server. It lost the
| mindshare war, and I really see why. It really is that bad of
| an experience.
|
| The main reason I've heard people use Windows server is because
| they are forced to because of app compatibility (no tech
| startup would find themselves in this position), or the
| preference of maintaining a server with clicking in the GUI
| (again, not a place most of us here find ourselves).
|
| Anyways, I'd love to hear from someone, anyone, who likes
| Windows server more than Linux.
|
| The point of this comment is also to state the opinion that
| Windows is currently a very bad Linux distro.
| nullify88 wrote:
| Its about 5 lines of powershell to install and start OpenSSH.
| Maybe a few more if you want to automatically inject public
| keys. Well within possibilities of a user_data script that
| runs on the first boot of an AWS instance.
|
| My main pain with OpenSSH on Windows was that its an older
| 7.7 Windows port that gets installed. However 8.1 is finally
| bundled as part of the recent KB5001391 and fixes some
| annoying bugs.
| jaywalk wrote:
| I like Windows Server more than Linux. I administer both of
| them, although I am more familiar with Windows Server which
| definitely plays a big part in my preference. But I think
| that's going to be the biggest part of anyone's preference.
|
| Everything you complain about Windows Server not supporting
| is actually supported, but it was your unfamiliarity that was
| ultimately the issue. "Linux guy who is unfamiliar with
| Windows Server prefers Linux" isn't particularly shocking
| news.
| majkinetor wrote:
| This. RTFM
| coliveira wrote:
| Windows OS is a thing of the past, when people were
| supposed to do most of their work from a desktop. As soon
| as computing become based on remote services, Windows lost
| its main reason to exist. It is Windows that needs to
| adapts to the new times, not people working on other OSs.
| rasputnik6502 wrote:
| It is the OS from the past and still most people use it
| on their computers. Because they are still doing things
| from the desktop. And I suppose they're happy not having
| to adapt to technology du jour again and again.
| jiggawatts wrote:
| "When in Rome, do as the Romans do."
|
| I don't complain that Linux is hard to administer with
| PowerShell. I learned SSH and Bash.
|
| The reverse does not seem to be true, Linux admins
| generally expect everything to work exactly the same in
| Windows as in Linux.
|
| A negative effect of this is that Windows has many recent
| hires working on some of their teams with mostly Linux
| experience, and they're copying Linuxisms into Windows
| _bug-for-bug_. Even if it makes no sense in Windows.
|
| A recent example that boiled my blood is that the new
| Windows Terminal emulates the incorrect "Clear-Host"
| behaviour of ancient Linux terminals. It doesn't clear the
| virtual terminal any more, just the current viewport.
| Before, it was a convenient way to reset the terminal's
| display state without resetting variables. NOW, it just
| deletes _some_ of the display state, so if you scroll back
| you get scrambled garbage.
|
| This is not a small thing: it's significantly impacting my
| workflow. I've seen garbage output, overwritten output,
| scrolling back accidentally corrupts the output completely,
| you name it. This is not a coding error, this is correctly
| copying a limitation of some terrible terminal from the
| 1960s nobody should give a shit about in 2021.
|
| Worse: If you look back at the history of the debate around
| fixing this, as far back as the early 1990s there were
| Linux people advocating for fixing this! It's _obviously_
| broken.
|
| Then: When the same debate came up in the Windows Terminal
| issue tracker, people making the same rational, logical
| arguments were shot down with: "We have to copy the
| _standard_. "
|
| Hint: There is no "standard". This is not an RFC. It's just
| what Linux does! Linux does this just because this is what
| some random MIT or Berkley student wrote in a hurry in the
| 1960s! If you make the argument that the majority of
| systems work some way or another, and that's a defacto
| standard... then Windows should win because it was used for
| the the vast majority of computing for many decades. Linux
| has taken over only recently, and only in some areas
| (Android and web servers).
| jaywalk wrote:
| Microsoft is getting really lazy with their new
| "PowerShell for everything" mantra. Many examples with
| Windows Server and even the Azure Portal. It's great to
| have the ability to do things with both a GUI and CLI,
| but then arbitrarily limiting things to one or the other
| (usually the CLI) gets incredibly annoying.
| majkinetor wrote:
| Lets limit GUI then :)
| jaywalk wrote:
| Ha, that's actually what I'm complaining about. So many
| things that can only be done via CLI and there's no way
| to even know they're possible without crawling through
| documentation or (more often) finding somebody's blog
| post or a StackOverflow answer.
| majkinetor wrote:
| PowerShell CLI is totally discoverable tho.
| pjmlp wrote:
| Those recent hires are also affecting how Visual Studio
| gets developed.
|
| It is starting to become tiresome to get some CLI stuff
| instead of proper VS wizards.
| EvanAnderson wrote:
| I'm probably pretty similar in experience to you. I "grew
| up" with Linux (and Xenix) in the early 90s, not being able
| to afford to buy Windows Server. I transitioned over to
| Windows Server around NT 3.51 and now handle both.
|
| All the tooling for headless / remotely-manageable Windows
| is "in there" in 2008 and later. Prior versions required
| more jumping thru hoops to manage via command line, but
| Resource Kit tools helped.
| jaywalk wrote:
| My server administration journey actually began with a
| pirated copy of Windows 2000 Advanced Server. And I don't
| feel bad for it, because having started very young with
| Windows Server has directly led to many tens/hundreds of
| thousands of dollars in licensing fees paid to Microsoft
| at my direction :)
| EvanAnderson wrote:
| You missed a lot of tedious reboots by starting your
| experience with the Windows NT family w/ Windows 2000.
| Windows NT 4.0 was a breath of fresh air, as far as the
| UI went, compared to NT 3.51, but Windows NT didn't
| really come into its own, in my opinion, until Windows
| 2000.
|
| The tedious "re-apply the service pack and reboot" or
| "you thought about changing a setting, so therefore
| reboot" scenarios were nearly removed with Windows 2000.
| Having plug 'n play and hot-plug hardware work well was
| great, too.
| pjmlp wrote:
| I do mostly Windows, and given the option would rather
| keep doing so, however you just reminded me of the "fun"
| of writing ISAPI extensions on Windows 2000.
|
| For those unaware of it, IIS used to execute fully on
| kernel level, so ISAPI extensions were comparable to
| device drivers, which meant any programming error would
| just kill the kernel, thus requiring a reboot.
|
| So tracking down memory corruption issues on ISAPI
| extensions was bound to have a countless amount of
| reboots during the work day.
| pjc50 wrote:
| > Everything you complain about Windows Server not
| supporting is actually supported, but it was your
| unfamiliarity that was ultimately the issue.
|
| Funny, I've seen people saying exactly that when newbies
| bounce off some aspect of Linux, and in both cases it's a
| usability failure.
|
| Discoverability of this stuff on Windows is _terrible_.
| Things like powershell remoting exist but getting them
| working between two random machines is opaque. Yes, some of
| it gets easier in a domain, and that 's one of the big
| Windows wins (since the NIS/YP era), but domains are an
| extremely premium feature.
| jaywalk wrote:
| I don't think comparing discoverability of features in
| Desktop Linux to Windows Server is fair at all.
|
| And really, if you want to talk about discoverability
| between Linux in a server role and a Windows Server...
| Windows Server wins by an absolute landslide. But I don't
| think discoverability is all that important when you're
| talking about server administration.
| pjmlp wrote:
| As if UNIX was any better with its archaic configuration
| files and cryptic commands to avoid typing one extra
| character.
|
| Most of the stuff I learned about UNIX required actually
| buying books, not much different from Windows.
|
| Drop someone on a proper UNIX just with man to see how
| far they go joining a NFS server or logging in via yellow
| pages.
| majkinetor wrote:
| Its trivial without domain TBH.
|
| If on workgroup, you just have to have the same user name
| on different machine and it works like in domain.
|
| > Discoverability of this stuff on Windows is terrible
|
| Meh... matter of taste and adequate Windows social
| skills, not a fact.
| recursive wrote:
| I don't have much experience with Linux. All our customers
| (health care, mostly US) have Windows servers. Some of them
| have some Linux also, but that seems to be a minority. We
| need to be able to ship software they can run. Most of our
| development is windows-based.
| Uehreka wrote:
| In my experience, even MSIs can be run from the command line,
| but the amount of effort required to look this up and write a
| clean script is definitely way more than the equivalent Linux
| sysadmin task because Windows is just not expecting users to
| work this way at all.
|
| My gripe with installing things on Linux is that every
| project assumes install means "build from source", and it's
| often annoyingly hard to find the exact yum/apt-get name for
| something (do I need a PPA? is the name thing, libthing,
| libthing-dev, libthing2, or something else?) But this is a
| much smaller issue than anything I run into with Windows
| Server.
| rasputnik6502 wrote:
| I kinda like Windows server, mostly for the stability - both
| of the runtime and of functionality. Compared to Linux it
| requires less attention, i can concentrate more on software
| and less on the system: after two years of not touching i can
| still find configuration options in more or less same places.
| With Linux i have to re-learn quite a lot after not paying
| attention for a while. Missing good ssh/command line but not
| badly, I don't really need advanced shell scripting.
| bostonsre wrote:
| I don't use it in production but yea, I've read that
| automation for windows servers is mainly geared toward
| management with powershell. It's been a while since I've used
| it and it's definitely a lot different than bash, but it
| seemed petty elegant when I used it last. I like objected
| oriented programming, so having an object oriented shell was
| pretty neat.
| vladvasiliu wrote:
| But PowerShell feels so clunky and slow to me (disclosure:
| I'm used to Linux). If you want object-oriented automation
| tools, Python works much better on Linux. Granted, it's not
| a _shell_ , but if we're talking automation, then it
| doesn't really matter.
|
| I think the big issue for Windows is that most "admins"
| aren't in the habit of automating things, or at most
| they'll write a basic bat file. They still expect to click
| around their GUIs, so they'll be fairly reticent to install
| the Windows Server Core version [0]. "To be able to
| intervene in case something happens". The main issue with
| this is that they often aren't aware of possibilities
| offered only via PowerShell[1]. There's also the issue that
| when they look things over in the GUI, they won't _see_ the
| configuration that 's only visible through PowerShell.
|
| ---
|
| [0] Windows Server Core comes without a GUI, but it can be
| managed remotely with the usual tools. However, not all
| server roles work on it. Remote Desktop Gateway is one such
| example, even though it doesn't have any "desktop"
| functionality.
|
| [1] For example setting up split-view DNS. This is possible
| since Windows 2016, but only via PowerShell, and it's
| impossible to know from the GUI that it's activated. Also,
| this configuration doesn't replicate through
| ActiveDirectory.
| EvanAnderson wrote:
| MSIs, if put together well, easily install silently from the
| command line.
|
| msiexec /qn /i msi-name.msi
|
| Edit (now that I have more time):
|
| All the tooling to make Windows command-line manageable is
| there "out of the box".
|
| In a former "life" I staged a Windows Server 2008 R2 install
| that was remotely manageable with SSH (using a third-party
| SSH server) "out of the box". Similar to a "kickstart" w/ the
| Anaconda installer, you're talking about chaining scripts to
| run after the installation to enable desired functionality.
| It wasn't much different than automating a Linux install.
|
| If you enable the serial console you can do some nice
| command-line management of Windows VMs through your
| hypervisor's virtual serial port functionality too. I enjoy
| having the serial console open because I've been able to
| diagnose "hung" Windows machines (that is, not responding to
| GUI logon attempts) thru the console. It's very handy.
| malkia wrote:
| and /norestart too
| e12e wrote:
| I seem to recall authorized_keys works as expected; it goes
| into %HOME%\\.ssh\authorized_keys (I'm not sure/can't recall
| if there are some similar permission requirements). Anyway,
| that's eg: c:\users\mcgyver\\.ssh\authorized_keys
|
| And ssh needs a restart.
|
| That said, windows remote management is traditionally via
| WMI, not powershell. But PS has come a long way, and ssh is a
| sane transport. And it can function as a tunnel for WMI, RDP
| and PS (ssh is easier to use for key based auth, disabling
| password auth).
| mook wrote:
| If you're a member of the administrators group, by default
| it uses something out of C:\ProgramData instead.
|
| https://docs.microsoft.com/en-us/windows-
| server/administrati...
| e12e wrote:
| But of course, you're not running as Administrator,
| right? That's why we have runas... :)
| agumonkey wrote:
| > Powershell is apparently pretty modern and well designed,
| but it's quite confusing if you're used to Unix.
|
| bash is pretty confusing eve if you're used to unix
|
| -- Greg's
| majkinetor wrote:
| Bash is simply outdated. It grown organically and thats
| what you got. Now you have zillion scripts and situation is
| even worst then with cobol.
|
| PowerShell was made by Unix people after 2+ decades of bash
| experience. It solved hundreds of things.
|
| Yet people complain it didn't solve few or it takes a bit
| more to load (no, verbosity = RTFM). You can't ever please
| I guess.
| agumonkey wrote:
| were powershell designers from the unix world ? I didn't
| know that
|
| I don't mind bash warts, history is what it is, I don't
| sell powershell .. but someone saying powershell is
| confusing has serious jaws. powershell is really nice and
| only if you fancy sed/grep everything then you'll
| consider bash* superior
| Agingcoder wrote:
| I don't think I want to compare them - I dislike them
| both! One is too basic and cryptic, the other one is
| overly complex for a shell, and in the end, I want to use
| neither.
|
| I'm not sure what the ideal shell would look like though.
| Maybe an actual (simple and expressive) programming
| language with a way to 'lift' statements ?
| agumonkey wrote:
| oh my bad then, and the quest for an ideal shell / text
| user interface is a nice one. between lispy repls, to
| notebooks .. I guess there's a better solution that is
| both concise and fun yet not brittle.
| majkinetor wrote:
| sed/grep/awk have nothing to do with bash tho and you can
| run them equally easy on Windows (cinst sed grep awk) if
| you like outdated reg ex.
| agumonkey wrote:
| yes they're not bash but they're an integral part of bash
| scripts pipe processing
| majkinetor wrote:
| They are "integral" only because shell is lacking those
| functions.
|
| On some places tools are not there (docker image for
| example).
|
| Some people complain about size of the dotNet runtime,
| but if you install all those tools bash "needs" for comfy
| usage, you can equally easy install dotNet.
| agumonkey wrote:
| I don't think that's right. unix users care a lot about
| streams of bytes as exchange format, powershell tried the
| object stream way, to avoid parsing manually stuff every
| time and also share some common bits (table formatting
| for free, map/filter for free too)
|
| unix give you partial stuff for that like comm but it's
| just brittle
| majkinetor wrote:
| > Sure, although, you know, my team - we all have deep
| UNIX backgrounds, before getting into NT, I was a UNIX
| development manager at Digital [Equipment Corporation],
| ... worked on Ultrix, System 5.
|
| https://www.networkworld.com/article/3110744/linuxcon-qa-
| wit...
| agumonkey wrote:
| oh wow, I had no idea
|
| thanks for the link
| kwdc wrote:
| I won't comment on the eBPF or WSL or even the Windows as
| linux debate, but I used to do some Windows admin.
|
| Some clarifications are in order.
|
| MSIs CAN be installed on servers with no gui required. Or
| much more commonly via powershell automation. Completely
| remotely and I'm not referring to remote desktop either.
|
| I know its fun to complain about Windows, but really, if
| you're not using powershell and the right tools such as a
| Windows Domain, you're kind of like some kind of debian linux
| admin that refuses to use bash scripts / debian apt / ssh etc
| plus chef or similar management. It really is that kind of
| comparison you're making. What would you say about a linux
| admin that refused to use SSH or any scripting? You'd wonder
| why they are complaining.
|
| Most of Windows Server comes alive when you join the machine
| to a domain and it gets access to actual infrastructure
| rather than some lone isolated server. This is to the point
| where you don't even need to log into the machine via remote
| desktop or ssh at all. In fact you manage the server from a
| completely different Windows machine with an admin account
| within the domain. You can then run the powershell script on
| your management computer and things happen on the target
| computer(s). I haven't even mentioned the multiple other
| tools you get as part of the machines being joined to a
| domain. Or you can deploy the script to the machine and
| execute it there. Still no remote desktop required.
| EvanAnderson wrote:
| I can't imagine how anybody manages any number of Windows
| machines w/o a domain. Even just an NT 4.0-style
| "downlevel" domain (hosted with Samba, if need be) made
| life so much easier "back in the day". Once Active
| Directory came out I never looked back. Group Policy makes
| so many Windows administration tasks reproducible and
| automated.
|
| I keep meaning, year after year, to take at Samba and see
| how its Active Directory emulation functionality has
| progressed. I never end up getting around to it.
| Presumably, since so much of Active Directory is really
| just leveraging LDAP and a funky proprietary schema, it has
| progressed significantly.
|
| I've had a hard time figuring out how to position Desired
| State Configuration. It feels like an appeal to Linux
| sysadmins used to Puppet, Chef, et al. I can already do
| everything it can do with Group Policy, and I'd want an
| Active Directory domain for single-sign-on anyway. I have a
| hard time coming up with a use case for learning all new
| tooling when I've already got AD and Group Policy.
| nont wrote:
| I think mostly they're forced to use Windows server because
| of their proprietary software like outlook, active directory,
| iis etc.
|
| It was maybe easier to find people to support Windows
| servers... Just click here here and here to install.
| cptskippy wrote:
| All of the modern GUI is just a skin over powershell. Most
| server functionality/configuration isn't exposed through
| the GUI.
| pjmlp wrote:
| On the contrary, that is how Microsoft fixes the big mistake of
| not having kept POSIX subsytem around and improved it
| throughout the last 25 years.
| encryptluks2 wrote:
| They implement Linux functionality enough to suck at it and
| then the Windows users that try it thinks it is Linux that
| sucks and not Windows.
| cptskippy wrote:
| The Linux functionality is intended to allow Windows
| developers to develop for Linux and deploy to Linux.
| encryptluks2 wrote:
| Compiling on WSL2 would have terrible performance. WSL2 is
| just there to try to entice companies to say their
| developers shouldn't need to move to Linux or Mac. No one
| is seriously developing in WSL.
| kube-system wrote:
| Why would they need WSL2 to do that? AD and Office were
| and still are plenty enough to keep MS on corporate PCs.
| cptskippy wrote:
| It's not really targeted at compiling either. Think line
| of business apps on web technology like .NET Core, PHP,
| Python, etc...
|
| With WSL you can setup some docker containers or do some
| orchestration with Kubernetes and push it off to the
| cloud with minimal effort.
|
| If you really want a full Linux environment you can spin
| up a VM in Hyper-V. WSL just makes it easier to do things
| where a VM is a hassle.
| encryptluks2 wrote:
| Docker containers don't run in WSL.
| encryptluks2 wrote:
| You still have to install Docker Desktop and enable the
| integration. You can't simply install docker in your WSL2
| distro and use it.
| jhomedall wrote:
| They do in WSL2, as I understand it.
| encryptluks2 wrote:
| Try it out... install Ubuntu using WSL2. Install docker
| using apt-get. See that it doesn't work without the
| Docker Desktop install for Windows and a special
| integration. Try running podman or other container-based
| solutions and see that they don't work.
| nickstinemates wrote:
| Sure they do.
|
| https://i.imgur.com/TqW6Ola.png
| chokolad wrote:
| > Compiling on WSL2 would have terrible performance.
|
| define terrible. Compared to what ?
|
| > No one is seriously developing in WSL.
|
| A very strong statement. Do you have any proof perhaps ?
| encryptluks2 wrote:
| > define terrible. Compared to what ?
|
| Terrible = significantly worse than a native Linux distro
| that doesn't use a file system integration layer.
|
| > A very strong statement. Do you have any proof perhaps
| ?
|
| Just experience working in the industry.
| garethrowlands wrote:
| > worse than a native Linux distro that doesn't use a
| file system integration layer
|
| What filesystem integration layer?
| skinkestek wrote:
| Let me tell you something interesting:
|
| .Net Core programs run much faster on Linux.
|
| Does that sound like something they would let happend if they
| wasn't serious about their Linux efforts?
|
| That said: all is not good. For years there seems to be a
| fight going on in the wheelhouse.
|
| One month it is: Microsoft, the reliable, reasonable vendor
| in a world full of Oracle and Google.
|
| Next month it is: let's increase the cost for this small
| company by $10000 just because we can.
|
| Next month: something admirable.
|
| Next month: try to push Edge using some sleazy tactic learned
| from Googles Chrome push combined with resetting the
| defaults.
|
| It must be frustrating for the guys who try so hard to drag
| the rest of Microsoft kicking and screaming into the future
| everytime some old guys gets up from the wheelchair and turn
| the weel all the way to the port side while the helmsman
| wasn't paying attention :-]
| the_only_law wrote:
| I admittedly have only an extremely cursory knowledge of these
| sort of technologies, but how does eBPF compare to NDIS filters
| and WFP filters? Biggest reason I could imagine for this is
| easier portability of existing eBPF applications.
| aneutron wrote:
| That's exactly what I thought. Because WFP are powerful, NDIS
| is bonkers (it's what what used by Internet Download Manager
| and Kaspersky for their features), so the only use case is
| maybe YARA-style eBPF rulesets.
| tptacek wrote:
| You can do a lot more in NDIS and probably more in WFP than you
| can in eBPF, if only because eBPF has strict limits on the
| kinds of loops you can express (they have to be verifiably
| bounded). Packet-processing BPF programs are tightly bound to
| Linux kernel APIs, many of which won't be ported here, so I
| think write-once-run-anywhere is unlikely to be an attribute of
| this.
|
| Importantly: eBPF has at this point not much to do with
| packets; it's a generic kernel and userland instrumentation
| layer. Most new BPF code is written to monitor local program
| runtimes, not to look at packets.
|
| If Windows adopts XDP, we might get to a point where
| joestringer wrote:
| The packet-processing BPF programs are less tightly bound to
| Linux kernel APIs than you might think. Even in Linux, there
| has been motivation to make the APIs more generic to support
| different kernel hooks for packets, in particular XDP which
| doesn't operate on the standard internal packet buffer
| representation (skbuff).
| mad_vill wrote:
| I wonder how long until I can run cilium on my mixed node
| kubernetes clusters!
| 1970-01-01 wrote:
| See
|
| https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
|
| Step 1: Getting SQL and a few other things running in Linux. That
| was in 2016.
|
| Step 2: WSL and WSL 2
|
| eBPF puts them at something like step 2.2.5
| jaywalk wrote:
| This seems like the exact opposite of EEE. Care to explain your
| thinking?
| hkt wrote:
| One assumes the idea is to make windows have feature parity
| with linux, then try to leverage network effects for features
| windows has but linux doesn't, such that the "extinguish"
| step will follow the "extend" step.
| jaywalk wrote:
| That's called "being better than the competition" and not
| really what EEE was meant to describe.
| zhengyi13 wrote:
| If you're thinking in EEE terms, this is Embrace. Extend and
| Extinguish come later, once you've got a preponderance of
| developers on your platform.
| zwad3 wrote:
| Is there any analogue of seccomp in windows that can be used with
| BPF?
| tptacek wrote:
| Windows already has a native system call filter, doesn't it?
| roblabla wrote:
| I don't think so? I actually looked for such functionality
| recently and couldn't find anything. Kaspersky uses a
| hypervisor to hook syscalls[0] in order to provide such
| functionality. There's also DTrace for Windows[1], but that
| requires being enabled through bcdedit which is a bit... meh.
|
| [0]: https://github.com/iPower/KasperskyHook
|
| [1]: https://docs.microsoft.com/en-us/windows-
| hardware/drivers/de...
| gigatexal wrote:
| Microsoft is really being bold about adopting open tech to
| improve either it's bottom line (Azure now runs more Linux VMs
| than Windows ones) and now with eBPF. Truly a new and different
| Microsoft.
| throwaway29303 wrote:
| Pretty cool, but let's not fool ourselves. Recall history or why
| Microsoft is doing this. This is a long-term strategy.
|
| https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
| jrockway wrote:
| Has Microsoft been doing a lot of embracing, extending, and
| extinguishing lately? I guess Typescript kind of embraces and
| extends Javascript, but I think every frontend engineer will be
| doing a happy dance if they manage to extinguish it. Not quite
| 1990s Microsoft's approach.
| bostonsre wrote:
| I wonder what kind of performance this gets when compared with
| running eBPF since eBPF was written with performance in mind from
| the start.
| PoignardAzur wrote:
| What?
| bostonsre wrote:
| BPF or berkely packet filter was written to be a faster
| replacement of tcpdump. People saw that it was pretty neat
| and started using it for non-tcp dump like stuff and it
| became extended BPF/eBPF. I would guess that running eBPF on
| Windows would be a lot slower, but it would be interesting to
| see a performance comparison.
| tptacek wrote:
| Point of order: BPF wasn't written simply for tcpdump; it's
| part of a line of research on using PL runtimes to
| configure and operate networking stacks; so, right after
| McCanne's BPF paper, you get MPF, which is proposed to do
| all of demux for Mach.
| bostonsre wrote:
| Neat, did not know that.
| tptacek wrote:
| A long post I wrote about this stuff, taking the history
| back to the Xerox Alto:
|
| https://fly.io/blog/bpf-xdp-packet-filters-and-udp/
| tptacek wrote:
| They're doing native code generation, like Linux.
| mhh__ wrote:
| Hence, the reason why eBPF has been referred to in the past as
| a Spectre-accelerator
___________________________________________________________________
(page generated 2021-05-10 23:00 UTC)