BBC BASIC
« Intel CPU memory protection flaw »

Welcome Guest. Please Login or Register.
Jan 22nd, 2018, 4:55pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Intel CPU memory protection flaw  (Read 93 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Intel CPU memory protection flaw
« Thread started on: Jan 3rd, 2018, 9:37pm »

Some of you will have seen reports today of a feature of Intel CPUs that can, with sufficient effort being taken by an 'attacker', reveal some details of kernel memory (which should be invisible) to a user-mode program.

It isn't clear whether only the layout of the kernel memory can be ascertained (which would weaken kernel address layout randomisation) or whether the actual contents of some kernel memory can be read (which would be more serious, but seems less likely). Edit: It seems to have been demonstrated that data can be read, but not very reliably.

The workaround, which is being applied to Windows, Linux and Mac OS kernels (amongst others), adds an execution-time overhead to each round-trip from user mode to kernel mode and back. The impact on performance, therefore, will depend on whether a program performs a large number of kernel transactions or not.

It is relatively unlikely that a BBC BASIC program will be making heavy demands on kernel resources, so I would not expect the performance hit to be significant. File input/output using BGET# and BPUT# might have been an issue, but fortunately both BB4W and BBCSDL implement automatic file buffering which means that blocks of data (256 bytes in the case of BB4W, 1024 in the case of BBCSDL) are transferred at a time, rather than single characters.

See Intel's own statement which disputes that the impact on speed of workarounds will be significant for the "average user".

Richard.
« Last Edit: Jan 3rd, 2018, 10:26pm by Richard Russell » User IP Logged

michael
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 141
xx Re: Intel CPU memory protection flaw
« Reply #1 on: Jan 4th, 2018, 04:28am »

Seems the more I get updates from windows, the more problems I have. Now my Toshiba i7 cant initialize 3D graphics acceleration.(BBC Basic is not affected as far as I know)

That is the case for one game. My ASUS ROG gaming computer still works fine, but I have had to roll back one update on it.

If it aint broke we will fix it... LOL

User IP Logged

I like reinventing the wheel, but for now I will work on tools for D3D
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: Intel CPU memory protection flaw
« Reply #2 on: Jan 4th, 2018, 08:36am »

on Jan 4th, 2018, 04:28am, michael wrote:
Now my Toshiba i7 cant initialize 3D graphics acceleration.(BBC Basic is not affected as far as I know)

I would expect that any program using the D3DLIB libraries (in BB4W) or the OGLLIB library (in BBCSDL) would be adversely affected by problems enabling 3D graphics acceleration. You may find that updating your graphics drivers helps (or even reverting to an earlier version).

On the subject of this thread, I think Intel have a valid complaint that the 'media' are, by and large, describing this as a 'bug' in their CPU chips. A bug is something that doesn't work as it was intended to work, and that's not the case here. The chips are working exactly as they were designed to.

The issue is better described as a 'vulnerability' that was not previously appreciated. Intel cannot be criticised for missing something that nobody else - including other CPU vendors - realised could be exploited until recently. It's unclear to what extent AMD and ARM CPUs may be similarly affected, but even if they are less vulnerable than Intel chips this is through luck rather than 'better' design.

Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: Intel CPU memory protection flaw
« Reply #3 on: Jan 4th, 2018, 12:00pm »

To any x86 assembly language programmer, the exploit code is beautiful in its simplicity:

Code:
; rcx = kernel address
; rbx = probe array
  xor rax,rax
  mov al,byte [rcx]
  shl rax,12
  mov rbx,qword [rbx + rax] 

It attempts to read a byte of data from kernel memory [rcx], which of course faults. The subsequent instructions, which are speculatively executed despite the fault, multiply the data byte al by 4096 and use the resulting value as the offset into a 1 Megabyte array (addressed by rbx). Reading from that array refreshes one of 256 cache lines.

Although the data byte itself is not visible to the user-mode program (it is discarded as soon as the access-violation fault is handled by the CPU) it is possible to determine which cache line was refreshed, by the simple means of timing how long it takes to read from that line. If it reads very quickly, the cache line was already refreshed; if it takes some time to reload, it wasn't.

So having determined which of the 256 cache lines is 'fast', you can infer the value of the data byte read from the kernel memory! Neat.

Richard.
« Last Edit: Jan 5th, 2018, 1:44pm by Richard Russell » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: Intel CPU memory protection flaw
« Reply #4 on: Jan 5th, 2018, 1:43pm »

on Jan 4th, 2018, 12:00pm, Richard Russell wrote:
To any x86 assembly language programmer, the exploit code is beautiful in its simplicity

I should probably add that some of the details I have provided are almost certainly wrong, but the principle is correct. Don't try to reproduce the exploit based on the code I listed, at least not without expecting some experimentation to be required.

Richard.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls