Live data from Hacker News

W^X policy violation affects Windows drivers compiled in VS 2013 and previous

codeinsecurity.wordpress.com

21–30 of 30 posts

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#21
post #20

Earlier quoted context omitted.

In userland, the DISCARDABLE and MOVABLE flags date back at least to Windows 3. Not sure about the kernel.

That would have been a different file format though, right?

Yes, but the point is that movable/discardable flags are an old-school hack that probably shouldn't have made it into modern binary file formats to begin with.

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#22
post #15
post #11

W^X policy??

Writable exclusive OR eXecutable policy, applied to memory pages it makes memory safety bugs a lot harder to exploit, as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

Just to emphasize (be picky): Logically it is exclusive or (XOR), not inclusive (OR). That is either write or execute, but not both.

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#23
post #20

Earlier quoted context omitted.

That would have been a different file format though, right?

Yes, but the point is that movable/discardable flags are an old-school hack that probably shouldn't have made it into modern binary file formats to begin with.

Memory pressure didn't go away with NT 3.1 though... probably in Windows Vista it could have gone away...

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#24
post #15
post #11

W^X policy??

Writable exclusive OR eXecutable policy, applied to memory pages it makes memory safety bugs a lot harder to exploit, as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

> as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

Very interesting read on how this works in practice: https://www.corelan.be/index.php/2010/06/16/exploit-writing-...

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#25
post #15

Earlier quoted context omitted.

Writable exclusive OR eXecutable policy, applied to memory pages it makes memory safety bugs a lot harder to exploit, as an attacker can't simply load an executable payload (typically, shellcode) in the address space of the exploited program and jump to it...

Just to emphasize (be picky): Logically it is exclusive or (XOR), not inclusive (OR). That is either write or execute, but not both.

Too be really picky, logically it's NAND. Not writable and not executable is valid. :)

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#26
post #18

Earlier quoted context omitted.

The whole DISCARDABLE thing was a relic of pre-NT versions of Windows, back when people were just beginning to realize that 640K was not, in fact, enough for everybody. I'm surprised the kernel pays any attention to it at all anymore. There's not much upside to paging memory associated with drivers in and out. Certainly not worth the additional attack surface that you get by making things more complicated than necess…

Pre-NT? Are you sure? My understanding of history is that the PE file format was part of NT 3. I would have thought that earlier systems kept as much paged as possible, but maybe that's wrong. Maybe it's not worth it any more. My phone has 8GB of memory. I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a syste…

> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system.

No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...maybe you're thinking of desktop environments.

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#27
post #26
post #18

Earlier quoted context omitted.

Pre-NT? Are you sure? My understanding of history is that the PE file format was part of NT 3. I would have thought that earlier systems kept as much paged as possible, but maybe that's wrong. Maybe it's not worth it any more. My phone has 8GB of memory. I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a syste…

> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system. No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...may…

Or fat initrds

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#28
post #26
post #18

Earlier quoted context omitted.

Pre-NT? Are you sure? My understanding of history is that the PE file format was part of NT 3. I would have thought that earlier systems kept as much paged as possible, but maybe that's wrong. Maybe it's not worth it any more. My phone has 8GB of memory. I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a syste…

> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system. No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...may…

Yep. The smallest I've seen IIRC was a 386 with 4MB running X11 back around 1998. Took a good time to boot and start X11, but it did work.

Re: W^X policy violation affects Windows drivers compiled in VS 2013 and previous

#30
post #28
post #26

Earlier quoted context omitted.

> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system. No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...may…

Yep. The smallest I've seen IIRC was a 386 with 4MB running X11 back around 1998. Took a good time to boot and start X11, but it did work.

My first X86 machine running Linux was a 386DX/33 with 4MB of RAM. It booted the Linux 0.96 kernel (IIRC) just fine and I also used X on that machine. As far as I remember, I did have 16MB swap as well to make things actually usable, but the kernel itself would boot just fine with just the 4MB RAM. If memory serves me right, it was actually possible to get the kernel to boot with as little as 2MB in those days, but that was the limit.

I remember a custom kernel compile on this machine took a little over 24 hours. :-/

Post reply on HN