lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 12 Nov 2022 11:58:51 -0800
From:   Ashok Raj <ashok.raj@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Thiago Macieira <thiago.macieira@...el.com>,
        Jithu Joseph <jithu.joseph@...el.com>, <hdegoede@...hat.com>,
        <markgross@...nel.org>, <tglx@...utronix.de>, <mingo@...hat.com>,
        <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <gregkh@...uxfoundation.org>, <tony.luck@...el.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <patches@...ts.linux.dev>,
        <ravi.v.shankar@...el.com>, <athenas.jimenez.gonzalez@...el.com>,
        <sohil.mehta@...el.com>, Ashok Raj <ashok.raj@...el.com>
Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs
 entry

On Sat, Nov 12, 2022 at 08:20:30PM +0100, Borislav Petkov wrote:
> On Sat, Nov 12, 2022 at 10:21:35AM -0800, Thiago Macieira wrote:
> > Not exactly. That's what this file is there for. It allows the algorithm to 
> > read the current batch file, add 1, then echo back. If the load succeeds, the 
> > the batch exists; if not, then the algorithm should simply go back to 0.
> 
> This sounds to me like there's a special order in which those batches
> should be executed?

There is no special sequence required. Idea is that user would like to run all
tests, so simply going through them works. User has no idea what the test
content is for each file, unless there is a case where they like to repeat
a specific batch on one core, they can simply skip and do one specific
batch, they don't need to go through in sequence.

> 
> I thought they're simply collections of test sequences which can be run
> in any order...
> 
> > First, there's the question of the ability to see into /lib/firmware. I'm not a 
> > kernel dev but I'm told that request_firmware() only operates on the root 
> > container's filesystem view. We're expecting that the application may get 
> > deployed as a container (with full privileges so it can write to /sys, sure), 
> > so it won't be able to see the host system's /lib to know what files are 
> > available. It could "guess" at the file names, based on the current processor's 
> > family/model/stepping and a natural number, but that's sub-optimal.
> 
> It is not about seeing - you simply give it the filename -
> request_firmware* does the "seeing". Either the file's there or it
> isn't.

Link to Tony's last post before changing the file formats to accomodate
Greg's feedback.

https://lore.kernel.org/lkml/SJ1PR11MB6083263E8EEBF106B6B61B24FC969@SJ1PR11MB6083.namprd11.prod.outlook.com/

Cheers,
Ashok

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ